Agent control plane
Your agents already act.
Nobody wrote down what they are allowed to do.
Build the agent here. Deploy it into the stack it already runs in. Govern what it may touch, and track every action against the rules that authorised it.
Governing documents in force at this run
- system-prompt1.0.0
- task-instructions1.0.0
- behavioral-constraints1.0.0
- tool-use-policy1.0.0
- escalation-paths1.0.0
A control plane, not a dashboard.
Three agents, what governs each one, and the standing checks running against them. The two open findings below are real and they are against our own agents.
Build
Most agents have no governing document.
The control plane assumes one exists. Almost nobody has one, and the blank page is where the work actually stalls: a compliance officer will not author a tool-use policy from scratch, and neither will most engineers.
Four files take an agent that has a system prompt and nothing else and produce a governing document, a fixture suite and a baseline. They are published in full.
The governing document
Twelve sections. Scope, the corpus it must cite, which of its actions cannot be undone, who approves those, and the conditions that require a human. Each section carries the reason it exists.
The interview
The questions that fill it, split into what can be read out of the code and what can only be asked. Reversibility, approvers, acceptable escalation rate and cost asymmetry are policy. They live in a person's head and the only way out is to ask.
Clauses to fixtures
Every constraint produces at least one eval case, and every case names the clause it tests. A constraint with no case is decoration. A case with no clause is an opinion, and when it goes red nobody can say whether the agent broke or the test was always wrong.
The builder's own document
The agent that runs the interview, governed by the template it writes with. It holds no irreversible action and cannot promote a version. A system that exempts its own tooling is a policy for other people.
Published in full, and rendered from the same files a licensee receives rather than from a copy. A stale template on the page arguing that documents must stay in step with what they govern would refute itself.
Deploy
Agents run wherever they live.
An agent that already runs somewhere is not going to move. The control plane goes to it, and it never needs to see your data: it holds rules and records, your system holds the work.
import { createClient } from "./rulekeeper-client.ts";
const rk = createClient({ apiKey: process.env.RULEKEEPER_API_KEY });
await rk.run("allowance-classifier", { input: workOrder }, async (ctx) => {
const result = await yourAgent(ctx.systemPrompt, workOrder);
await ctx.recordAction({
toolName: "submit_overallowable",
arguments: { workOrderId: workOrder.id, amount: result.amount },
externalRef: result.confirmationNumber,
status: "succeeded",
});
return { outcome: "completed", output: result };
});{
"mcpServers": {
"rulekeeper": {
"command": "node",
"args": ["--experimental-strip-types", "./mcp/server.ts"],
"env": {
"RULEKEEPER_API_KEY": "rbk_live_...",
"RULEKEEPER_AGENT_ID": "allowance-classifier"
}
}
}
}It fails closed
If the control plane cannot be reached, or the agent’s document set is incomplete, the run does not start. An ungoverned agent producing plausible output is worse than an outage, because the outage gets noticed.
- 01
Your agent asks what governs it
Before it does anything, the agent pulls its five documents from here. It gets back the assembled instructions and the exact version of each one.
GET/v1/agents/claim-triage/governance- system_prompt
- "You triage inbound claims..."
governance_version_in_force
- system-prompt
- 1.4.0
- task-instructions
- 2.0.1
- behavioral-constraints
- 1.1.0
- tool-use-policy
- 1.0.0
- escalation-paths
- 1.2.0
A draft is never served here. An agent pulling its rules cannot be running an untested one by accident.
- 02
It runs, and reports what it did
The run is stamped with those versions the moment it opens. Every action underneath it records what came back and the identifier the receiving system issued.
POST/v1/runs/8f31c2/actions- tool_name
- "dispatch_adjuster"
- side_effect_class
- "irreversible"
- status
- "succeeded"
what makes it checkable
- external_ref
- "WO-88431"
- authorized_by
- escalation 214
A run citing a version this system never issued is refused. That is the difference between a record and a claim.
- 03
Someone changes a rule
Not a call. A person edits the document in the console and it saves as a draft that governs nothing. The eval suite scores that exact draft, and promotion is refused unless it holds at or above the standing baseline.
In the consoleGovernance workbench- candidate
- behavioral-constraints 1.2.0
- scored
- 41 / 46
- baseline
- 46 / 46
- promotion
- refused
The result is binding rather than advisory. A gate that reports and lets you through anyway is a report.
- Agent
- allowance-classifier
- Document
- behavioral-constraints
- Draft
- 1.1.0
- In force
- 1.0.0
Scored on the draft
9 / 11
standing baseline 11 / 11
Below the baseline, so the draft stays a draft. Nothing in production changed.
Fixtures the draft broke
escalate-out-of-season-winterize-tx
Winterization ordered in Texas outside the state season. The agent is required to refuse the classification and escalate. Under the draft it classified confidently.
hawaii-winterization-not-required
Winterization ordered in a state that has no winterization season at all. Same requirement, same failure.
Govern
Weakening a rule turns the suite red.
A governing document is edited the way production code is edited, and nothing about that is a metaphor.
- 01
Draft
The edit is written as a draft. It governs nothing: no run reads it and no agent behaves differently, and it can sit there for a week while the reviewer is on leave.
- 02
Score
The eval suite runs against that exact draft. Not against the current version, not against a copy that has since moved. Only a finished run counts as a score.
- 03
Promote
Promotion is refused unless a finished run scored that draft at or above the standing baseline. Refusal is the default, and it names the fixtures that broke rather than reporting a number.
The refusal above is a recorded event on the deployment described below, from a degradation introduced deliberately to confirm the gate fires. It is not an illustration.
A real governing document, at version 1.0.0, carrying its author, its reviewer, when it was amended and how many versions are on record. This is what a run is stamped against, and what the answer to a question about March is read out of.
Track
What governed this decision on the 14th?
Five things, each of which an examiner can ask for by name. Observability answers whether the prompt was any good. This answers the other question.
Agent registry
Every deployed agent with its owner, its stated purpose, what it costs to run, and the escalation rate it committed to. An agent drifting from its declared rate is a change to the business, and it surfaces as one rather than being discovered later.
Governing documents
Five documents per agent, each versioned, each carrying an author, a reviewer and the promotion event that put it in force. Every prior version is kept, because the question in March is what the document said in January.
- system-prompt
- task-instructions
- behavioral-constraints
- tool-use-policy
- escalation-paths
Runs and the rules in force
Every run stamps the exact version of every governing document that applied when it happened, with the reasoning steps and the escalations underneath it. Not the prompt as it reads today. The one that was actually applied.
The action log
What the agent did to the world, kept apart from what it was thinking. Each action carries its result and the identifier the receiving system gave back, so the record can be checked against a third party rather than believed. Anything irreversible names the approval behind it, and an approval granted during a different run is refused.
Evaluation harness
Fixtures with expected outcomes, scored against one specific draft. Escalating counts as a pass wherever the case expects it, because a suite that scores stopping as failure teaches an agent to stop stopping. An unfinished run is not a result and cannot stand in for one.
The conformance audit
Four things true for months without an alert.
We run the standing checks against the agents you already have and send you the findings. Not a trial: an empty console proves nothing, and the report is the part worth reading.
- grant.irreversible.no_gateAn irreversible tool grant with no escalation gateA tool that files, submits, pays or deletes, held by an agent that can reach it without a human in the path. The grant and its side effect class are both in the registry, so this is a query, not a review.critical
- agent.no_eval_baselineAn agent with no eval baselineIn production with nothing to regress against. Every future change to its governing documents is unmeasurable, and the first sign of a problem is the incident.warning
- agent.no_declared_rateAn agent that declares no expected escalation rateWithout a declared number there is no such thing as drift. An agent escalating on two runs in a thousand is either working correctly or was never wired to a gate, and nobody can tell which.warning
- Irreversible or external tools granted with no escalation gate behind them
- Agents with no completed eval baseline, so no change to them is measurable
- Agents that never declared an expected escalation rate, which therefore cannot be exceeded
- Declared rates that have never once been measured against production traffic
One deployment. Its real numbers.
A mortgage field services system running four governed agents against published HUD guidance, with a recorded regression history including deliberate degradations used to confirm the gates fire.
- 4
- Governed agents
- 20
- Governing documents
- 46
- Eval fixtures
- 2
- Fixtures that caught it
Each with a declared escalation rate
Five per agent, every version kept
All currently passing
Promotion refused, the draft never landed
Built for
- Mortgage servicing
- Insurance claims
- Healthcare revenue cycle
- Banking operations
- Title and escrow
Regulated operations deploying agents that take actions rather than make suggestions. The buyer is the person an examiner asks.
Start with the audit, not the console.
An empty console proves nothing. Point the standing checks at the agents you are already running and read what comes back.