Coco, run for you

Your team wants agents doing real work, and your compliance team wants proof that every action was checked against your rules before it happened. Coco is that check. It runs outside your agent, on Coco's infrastructure, and your harness asks it one question before every action.

No package tree installs inside your codebase. The checker, your contract and the evidence all live on the service, and the one thing you take is the single-file client, which your compliance team can read in one sitting. A workflow platform with no code takes nothing at all. The only engineering on your side is one call at the point where tools execute.

The workflow

1  You send what you have      policy documents, sample cases, the agent's prompt
2  Coco drafts your contract   every rule cites the policy sentence it enforces
3  You review and approve      on your dashboard, as a graph and as a list
4  Your gate goes live         observe mode, two URLs and two keys arrive
5  You connect your agent      six lines of code, or one web request per step
6  You turn enforcement on     after the observe report, one setting flips

Steps 1 to 3 happen with us, and starting is a conversation rather than a form, so begin at trustcoco.ai. Steps 4 to 6 are yours. Each step below says what you do, what you get back, and how you know it is done.

1. Send what you already have

You share a folder holding four things. The policy documents your team already follows. A few sample case files, so the rules can name the real folders and markers your workflow uses. The prompt your agent runs on. And the constraints you care about most, written in your own words, for example that a person signs every approval.

Nothing needs rewriting for Coco. The policy stays the document your risk committee approved. This step is done the moment the folder is shared.

2. Coco drafts your contract

An authoring agent reads what you sent and drafts your behavioural contract, which is a set of plain rules your team will own and version like a document. Every drafted check carries a citation naming the policy file and quoting the sentence it enforces, so your reviewer can hold the draft against the policy line by line.

The draft passes three checks before you see it, and none of them involves a model. The schema has to parse, every rule has to compile under a deliberately small expression language, and the draft is run against your sample cases so you can see which way it decides before anyone relies on it. A rule that fails any of these is rejected rather than written.

A drafted contract enforces nothing. It sits in a drafts area the gate refuses to load, and moving it out of drafts is a person's decision, never Coco's. This step is done when the draft appears on your dashboard for review.

3. Review it on your dashboard

Your dashboard shows the contract two ways. As a list, where each rule reads in one sentence what it checks and why. And as a graph, where every check is a box and a line runs from each box to the verdict it returns when it fails. A compliance officer can see the whole contract on one screen and point at the rule they would change.

You mark up, we revise, and you approve. What you approved is compiled and sealed into your own container image, and that image is fingerprinted, so an auditor can later pin the exact contract version that governed any given decision. This step is done when you have said approve, in writing.

4. Your gate goes live, watching first

Your gate starts in observe mode. It records the verdict for every action and stops nothing, so a rule drafted too tightly shows up as noise in a report rather than as a stopped workflow. Four things arrive.

gate            https://gate.trustcoco.ai/yourname
dashboard       https://yourname.dash.trustcoco.ai
API key         goes into your agent platform's secrets, never into code
dashboard key   the browser password for whoever reviews decisions

The two are shaped differently on purpose. The gate is an API, so it takes a path prefix under one name. The dashboard is a browser application whose shell asks for its assets at the root of the host, so it gets a name of its own with its own certificate. Architecture has the measurement behind that.

Check the gate is up before anything else. This needs no key.

curl https://gate.trustcoco.ai/yourname/health

{"status": "ok", "mode": "observe"}

Then open the dashboard in a browser. It asks for a login, any username works, and the dashboard key is the password. You see your contract as the graph and the list, and a receipts feed that is empty until your first call.

Data stays in Australia. The service runs in Sydney, and what reaches it is the description of each proposed action, not your customer database. This step is done when health answers and the dashboard opens.

5. Connect your agent

Your engineer puts the check at the one place that executes tool calls. The client is one file with no dependencies, and SDK has the full reference.

from coco_gate import CocoGate

gate = CocoGate("https://gate.trustcoco.ai/yourname", api_key=key, session_id=run_id)

verdict = gate.check("payment.send", {"amount": 25000, "payee": payee})
if verdict.allowed:
    execute()
elif verdict.escalated:
    park_for_a_person(verdict.reason)
else:
    refuse(verdict.reason)

A workflow platform with no code at all does the same with one request per step.

While the gate is observing, every answer is an ALLOW and the reason says so plainly. The verdict the contract reached is on your dashboard, in the receipts feed, within a second of the call. Send one test call and watch it land there. This step is done when you can see it.

6. Turn enforcement on

After a period in observe mode you read the catch report with us. It groups everything enforcement would have stopped, by the rule that would have stopped it. A rule firing constantly on ordinary work is drafted wrong and gets fixed. A rule that caught something that should not have happened is your argument for turning enforcement on.

When you say so, one setting changes on your gate, and nothing changes in your code. From that moment the same call comes back like this, and the call does not run.

{"verdict": "BLOCK", "reason": "Coco: The command is a destructive operation with no safe reading in a governed workflow", "mode": "enforce"}

Watching it run

The dashboard opens on Live. Across the top, the verdict count, the block rate, the escalations waiting and whether the receipt chain verifies, and under them the feed of verdicts as the gate writes them, allows included. Clicking any row opens the receipt whole, with the rule that fired, every check that ran, the state the gate read and the contract source scrolled to the failing line.

Contracts, the escalation queue and the full receipts table are their own views, and the table filters by verdict, searches by reason and exports as CSV.

An escalation is the gate saying a person has to decide this one. The item shows what the agent wanted to do, the rule that paused it and the reason in a sentence. Whoever holds the dashboard key clicks approve or deny and writes one line saying why, and that line goes on the record next to the receipt. The agent waits. It cannot approve itself, and silence is not a yes.

When a call is stopped

The agent receives the refusal and the reason in one sentence, for example that this session has already read a customer file, so sending data out is not authorised. A well built agent reads that and takes a different path. The person watching sees the same sentence on the dashboard, next to the rule that fired and the exact action that was attempted.

Both halves of a bad sequence can be innocent. Reading a case file is the work. Sending a summary out is the work. Coco keeps session state, so it sees the pair, and the receipt shows why the pair was refused when each half alone was fine.

If Coco is unreachable

With enforcement on and the client at its default, your agents stop until the gate answers, because a check nobody answered is not an allow. That is the honest cost of a hosted checker, and you choose it rather than discover it. In observe mode, fail open and nothing interrupts you.

Deciding a call is quick. The measured figures are in What it costs, and your network round trip to Sydney is on top and is one curl away to measure.

Questions that come up

Can the agent talk its way past a verdict. No. The gate never sees the conversation, only the proposed action and the recorded state, so there is nothing for an argument to reach.

Does a model decide anything at runtime. No. A model drafts the contract once, a person approves it, and the runtime check is plain rule evaluation. Same call, same state, same answer, every time.

Who writes the contract. Coco drafts it from your documents, your reviewer approves it, and every check cites the policy sentence it came from. Changing a rule is a new version, reviewed the same way.

What if our data cannot leave our infrastructure. The same gate ships as a container image for exactly that case, and Self-hosted covers it. The hosted service is the faster road and most teams start there.

What does our agent vendor have to change. Nothing structural. The check is one call at the point where tools execute, and platforms without code can gate a workflow step with a single web request.