Loading...
Loading Operational AI Strategy & Governance...
Loading Operational AI Strategy & Governance...
All of it running against live portals, all of it written from scratch rather than assembled from a framework tutorial.
A tool surface an agent can actually drive — properties, pipelines, workflows, lists, associations, reporting — with the scopes, rate limits and pagination handled once instead of in every prompt.
Every figure an agent reports carries the query that produced it, a confidence state, and a blocker code when it could not be established. A finding you cannot check is not a finding.
Nothing writes on the first pass. A plan is produced, hashed, and shown to a human; execution refuses anything the approved plan does not name. Deletes need an explicit target ID and exact confirmation text.
Tokens, credentials, emails and phone numbers are stripped before a payload reaches an LLM and before it reaches a change log. The method gets recorded; the secret never does.
The AI logic that belongs inside a workflow rather than beside it — serverless, idempotent, and instrumented well enough to debug at 2am without guessing.
Versioned change logs per portal, a decision record for anything an agent was allowed to do, and a written boundary for what it is not allowed to touch.
These are not positioning. Each one exists because the alternative was tried, measured, and found to produce confident nonsense.
Config says what a system could do. Only the action log says what it did. An agent that reads a workflow and declares it broken is guessing — and guessing confidently is the most expensive failure mode an AI tool has. Every config-derived finding stays a hypothesis until behaviour confirms it.
Asking another model to check the first model's reading of the same configuration confirms wrong conclusions rather than catching them. Verification has to come from a different source — the log, the record, the actual state of the system — or it is theatre.
The first production session blocks writes outright. Not as a setting someone can flip in a hurry, but as the default the system has to be deliberately talked out of.
Built. The MCP server, the agents, the approval gate and the redaction layer are all things written from scratch and running against live portals — not a framework recommendation or a readiness assessment. Advisory happens because building it surfaced the questions worth asking, not instead of building.
Four things, in order. The first production session blocks writes outright, so the system has to be deliberately talked out of read-only. Nothing executes without a dry run. A plan is produced and hashed, and execution refuses any operation the approved plan does not name. Deletes need an explicit target ID and exact confirmation text. On top of that, every change is written to a versioned per-portal log, so there is a record of what happened and who allowed it.
Because it carries its evidence. Every figure reports the query that produced it, a confidence state, and a blocker code where it could not be established. The underlying rule is that configuration is a hypothesis: config says what a system could do, only the action log says what it did. A finding derived from configuration alone stays a hypothesis until behaviour confirms it — which is exactly where most AI audit tools quietly assert instead.
You can, and it is close to worthless. A second model re-reading the same configuration confirms wrong conclusions rather than catching them, because it inherits the same blind spot. Verification has to come from a different source — the action log, the record itself, the live state of the system. Anything else is theatre with a second invoice attached.
Tokens, credentials, email addresses and phone numbers are redacted before a payload reaches a model and before it reaches a change log. The method is recorded so the work stays reproducible; the secret is not. That distinction matters — a guard that refuses to record how something was done makes the system unusable, and a guard that records the credential makes it dangerous.
The production work is HubSpot, which is where the depth is. The architecture — a tool surface an agent can drive, evidence attached to every claim, a plan-and-approve gate in front of writes — is not HubSpot-specific and has been built to be portable. If your system has a decent API, the same shape applies.
An agent you want to let near production, an AI audit whose findings you cannot verify, or an automation nobody can explain. Bring the specific one.
Also worth reading: AI agents as operational infrastructure · the AI-ready diagnostic
Real engagements, anonymised where the work was delivered under another company.
Configuration says what a portal could do; only the action log says what it did. Built around that, with a gate before every write.
Read the case studyCorrections become portal-agnostic rules, with redaction in the write path because a shared store is a cross-tenant boundary.
Read the case studyA multi-tenant engine normalising portal enquiries into one model, with a heartbeat that detects its own silence.
Read the case study