AI Controls and Governance
What controls do I need before deploying an AI agent?
Most pre-deployment advice for AI agents is really infrastructure advice: can it scale, is it secure, does it integrate, is the data pipeline sound. Those controls matter, and they are also the ones least likely to be missing — engineering teams generally understand them and notice quickly when they're absent, because they block deployment visibly.
The controls that actually get skipped are quieter. They don't block anything. The agent deploys fine without them. You discover they were missing months later, when a decision needs explaining and the answer turns out never to have been written down.
Controls Are Decisions, not Software
The word "controls" suggests things you install — gates, filters, monitoring hooks, permission systems. Some controls are that. But the controls that determine whether an agent deployment is governable are not products. They are decisions, made and recorded before the agent runs: what this agent is for, what it must not do, what it should be working from, and who owns all of that.
This is worth stating plainly because it changes what "ready to deploy" means. A deployment blocked by missing infrastructure is blocked by work. A deployment that goes live without these decisions isn't blocked at all — it just goes live ungoverned, and nothing visibly breaks. The readiness gap in most agent deployments is not technical capability. It's that nobody wrote down the intent while it was cheap to do so.
The Checkpoint Question
One control sits slightly apart from the four, because it's about the shape of the work rather than the record of it: where do humans remain in the loop? Not every agent action needs approval, and pretending otherwise produces checkpoint theatre that gets bypassed within a month. The honest version of this control is deciding deliberately which actions are consequential enough to need a human decision, which are reversible enough not to, and writing that boundary down.
The failure mode here is not the absence of checkpoints. It's checkpoints placed by default rather than by decision — approval steps nobody can justify, alongside consequential actions nobody thought to gate. A deployment where someone can say "these actions need approval, those don't, and here's why" is governed. One where the checkpoints accreted is not, even if there are more of them.
What This Looks like in Practice
The honest sequencing: the technical controls — security, access, monitoring — are necessary and usually present, because they block visibly when missing. The intent controls — permitted scope, operating context, named owner, deliberate checkpoints — are equally necessary and usually absent, because their absence blocks nothing on day one.
A practical diagnostic before go-live, worth naming because it travels well:
The outsider test: could someone who wasn't in the room answer the four questions about this agent from the record — not from asking around?
If yes, the deployment is governed in the sense that matters: the answers exist before the questions arrive. If no, the agent may still perform well. But the organisation has deployed something it can operate and cannot yet account for, and the difference between those two only becomes visible at the worst possible moment.
Engramic's approach
How Engramic Approaches it
There are multiple ways to put the intent controls in place before an agent deploys. This is one approach.
Engramic treats the pre-deployment moment as the point where the controls are authored: the agent's goals, constraints, and operating context are recorded in a curated knowledge graph before it acts, with the person accountable for each recorded alongside. The four questions are answerable from day one because their answers were created as deployment decisions, not assembled afterwards. When the agent's scope or context changes later, the change is recorded with the prior version preserved — so the readiness test keeps passing as the deployment evolves, not just at go-live.
The technical controls remain the engineering team's domain. Engramic's contribution is the layer that usually has no home: the recorded intent.
In short
The controls that matter before deploying an AI agent are mostly decisions, not software: what it's permitted to do, what it will be working from, how its actions will be interpretable later, and who is accountable for it — plus a deliberate decision about where humans stay in the loop. The technical controls block deployment visibly when missing; these don't, which is why they're the ones that get skipped. The readiness test is the outsider test: could someone who wasn't in the room answer the four questions from the record? Governance questions asked before go-live become records. The same questions asked after an incident become investigations.