“Who approved that?”
The approval was a line in a prompt. The model read it, then decided for itself whether it applied.
governance: Who approved that? Now you know.
ConvOps governance puts approval gates in your AI agent workflows. Where your process needs a person, the workflow holds: the engine checks every gate against real state, and the AI cannot move past one that is unmet.
gates checked by the engine · refusals name the reason · every change written down
task Fix checkout timeoutexample
the AI starts the workflow
review the fix
Ship the timeout fix?
Not yetApprove
in short
How do you govern AI agents with ConvOps?
With approval gates the engine checks, rules delivered into the step the agent is on, and an audit row for every change, in the AI client your team already uses.
ConvOps is the operations layer for AI agents: an MCP server that holds your team's process as workflows, with approval gates, a shared memory and an audit trail. It runs no AI models.
key facts · october 2026
- A gate sits on a workflow step and can require explicit approval, finished child tasks, a task status or a context note. The engine checks it on every advance.
- When a gate is unmet, the cursor does not move and the response names each unmet condition, for example "Requires explicit user approval".
- Approval is passed explicitly on the advance call. It is never inferred from chat text.
- Policies are reusable rules delivered into the active step. They are guidance the agent reads; gates are the enforcement.
- Each audit row keeps the agent's self-declared label apart from the verified account the server derived from the credential.
- Article 14 of the EU AI Act asks that high-risk AI systems "can be effectively overseen by natural persons during the period in which they are in use." Gates and the audit trail are how ConvOps supports that oversight; ConvOps is not a compliance certification.
best for
- Teams that need a named person to approve specific agent steps: merge, release, send, pay.
- Security and compliance reviewers who need field-level history of what agents changed.
- Organizations preparing human oversight evidence for the EU AI Act.
not for
- Blocking single tool calls inside one session. Claude Code permission modes and hooks do that; ConvOps governs the order of steps and the sign-off between them.
- Custom roles or per-item permissions. There are three roles: owner, admin and member.
- A separately signed approval record. The audit shows the verified account behind the advance that passed the gate.
updated
the problem
An approval in a prompt is a suggestion.
Most AI setups govern with wording. The model reads the rule, then decides for itself whether it applies.
“Did anyone check the tests?”
The chat says they passed. Nobody can tell if that is a fact or a sentence the model wrote.
“Which rule was it following?”
Standards live in pasted prompts that drift. Every person runs a slightly different copy.
watch it work
A bug fix, waiting for a yes.
One fix, asked in Claude. The AI does the work. The engine holds the line. A person decides.
01you, in Claude
A request becomes a task.
Someone asks Claude to fix the checkout timeout. ConvOps opens a task with the team's bug fix workflow attached, before any code is touched.
The checkout times out under load. Can you fix it?
task created · Fix checkout timeout · Bug fix workflow
task · exampleFix checkout timeout
reproduce
fix
reviewapproval
ship
done
02the AI
Steps arrive one at a time.
The AI receives only the current step: reproduce, then fix. It cannot read ahead or jump to the end.
- 1Reproduce
Reproduce the timeout and note the cause.
- 2Fix
Write the smallest fix. Add a regression test as a child task.
- 3Review
not shown yet
- 4Ship
not shown yet
03the engine
It tries to ship. Refused.
The fix is done and the AI asks to advance. The engine checks the gate: no approval yet, tests still running. The cursor stays put.
Fix is done. Advancing to ship.
workflow_advance · refused · 2 unmet
refused · cursor stays on review
- Requires explicit user approval
- 1 of 1 child tasks are not completed
04you approve
A person decides.
Tests finish. You read the change and say yes. The next advance carries your OK, the gate is met, and the work moves on.
waiting for you
Ship the checkout timeout fix?
Run regression tests · completedapproval · waiting
Send backApprove
05written by ConvOps
The record already exists.
Every change to the task and the workflow was written down as it happened: what changed, the agent's label, and the verified account behind it.
- taskstatusbacklog→in_progress
- workflowcurrent stepfix→review
- workflowcurrent stepreview→ship
- taskstatusin_progress→completed
claude agent labelDana Reyes verified account
example data
The checkout times out under load. Can you fix it?
task created · Fix checkout timeout · Bug fix workflow
task · exampleFix checkout timeout
reproduce
fix
reviewapproval
ship
done
try it
Try to skip the approval.
You are the AI. Find a way past the review gate. Then switch sides and approve as the human.
Fix the checkout timeout. Use the bug fix workflow.
Reproduced it and wrote the fix. The review step is next.
your move, as the AIthen, as the human
task Fix checkout timeoutexample
gate on review
requires_approvalno approval yet
wait_for_childrenRun regression tests · 0%
Pick a move on the left. The engine answers every advance.
where it holds
Hold where it matters. Run everywhere else.
Gates sit only where you put them. Between gates the AI works at full speed.
reproducethe AI
fixthe AI
reviewapproval
shipthe AI
donerecorded
the record
Every change, written down.
Changes to tasks and workflows are recorded as they happen: what changed, the agent's label, and the verified account behind it.
agent label
What the AI calls itself. Self-declared, so treated as a label.
verified account
Stamped by the server from the credential. Never a parameter, so it cannot be typed in.
how far it goes
Tasks and workflow instances. There is no separate approver field.
waiting for the first change
example data · field-level before and after · tasks and workflow instances
the ideas
Four things that make it hold.
Gates the engine checks
Approval, finished tests, a required note. Checked against real state on every advance. Unmet means the cursor does not move.
refuses, with reasons
Rules at the moment of action
Policies are written once and delivered inside the step the AI is working on. Guidance it reads, not a lock. Gates are the lock.
edit once, every run
Two identities per change
Each change to a task or workflow keeps the agent's self-declared label apart from the verified account it ran under.
tasks + workflows
Three plain roles
Owner, admin, member. Checked by the server, with a real refusal when a role is not enough. Nothing more granular.
owner · admin · member
the difference
Wording in a prompt vs a gate.
- "Wait for approval" written in a prompt
- The model decides if the rule applies
- "Tests passed," says the chat
- Who did it is whatever the log narrates
- Standards pasted into every system prompt
- A skipped review shows up after the damage
A gate is structure, not prose
Gate keys sit on the step and are evaluated by the engine on every advance: approval, children finished, task status, a required context note.
payload
{
"id": "approve",
"gate": {
"requires_approval": true,
"wait_for_children": true,
"prompt": "Ship it?"
}
}A refusal says exactly why
When a gate is unmet, the cursor does not move and the response lists each unmet condition. Approval is passed explicitly on the advance call, never inferred from chat text.
payload
// the AI asks to advance; the gate is unmet
workflow_advance(task_id="…")
{
"current_step": { "id": "review" },
"unmet_conditions": [
"Requires explicit user approval",
"1 of 1 child tasks are not completed"
]
}Policies are delivered, not enforced
A policy is reusable text, global or per workflow, injected into the active step when the agent reads it. Edit it once and every run picks it up. It informs; gates enforce.
payload
{
"slug": "cite-or-cut",
"text": "Every factual claim carries a
source or it does not ship.",
"enabled": true,
"assigned": ["bug-fix", "content-os"]
}The audit row keeps two identities
Changes to tasks and workflow instances write field-level before and after. The actor field is the agent label the caller declares. The human is stamped by the server from the verified credential. There is no separate approver field.
payload
{
"actor": "implementer",
"actor_user_name": "David Marsa",
"action": "updated",
"entity_type": "task",
"changes": {
"status": { "old": "review", "new": "completed" }
}
}questions
AI agent governance questions, answered.
Can the AI skip an approval step?
Not by asking or by writing that it was approved. The engine evaluates the gate on every advance against real state, and an unmet gate leaves the cursor where it is, with the unmet conditions listed. Approval has to be passed explicitly on the advance call.
Are policies enforced?
No, and we say so. Policies are rules delivered into the step the agent is working on, so the rule is in front of it at the moment it acts. The enforcement mechanism is the gate. We keep the two apart on purpose.
How do I know who approved something?
The advance that passes the gate is written to the audit with the agent's label and the verified account the call ran under. There is no separate approver field, so the record shows the account behind the advance, not a signed approval.
What exactly does the audit cover?
Field-level before and after on tasks and workflow instances, plus a high-level activity feed. It does not claim to cover every table in the product.
Can an agent pretend to be a person?
The agent label is self-declared, so treat it as a label. The human identity is never a parameter: the server derives it from the verified credential, so there is nowhere in a request to forge it.
How granular are permissions?
Three roles: owner, admin and member, checked at the route and service layer with real refusals, and the last owner cannot be removed. Plain by design.