DEV Community: Cognous

The Replay Bundle That Remembers What Happened

Doug Sillars — Tue, 25 Aug 2026 12:58:42 +0000

It's 2am. A customer complains about something an agent did. The next morning the CEO is already asking the only question that matters: did the agent do something it shouldn't have?

"I'm pretty sure our guardrails are solid" isn't an answer anyone wants to give the boss. It certainly won't fly with a customer, an auditor, or with legal. What they want is proof, and proof means being able to answer specifically: what did the agent try to do, on this exact run, and what happened when it tried?

If that answer lives in the timestamps of a few hundred servers and a half-dozen tool integrations, you don't have proof. You have a scavenger hunt. "Trust us, it's fine" does not survive a scavenger hunt.

Cognous' Open Control Stack exists to close that gap. It follows four steps: Declare → Control → Replay → Evidence.

Declare: Agents need guardrails to tell them what they can and cannot do — that's a manifest, declared up front.
Control: They need something enforcing those guardrails live — that's a control plane, deciding allow/block/escalate on every proposal in real time.

In this post, we'll cover Replay: no longer defining and patrolling the guardrails, but the receipts that the rails held. Taking what the Control Plane recorded during a run and turning it into one portable file — the thing you actually hand someone instead of a text file with pasted logs from a dozen systems.

What The Control Plane Hands Off

Picture a workflow mid-run: actions getting proposed, the gate deciding each one, live.

Now what? The Control Plane made the right calls in the moment — but how do you actually know that, after the fact, without having watched it happen live? That's the question Replay answers: it takes what already happened and turns it into something you can go back and inspect.

The Control Plane keeps a recorder running for the life of a run — that's what's actually holding the frame, the proposals, the decisions, the traces as they happen. At the end of the run, the recorder exports everything it captured as a replay bundle: one file you can store, ship, or hand off for later analysis.

bundle = recorder.generate_replay_bundle()
with open("run_bundle.json", "w") as f:
    f.write(bundle.model_dump_json(indent=2))

run_bundle.json is the full playback of the workflow — every decision, every trace, and the evidence behind the one blocked action, send_email, all in one place. It's exactly what you'd look at to understand an error, or hand over if there's a deeper investigation.

The Replay Tool

Agent Replay Bundle ships its own CLI, arb, for working with files like this one — validating, summarizing, redacting, signing. Start with validation, pointed at the bundle the Control Plane just exported:

$ arb validate run_bundle.json
Error: Replay bundle failed model validation: 1 validation error for AgentReplayBundle
bundle_id
  Field required [type=missing]

It fails immediately. The Control Plane's export calls the field replay_bundle_id; arb's schema — the AgentReplayBundle model that validate checks against — calls it bundle_id.

The Agent Replay Bundle is a public interchange format, meant for any system, and Agent Control Plane's internal run record shapes several of the schema terms differently than the Replay Bundle. Running validation means performing a mapping step between the two first — small, mostly renames:

mapped = {
    "bundle_id": run["replay_bundle_id"],
    "run_id": run["run_id"],
    "generated_at": run["generated_at"],
    "frame": run["frame"],
    "action_proposals": run["actions"],
    "policy_decisions": run["decisions"],
    "policy_traces": run["policy_traces"],
    "authority_records": run["authority_records"],
    "reliance_records": run["reliance_records"],
    "blocked_actions": run["blocked_actions"],
    "final_output": run["final_output"],
}

Run that, and the same run record now validates:

$ arb validate mapped_replay_bundle.json
VALID  bundle_id=ae564206-8daf-4b19-9d60-db54f56387a5  issues=2
  WARNING W005: Bundle has no authority records.
  WARNING W012: signature_metadata is missing.

Valid — with two warnings, not zero. Neither one blocks validity, and both are honest about the bundle's actual state: no authority was granted for this run (which is why two of the three actions didn't just allow), and nothing's been signed yet.

Worth building into your own pipeline: none of this runs automatically. generate_replay_bundle() builds the object; arb validate is a separate command a human has to think to run. Nothing stops a bundle from sitting unvalidated for months until the day someone actually needs it — which is the worst possible time to find out it doesn't pass. Wire the mapping and the validation into the end of every run, not into the moment an auditor asks for one.

What A Reviewer Sees First

arb summarize is the one-screen version — what you'd look at before deciding whether to open the full bundle:

$ arb summarize mapped_replay_bundle.json
bundle_id:          ae564206-8daf-4b19-9d60-db54f56387a5
run_id:             c3f474dd-952b-4f27-ab5c-98de868b3c67
status:             complete
actor:              support-agent-v1
environment:        production
policy_version:     v1.0
action_proposals:   3
policy_decisions:   3
policy_traces:      3
blocked_actions:    1
authority_records:  0
reliance_records:   1
final_output:       present
redacted:           no
signed:             no

Three proposals, three decisions, one block, zero authority records. That last number is the tell — it's the same fact the warning surfaced, now visible at a glance instead of buried in a rule name.

Redacting For Export

mapped_replay_bundle.json — the bundle we just validated — still has raw targets and payloads in it: customer IDs, draft email bodies, potentially PII. Fine for an internal review, not fine to hand to outside counsel.

Redaction isn't content-aware — it doesn't scan text and detect what looks sensitive. It replaces a fixed set of fields wholesale: payload (redacted by default), plus target and final_output if you opt in with flags. Everything structural — IDs, timestamps, decision results, policy names — is preserved no matter what:

$ arb redact mapped_replay_bundle.json --out redacted_bundle.json --targets --final-output
Redacted bundle written to redacted_bundle.json

"redaction_metadata": {
  "redacted": true,
  "redacted_at": "2026-08-18T19:47:34Z",
  "redacted_fields": [
    "action_proposals[0].payload",
    "action_proposals[0].target",
    "action_proposals[1].payload",
    "action_proposals[1].target",
    "action_proposals[2].payload",
    "action_proposals[2].target",
    "final_output"
  ],
  "replacement": "[REDACTED]"
}

A redacted bundle still validates clean — the whole point is that a reviewer can see what was blocked and why, without seeing the customer's actual email address.

Signing For Export Integrity

Once a bundle is ready to leave the building, sign it so anyone downstream can tell if it was altered in transit — the redacted version, since that's the one actually going out the door:

$ arb sign redacted_bundle.json --secret "demo-secret" --key-id "cognous-demo-key-01" --out signed_bundle.json
Signed bundle written to signed_bundle.json

$ arb verify signed_bundle.json --secret "demo-secret"
Signature VALID

$ arb verify signed_bundle.json --secret "wrong-secret"
Signature INVALID

That's HMAC-SHA256 over a canonical serialization of the bundle. Worth being precise about what it proves: it tells you the bundle hasn't changed since it was signed, given the secret. It does not prove who signed it — there's no identity binding, no PKI, no protection if the secret itself leaks. For production use, that's a job for a real key management system. For a shared-secret export check between two parties who already trust each other, HMAC does what it says.

Reading The Verified File

The auditor gets signed_bundle.json, runs verify, and knows immediately whether it matches what left your hands. Signing isn't encryption, though — verify is the only command that speaks the signed wrapper (signed_bundle_id, replay_bundle, signature_metadata). To actually read the run, pull the inner bundle back out first:

import json
with open("signed_bundle.json") as f:
    signed = json.load(f)
with open("extracted.json", "w") as f:
    json.dump(signed["replay_bundle"], f, indent=2)

Now extracted.json is a plain AgentReplayBundle again — summarize, validate, everything else works on it. Verify first, extract second: confirm nothing's been tampered with before you trust a single field inside it.

The signature also doesn't prove anything about the gap between when the run happened and when you got around to signing it. signed_at is just whatever time you ran the sign command — there's no check against generated_at. A bundle that sits unsigned for three days is three days an editor could have touched the file with no trace of it; sign it on day three, and verify comes back clean regardless. The signature only covers the window it's actually been alive for. So the real answer isn't "sign it before you send it" — it's validate, redact, and sign as part of the run itself, the moment the bundle is generated, so there's no gap for anything to slip into.

Proving The Guardrails Held

Back to that morning-after meeting: the complaint, and the question from the boss. What was once a stressful scavenger hunt across servers matching timestamps and logfiles is now just opening one file.

Agentic runs get their guardrails from two layers: a manifest declaring what's allowed, and a control plane enforcing that live. Replay is the layer that lets your team prove those guardrails actually held — turning what the control plane recorded into one validated, signed file anyone can check independently, long after the run itself is over.

Clone Agent Replay Bundle and try arb against the example bundles in the repo, or your own control plane exports.

Learn more about Agent Replay Bundle at cogno.us.

Cognous Control Plane: The Layer That Tells Your Agent No

Doug Sillars — Tue, 18 Aug 2026 19:39:36 +0000

It's all too common — a viral tweet describing how AI agents with poorly defined guardrails deleted production, wiped a critical database, or caused some other disastrous occurrence. Agents need guardrails: this includes permissions to do the job, but also blockers that limit the reach of the agent, thereby preventing accidental disasters that fuel viral tweets.

Cognous' Open Control Stack is a framework for wrapping AI agents in guardrails, providing access where needed, but blocking the boundaries that cannot be crossed.

In our introductory blog post, our agent drafted a cringey follow-up email and "helpfully" sent it to a company's entire list of top customers. Nobody approved that send, and the human marketing team had to drop everything and work to mitigate the damage.

Open Control Stack is structured as four layers: Declare → Control → Replay → Evidence.

We built the first layer in The Manifest That Keeps Your AI Agent Honest, the Agent Action Manifest. That's the Declare layer — a JSON file that works as the allow/block list for our agent:

Pull the top customer: allowed
Draft a reply: draft-first
Pull contract details: blocked
Send the email: needs approval

But that's all a manifest is — a list. Nothing reads it and nothing enforces it. We need something that takes that list and actually applies it to the agent while it's running.

That's the Agent Control Plane — the Control layer. This post is about what it actually does when the agent tries something.

What Sits Beside The Agent

The Control Plane doesn't run the agent, and it isn't a framework. It sits next to whatever is already generating the agent's behavior — OpenClaw, Hermes, a custom loop, whatever — and turns every proposed action into a recorded decision before that action is treated as real.

The agent's job is small in this picture — it proposes. The Control Plane does the rest: it decides, and it documents. Propose is the only row the agent touches. Decide is the gate ruling allow, block, or escalate. Document is what gets written down once the decision's made. The agent doesn't get a say in the outcome — it just gets to ask.

The pattern, end to end:

Propose

The agent wants to do something. The Control Plane frames it, and a proposal gets built.

Agent Task: The agent kicks off the run. In our use case: "review a customer account and follow up."
Frame: The Control Plane frames the execution context for the run — the task, actor, environment, allowed tools, blocked tools, policy version. This gets locked in at the start and becomes immutable for the life of the run.
Action Proposal: The agent's ask — this tool, this action type, this target, this payload, this reason. Recorded before anything executes — that's the point of the proposal steps. If the decision gate blocks it next, nothing downstream ever sees a real tool call, but the attempt is still on the record.

Decide

The Control Plane decides whether that proposal is actually okay. This is where the manifest's declarations actually take effect: what it declared is what ends up in the frame's allowed and blocked lists, and the frame is what the gate checks against. Two of the six rules below check something separate from the frame: authority — whether this actor currently has permission to write, or to send things externally. Authority is granted per run, on top of the frame, and it's what rules 3 and 5 are checking for.

Policy Gate: Decides what happens to the proposal. Six rules, checked top to bottom, first match wins:
1. tool is explicitly blocked → block
2. tool is not in the allowed list → escalate
3. action type is external_send → allow if authority for it exists, otherwise block
4. action type is read (and passed rules 1–2) → allow
5. action type is write → allow if authority for it exists, otherwise escalate
6. anything else → escalate
Policy Decision + Evaluation Trace: The gate's verdict, plus the rule-by-rule path it took to reach it.
Allow / Block / Escalate: The three possible verdicts. Only allow lets the proposal go on to actually touch a tool.

Document

Once a decision is made, the Control Plane writes down what happened, what the decision was, and how it was made.

Reliance Record: Once an action is allowed and actually executed, a record of what the agent depended on to produce its output — a tool, a database, a file, an API, user input. Blocked and escalated actions never execute, so there's nothing to record reliance on — dependence doesn't exist until an action actually runs.
Run Record: Every proposal, decision, trace, block, and reliance from this run, assembled into one object.
Replay Bundle: The run record packaged up for later, portable inspection.

Running The Scenario For Real

Let's take three of those actions from the manifest and actually run them through the gate: pull_top_customers, draft_reply, and send_email. All three are on this run's allowed-tools list. pull_contract_details is also declared in the frame's blocked-tools list, matching the manifest — but the task is "review a customer account and follow up," which never calls for contract details, so the agent never proposes it. It's declared, not exercised: nothing for the gate to evaluate here.

Starting the run:

This is the Control Plane spinning up: RunRecorder() creates the recorder instance, and start_run() builds the frame — the same frame from the Propose section above, locking in the task, actor, environment, allowed tools, blocked tools, and policy version for everything that follows.

from agent_control_plane import RunRecorder

recorder = RunRecorder()
run_id = recorder.start_run(
    task="Review a customer account and follow up.",
    actor="support-agent-v1",
    environment="production",
    allowed_tools=["pull_top_customers", "draft_reply", "send_email"],
    blocked_tools=["pull_contract_details"],
    policy_version="v1.0",
)

Proposing and Deciding One Action:

Here's the pattern for a single action, pull_top_customers. The same process repeats for the other two actions — omitted here for brevity:

Propose the action with the propose_action method. This is stored in the variable a1.
Evaluate the proposal with evaluate_action. This returns two values: the decision, and, if the action is blocked, a blocked-action record.

a1 = recorder.propose_action(
    tool_name="pull_top_customers", action_type="read",
    target="crm:top_customers", payload={"limit": 25},
    reason="Identify the customer's account tier before drafting a reply.",
)
d1, _ = recorder.evaluate_action(a1)

pull_top_customers is not blocked, so we receive only the decision, and the unused second value gets thrown away with _. d1 holds the decision: the verdict (allow, block, or escalate), which rule produced it, and why. Here's what the gate decides across all three actions:

Action	Type	Rule	Result
`pull_top_customers`	read	4	allow
`draft_reply`	write	5	escalate
`send_email`	external_send	3	block

Missing authority is what stops two of the three from just allowing. draft_reply escalates and send_email blocks — same problem, nobody granted permission for this run — but different severity, because the two actions aren't equally reversible. A blocked send is stopped outright: once an email's out, it's out. An escalated write just doesn't execute yet. Nothing about the original decision ever changes — but if someone grants write authority before this run ends, a fresh proposal for the same action would clear rule 5 as allow.

The evaluation trace is where the reasoning survives, not just the verdict. Here's the trace for the send_email decision:

{
  "rules_evaluated": [
    {"rule_name": "blocked_tool_policy", "matched": false, "result": "none"},
    {"rule_name": "unknown_tool_policy", "matched": false, "result": "none"},
    {
      "rule_name": "external_send_authority_policy",
      "matched": true,
      "result": "block",
      "reason": "Action type 'external_send' requires an authority record with scope 'external_send', which was not found."
    }
  ],
  "final_result": "block"
}

A reviewer looking at this trace can tell exactly which check failed and why — not just that the action was blocked. That matters because send_email is on the allowed-tools list; nothing about the tool itself was forbidden. The trace is what proves the block was about missing authority, not a banned tool.

Worth noting: draft_reply escalating isn't a lesser outcome than blocking. It's easy to read "escalate" as a downgrade of "block," but it's really the gate saying it doesn't have enough information to decide safely, so a human should. Grant write authority to the run, and the same action clears rule 5 as allow instead — the rule didn't change; what the actor is authorized to do did.

Documenting The Proposal And Decision

After a decision has been made, the Cognous Control Plane documents what occurred during the process. All of the information is collated and stored in one place — not grabbed from logs scattered across different tools and pieced together by timestamp.

The first step is the Reliance Record. Recall that this only documents actions that actually ran — in this case, pull_top_customers:

recorder.record_reliance(
    source_name="pull_top_customers",
    source_type="tool",
    scope="customer tier and account fields",
    referenced_action_id=a1.action_id,
)

This doesn't get written to a file by itself — it's held in memory as part of the run, alongside every proposal, decision, and trace, until the whole thing gets closed out and exported:

recorder.complete_run("Draft prepared and escalated for review. Email send was blocked, not attempted.")
recorder.export_json("run_record.json")
bundle = recorder.generate_replay_bundle()

export_json() writes everything — proposals, decisions, traces, the one blocked-action record, that one reliance record — to a RunRecord JSON file. Retrieving the reliance record later is just reading that file and looking at its reliance_records array.

Reading The Results

Writing the record is only half the story — you also need a way to check it. That's acp, the Control Plane's own command-line tool, shipped in the same repo: github.com/cogno-us/cognous-agent-control-plane.

Running it against the run record we just exported:

acp validate-run run_record.json

RunRecord 79ad6860-03de-4136-9828-d4e40fbd05f4: valid (0 errors, 0 warnings)

Validation here isn't checking whether the run succeeded — it's checking that the record is internally consistent: every decision references an action that actually exists, every blocked action corresponds to a decision that actually says block. It's a check on the evidence, not on the outcome.

The replay bundle gets the same treatment:

acp validate-replay replay_bundle.json

ReplayBundle 535c72f8-efee-4144-9b78-7f7fff73133d: valid (0 errors, 0 warnings)

What This Deliberately Doesn't Do

The Control Plane only enforces the rules and authority it's actually been given — it doesn't infer intent, and it doesn't fill gaps with a best guess. A permission that was never granted shows up as an escalation or a block, not a pass. It's not a compliance system, and it's not a guarantee that the agent's output was correct. It's the layer that turns "the agent tried to do X" into a recorded, deterministic, inspectable decision, every time.

It also doesn't decide what happens after a decision is made. The gate doesn't open a ticket, notify anyone, or track whether an escalation ever gets reviewed. Whether a human looks at the draft, whether the agent retries, whether authority eventually gets granted — that's handled by whatever's orchestrating the agent, not by the Control Plane.

Next Up

We now have a run: three proposed actions, one blocked, one escalated, one allowed, each with a trace and a fingerprint, packaged into a replay bundle that validates clean. That bundle is a record of one run.

The Cognous Open Control Stack has four steps: Declare → Control → Replay → Evidence.

In The Manifest That Keeps Your AI Agent Honest, we declared in the manifest what was allowed and what was not. In this post, we walked through the Control Plane — it runs next to your agentic framework to allow, escalate, or block actions. The Control Plane records the results from every action taken.

Next, we look at the last two steps: Replay and Evidence. These are the tools that will save you when auditors are knocking at the door, or you need to prove you've redacted customer data, or just prove it hasn't been tampered with since it was generated. That's the Agent Replay Bundle, and we'll cover it in our next post.

In the meantime, the Control Plane repo, examples, schemas, and test suite are live now: github.com/cogno-us/cognous-agent-control-plane. Clone it, run examples/simple_agent_run.py, and watch the gate make the call.

The Manifest That Keeps Your AI Agent Honest

Doug Sillars — Wed, 12 Aug 2026 14:50:04 +0000

In our first post, Cognous Keeps Your AI in Check, we introduced the scenario: a customer-service agent that pulls CRM records, drafts replies, and — if nobody's watching — occasionally sends 1,000 tone-deaf emails to your best clients. We said the fix isn't reading what the agent wrote after the fact. It's deciding, in advance, what the agent is even allowed to attempt.

That decision has to live somewhere. It can't live in a Slack thread, a comment in the agent's system prompt, or "Dave from platform remembers we blocked that." It needs to be a file — versioned, reviewable, and boring enough that a security team can actually sign off on it.

That's what Cognous's Open Control Stack is for. It's four small, open-source projects — Declare, Control, Replay, Evidence — that sit beside your agents and cover authorize, enforce, and prove. Declare comes first, and its artifact is the Agent Action Manifest. This post describes the Action Manifest tooling in the Open Control Stack, available on GitHub.

The Four Actions, Written Down

If you remember in post one, our AI agent was pulling customer data, drafted a cringey email, and sent it to our top 1,000 customers. The Action Manifest is used to outline the agent's permissions as declarations, to prevent this from ever happening again:

{
  "manifest_version": "0.1",
  "manifest_id": "customer-service-agent-manifest",
  "agent_name": "customer-service-agent",
  "owner": "support-platform-team",
  "environment": "production",
  "default_action": "block",
  "tools": [
    {
      "tool_name": "crm",
      "description": "Customer relationship management system",
      "allowed": true,
      "external_system": "crm.internal",
      "data_classification": "customer_pii"
    },
    {
      "tool_name": "email",
      "description": "Outbound customer email system",
      "allowed": true,
      "external_system": "smtp.internal",
      "data_classification": "customer_pii"
    }
  ],
  "actions": [
    {
      "action_name": "pull_top_customers",
      "tool_name": "crm",
      "action_type": "read",
      "description": "Retrieve top customer records from the CRM.",
      "default_action": "allow",
      "reliance_requirement": {
        "required": true,
        "allowed_source_types": ["tool", "database"]
      }
    },
    {
      "action_name": "draft_reply",
      "tool_name": "email",
      "action_type": "write",
      "description": "Draft a reply email for a customer inquiry.",
      "default_action": "allow",
      "authority_required": [
        {
          "scope": "email.draft.customer",
          "description": "Permission to draft outbound customer emails",
          "required": true,
          "source": "support-platform-team"
        }
      ],
      "review_requirement": {
        "mode": "draft_first"
      }
    },
    {
      "action_name": "pull_contract_details",
      "tool_name": "crm",
      "action_type": "read",
      "description": "Retrieve contract terms from the CRM.",
      "default_action": "block",
      "tags": ["contract", "restricted"]
    },
    {
      "action_name": "send_email",
      "tool_name": "email",
      "action_type": "external_send",
      "description": "Send an approved email to the customer.",
      "default_action": "escalate",
      "authority_required": [
        {
          "scope": "email.send.customer",
          "description": "Outbound customer send scope",
          "required": true,
          "source": "email.send.customer"
        }
      ],
      "review_requirement": {
        "mode": "approval_required",
        "reviewer_role": "support-lead"
      },
      "reliance_requirement": {
        "required": true,
        "allowed_source_types": ["tool", "user_input"]
      },
      "payload_policy": {
        "sensitive_fields": ["customer_email", "customer_name"],
        "forbidden_fields": ["contract_terms"]
      },
      "redaction_hints": [
        {
          "field_path": "customer_email",
          "reason": "PII in exported records"
        }
      ]
    }
  ]
}

(Field names here follow the public schema — check the repo for the exact current shape if you're implementing against it.)

Rules are only as good as what is defined. At the very top of the manifest, we explicitly cover anything not mentioned: "default_action": "block". So when a new tool is onboarded (for example send_tweet), you don't need to go back and update every manifest — it's blocked until you expressly give the agent permission to use it.

For those actions that are defined:

pull_top_customers and draft_reply are both allow, but not the same kind of allow: pulling the top customers is allowed, full stop, but the draft reply has review_requirement.mode: draft_first — the agent can write it, but it stops there.
send_email isn't just "escalate" as a vague gesture — it names the exact authority scope required (email.send.customer), the exact reviewer role (support-lead), and which payload fields have to be redacted before this record goes anywhere near an audit export.
pull_contract_details is the odd one out — it doesn't strictly need to be there. default_action: block already covers anything undeclared, so an unlisted "read contract details" action would be blocked anyway. It's included for visibility: a blocked action that shows up in the manifest, tagged restricted, is a documented decision someone can point to. A blocked action that's simply never mentioned looks identical to an oversight.

It's important to note that the manifest is not enforcement. It doesn't stop the agent from doing anything — a runtime layer has to actually read it and act on it (that'll be described in the next post). What the manifest gives you is a single artifact that says, in one place, what should happen — before the agent has run even once.

The Nine Action Types

In our simple manifest above, we show three possible action types. The manifest supports nine. These classifications are what give a governance review the ability to distinguish a harmless read from something that should never happen without a human:

Action	Meaning
`read`	retrieves or inspects information
`write`	creates or modifies information, not necessarily sent externally
`external_send`	sends information outside the system boundary
`delete`	removes information or records
`export`	packages or transfers information downstream
`purchase`	initiates or prepares a purchase
`approve`	approves or authorizes a workflow step
`escalate`	routes to a human or supervisory process
`other`	anything not otherwise classified

A tool list alone can't tell you this. Knowing the agent "has access to email" tells you nothing about whether it can draft, send, or both, and what's supposed to happen before each.

The Four Review Modes

Action type says what kind of thing an action is. Review mode says who has to look at it, and when — and it's doing just as much governance work in our example as action type is. There are four:

Mode	Meaning
`none`	no specific review posture declared
`human_review`	a human is expected to look at it before execution or completion — no specific person named
`approval_required`	approval is required from a named reviewer role
`draft_first`	the agent produces a draft; it does not finish the action itself

The difference between human_review and approval_required is easy to miss but it matters: human_review says "someone should look at this" without saying who. approval_required is stricter — it names a reviewer role, and the validator enforces that: an approval_required action with no reviewer_role fails validation outright.

That's why send_email in our manifest uses approval_required with reviewer_role: "support-lead", not human_review. Sending customer email isn't "someone should probably glance at this" — it's "this specific role signs off, or it doesn't go out."

Worth being precise about what "support-lead" actually is here: a role string, nothing more. The manifest doesn't know who holds that role, doesn't know they're on Slack, and doesn't page anyone. Your enterprise-side plumbing converts "support lead" to Janice, and builds an alerting system in Slack to let her know that her approval is required. The public stack's job ends at "this role must approve, and there's a record of whether it did."

Reliance: A Third Thing Being Tracked

Authority asks whether an action was allowed. Review asks whether a person signed off. Reliance asks something different: what did this action actually depend on to produce its result?

A reliance_requirement declares that an action should leave a record of its source — a tool, a database, a file, an API, or user input. pull_top_customers declares reliance on tool and database, because a governance review should be able to see it actually came from the CRM and not somewhere the agent invented. send_email declares reliance on tool and user_input, tying the send back to the approved draft it was built from.

draft_reply and pull_contract_details don't declare a reliance requirement — which is why the summarize output above shows Actions requiring reliance: 2, not 4.

Validation Isn't Optional, and It Isn't Decoration

A manifest can be valid JSON, but be semantic nonsense. A delete action on the production database marked allow isn't caught by JSON Schema. It's caught by the validator, which checks things like:

does every action reference a tool that's actually declared and allowed?
is a privileged action type (external_send, write, delete, purchase, approve) missing an authority requirement it should have?
is an action marked approval_required but missing a reviewer role?
are there duplicate action or tool names?
are sensitive fields declared with no redaction hints to match?

Run it from the CLI — aam, short for Agent Action Manifest, is the command-line tool that ships with the manifest repo. First we run the validate command to ensure that the JSON is valid:

$ aam validate customer-service-agent-manifest.json
Validation result: VALID
Manifest ID:       customer-service-agent-manifest

Warnings (3):
  [W004] [actions[1](draft_reply)] Action 'draft_reply' has effective default_action 'allow' for action_type 'write'.
  [W006] [actions[1](draft_reply).payload_policy] Action 'draft_reply' has action_type 'write' but no payload_policy is declared.
  [W005] [actions[2](pull_contract_details).reliance_requirement] Action 'pull_contract_details' has action_type 'read' but no reliance_requirement is declared.

VALID, but not silent — the validator still flags things worth a second look, even in a manifest that passes. Fair warnings, too: we didn't bother declaring a payload policy for a draft-only action, and a blocked action doesn't need reliance evidence it'll never produce.

Next we can summarize the manifest with the summarize command:

$ aam summarize customer-service-agent-manifest.json
Manifest ID:          customer-service-agent-manifest
Agent name:           customer-service-agent
Environment:          production
Tools:                2
Actions:              4

Actions by type:
  external_send: 1
  read: 2
  write: 1

Actions by default posture:
  allow: 2
  block: 1
  escalate: 1

Actions requiring authority: 2
Actions requiring review:    2
Actions requiring reliance:  2

That "2" next to authority is easy to misread as just the send — it's actually draft_reply and send_email both. Drafting on a customer's behalf declares its own authority requirement (email.draft.customer), separate from the one on the final send (email.send.customer). Declaring it isn't the same as enforcing it — nothing here checks whether that authority actually exists. That check is the Control Plane's job, next post.

aam verifies that your manifest is ready, and gives the team a concise summary of what's allowed.

What This Deliberately Doesn't Do

The manifest is the Declare layer, and it stays in its lane:

it doesn't execute the agent
it doesn't enforce anything at runtime
it doesn't grant authority — email.send.customer being declared as required doesn't mean it exists
it doesn't replace your application's own authorization system

Declaring that sending email should require approval is not the same thing as stopping an unapproved send. That gap — between what's declared and what actually happens when the agent tries to act — is exactly what the next layer closes.

Next up

The manifest says what the agent may propose. It says nothing about what the agent actually does on a Tuesday afternoon when it's mid-run and reaching for the send button. That's the Agent Control Plane — it reads this exact manifest, sits beside the agent at runtime, and turns every proposed action into a recorded decision: allow, block, or escalate, deterministically, every time. That's next.

The manifest repo, examples, schemas, and test suite are live now: github.com/cogno-us/cognous-open-control-stack. Clone it, validate the customer-service example, break it on purpose and watch the validator catch you.

Cognous Keeps Your AI in Check

Doug Sillars — Thu, 06 Aug 2026 22:49:57 +0000

You've probably gotten an email that was supposed to feel personal, but obviously wasn't. Something about it just felt off. Automated. And somewhere in the back of your mind, you wondered: who approved this?

Honestly? The answer is probably no one.

Organizations are leaning harder on AI agents to actually do work. Agents are making database queries, writing letters, accessing email lists, but where does the access end? Without solid guardrails, tone-deaf emails are no longer an embarrassing edge case, they're a real risk. Nobody wants to be the team that let an agent send 1,000 tone-deaf emails to its best clients before anyone noticed.

This series is about the tooling that keeps that from happening, and about actually building it, not just reading about it.

What actually needs to happen

The email itself might be perfectly fine. Correct grammar, on-brand, even genuinely well-written. But the problem is that the email didn't need to be sent. The agent just did it anyway, without any guidance from the team.

So the fix isn't a better read of what the agent said. It's governance around what the agent is allowed to do, three capabilities, specifically:

Authorize: Decide in advance what an agent is allowed to do.
Enforce: Apply that decision the moment the agent tries to act, before the action executes, not after.
Prove: Turn every run into a record you can produce on demand, not one you have to reconstruct from memory.

Application logs are a day late and a dollar short: the emails are already sent. Looking at logs is reactive. You need a stack that sits in front of your agents and proactively approves or denies actions.

Introducing Cognous

Cognous builds infrastructure for governing AI agents. Its first release, the Open Control Stack, is fully open source: four small projects that sit beside your AI agents to keep them in check, together covering Authorize, Enforce, and Prove. The four projects are Declare, Control, Replay, Evidence.

Declare, the Agent Action Manifest. Written once, before the agent ever runs. The manifest provides or denies access. The agent is attempting to complete a task, but the manifest keeps it in check:

Pull top customers: default_action: allow. A CRM read, flagged to leave a reliance record of what data it used.
Draft a reply: default_action: allow, review_mode: draft_first. The agent prepares content; it doesn't finish the job.
Pull contract details: default_action: block. Off-limits for this agent, full stop.
Send the email: default_action: escalate. Requires a named authority scope and human sign-off before it's eligible to execute.

The point is that the manifest lets you say reading customer data is fine, reading contracts is not, drafting is fine, but sending the email needs a person: four different rules for four different actions, declared before any of them happen, instead of one blanket policy applied to "the agent" as if every action carried the same risk.

Control, the Agent Control Plane. Runs live, alongside the agent. Every time the agent tries to do something, the Control Plane checks it against what was declared, records the attempt, and either allows it, blocks it, or escalates it for approval, deterministically, every time. Every one of those outcomes gets written down, not just the bad ones.

Replay, the Agent Replay Bundle. Not a process, an export. When the run ends, everything the Control Plane recorded (what was proposed, what was decided, what was escalated, what it relied on) gets packaged into a single portable file. No more digging through the logs of a dozen systems to reconstruct one run. Every read, every draft, every escalation, everything that was allowed or held back: it's all in one place.

Evidence, the Agent Governance Evidence Pack. Assembled later, across many runs. This is where you get to show your work: not "trust us, we have controls," but "here's proof: 40 sends needed sign-off this month, and here's what happened to each one."

Walking the scenario through the stack

The manifest declares that sending an email requires authority and escalates rather than executing automatically, decided before the agent ever runs a single task.
Mid-run, the Control Plane checks each of the agent's proposals against the manifest as they happen: pulling top customers and drafting a reply go through, pulling contract details is blocked outright, and the proposed send doesn't execute, it escalates and gets held for a person to review. Every one of those outcomes gets recorded as it happens, not just the one that got stopped.
When the run ends, every step (the reads, the draft, the block, the held send, and the outcome) gets packaged into a replay bundle.
Over time, those bundles roll up into an evidence pack: not "we think our agent behaves," but "here's the record of every send this month that needed sign-off, and what happened to it."

A thousand cringey emails to customers drops to zero. There are no questions about why, no furious Slack thread trying to piece it together. And if anyone does wonder, the stack's replay bundle provides the paper trail.

See it yourself

The Open Control Stack, Cognous's first release, is fully open source, and everything above (the manifest fields, the allow/block/escalate decisions, all of it) comes straight from the actual code, not a slide deck. If you want to see AI agent governance in action instead of taking our word for it, the manifest, control plane, replay bundle, and evidence pack repos are all live on GitHub. Clone one, run the examples, watch a proposed action get authorized, blocked, or escalated in real time. You can learn more about Cognous at cogno.us.

This is the first post in a series on AI agent governance. Next up, we build the manifest from this exact scenario: the real schema, the real validation rules, and what runtime authorization for AI agents actually looks like as working code. From there we'll get into the AI agent control plane that enforces it and how a single run turns into replayable AI agent evidence you can hand to an auditor. More posts coming soon.