Autonomy a team can sign off on.
The reason a team, not just an individual, runs on ConvOps: gates the engine refuses to advance past, rules that reach the agent at the moment it acts, and an audit row that keeps the agent's claim apart from the verified human.
Governing AI agents means being able to answer three questions with evidence: what is the agent allowed to do without a human, which rules was it following when it acted, and who, exactly, did what. Most setups answer all three with prose: instructions in a system prompt, approval requests the model is asked to make, and logs where the agent narrates its own behavior. Prose is not governance, because a model can talk past it.
ConvOps answers them with structure. Where a human is required, the workflow carries a gate that the engine evaluates and refuses to advance past. The rules an agent must follow are policies delivered into the step it is executing right now, edited in one place and picked up by every run in flight. And every mutation writes an audit row that keeps two identities apart: the label the agent declared, and the human derived on the server from the verified credential, which no request parameter can forge.
We are precise about the mechanism because that precision is the product. Gates enforce; policies inform at the moment of action; the audit covers the surfaces agents act on. Each claim below is stated exactly as far as it holds.
The run stops. You decide.
Approval gates hold the cursor until a human says go. Structural conditions hold it until reality catches up: children finished, status reached, context recorded. The engine evaluates all of it on every advance.
{
"id": "approve",
"gate": {
"requires_approval": true,
"wait_for_children": true,
"prompt": "Ship it?"
}
}The rule reaches the agent at the moment it acts.
Policies are governance rules assigned to workflows, one by one or globally, injected into whichever step is active right now. Edit one and every run in flight picks it up on its next step. No template surgery, no redeploy.
{
"slug": "cite-or-cut",
"text": "Every factual claim carries a
source or it does not ship.",
"enabled": true,
"assigned": ["bug-fix", "content-os"]
}Two identities, kept apart.
Every mutation on tasks and workflow instances writes an audit row with field-level before and after. The agent is a label it declares. The human is derived on the server from the verified credential, and there is no parameter through which an agent could forge it.
{
"actor": "implementer",
"actor_user_name": "David Marsa",
"action": "updated",
"entity_type": "task",
"changes": {
"status": { "old": "review", "new": "completed" }
}
}Plain roles, real refusals.
Three roles: owner, admin, member, enforced with real 403s at the route and service layer, with last-owner protection. An activity feed keeps the high-level story: created, started, completed, approved, blocked.
- API keys are hashed, shown once, scoped to the user
- Workspace isolation is enforced in the database itself: see the security page
- Approvals pass through the gate; the audit records the advance
Instructions vs governance
| rules as prose | rules as structure |
|---|---|
| "Please wait for approval" in a prompt | requires_approval, evaluated by the engine |
| Standards pasted into every system prompt | Policies injected into the active step, edited once |
| Who did it is whatever the log narrates | Agent claim and verified human, kept apart per row |
| Review means trusting the transcript | Field-level before and after on every mutation |
| Compliance drift is invisible until it bites | A refused gate is visible the moment it refuses |
questions
Are policies enforced?
Policies are governance text delivered into the step the agent is executing at that moment, so the rule is in context exactly when it applies. The enforcement primitive is the gate: engine-evaluated conditions that refuse to advance. We keep the two mechanisms distinct because conflating them is how governance claims go soft.
How do I know who approved something?
Passing a gate is a mutation like any other, and every mutation writes an audit row carrying both the agent's self-declared label and the authenticated human derived server-side from the credential. The human identity is never a parameter, so an agent cannot claim to be you.
What exactly does the audit log cover?
Field-level before-and-after diffs on tasks and workflow instances, the surfaces agents act on, plus a high-level activity feed of created, started, completed, approved, and blocked events. We state the scope precisely rather than claiming blanket coverage.
Can an agent impersonate a human?
No input slot exists for it. The verified human on a write is stamped by the server from the authenticated credential; request bodies, headers, and tool parameters have nowhere to carry one, so a forged identity has nowhere to land.
How granular are permissions?
Three roles: owner, admin, member, enforced with real 403s at the route and service layer, with last-owner protection. Plain by design; we would rather you know exactly what the model is than imply granularity that is not there.
Does any of this slow the agent down?
Only where you asked it to. Gates hold precisely at the points you placed them; everything between gates runs without ceremony, and policies arrive inside the step payload the agent was already reading.