Governed multi‑agent delivery — not unsupervised automation.
We install a governed fleet of AI agents that does the verifiable labour of running a business — software, operations, sales, or support — while two humans — one business, one technical — hold the two judgment gates a machine cannot sign. Software is how we practise the method on ourselves. High autonomy and safety become the same design — not a trade‑off.
A capable owner + many agents fails in two predictable ways
AI agents let a small team run work at team‑of‑many scale. The naïve setup breaks — in opposite directions — whether the work is software, operations, or a client process.
Review everything
The owner inspects every output, becomes the bottleneck, and the agents sit idle. Safe — but no faster than one person plus one chatbot.
Review nothing
Agents drift: they tick the letter of the brief and miss the intent, quietly pull in tools you never approved, wander outside scope, and follow orders hidden in text a stranger wrote.
Seven rules the whole system re‑derives from
Most of the machinery below can be reconstructed from these. They are the constitution — true at every step. Engineer terms sit in the decoder at the bottom of this page.
Two humans, two fields
Judgment is split across two accountable people — one for business, one for technical. Between their two gates, everything is done by agents under rules. No third human is needed; no agent may sign for either.
Independence stops where you cannot check
An agent only works alone if the result can be checked automatically. No check → no independence. So the checks are the highest‑leverage investment.
Catch a bad idea on the brief, not after the invoice
A flaw found at the start is ~10× cheaper than the same flaw found later. The hardest thinking sits on the brief, not on the finished artefact.
Small pieces, always
One sitting to build, minutes to review, easy to undo. Size limits are enforced by the gates — the loop keeps itself honest.
Checks catch; limits contain
Checks catch mistakes. If a check misses, the work is already in a sealed box, on a short leash, with a budget. Safety survives a missed check — the work does not reach the customer.
Incoming text is data, never an order
Every ticket, email, README and web page an agent reads is treated as untrusted. We clean it on the way in. The checker of the result never reads the raw file.
The fleet cannot rewrite its own rulebook
Agents may propose a rule change. Only a human publishes it. The one rule with no exceptions.
How one idea becomes shipped work
Four phases. Fifteen live steps, plus one we pull forward so you see the journey first (amber, dashed). Two human decisions (ringed in red). The artefact that flows is a locked work‑pack — what success looks like, what is out of scope, how a customer would click it, and how we will know it is done. Both the fast lane and the production lane build from that same pack. Once the pack is signed, it does not quietly change.
Idea
The owner writes the raw idea in one sitting — the problem and the outcome, not the solution.
LIVE
Hostile review
Assume it failed. Then: when would we abort, how could the brief be misunderstood, can it be smaller, is it worth the money?
LIVE
Second opinion
A different model, with a different way of thinking, checks the brief and writes an automatic check where the work is decidable. “Idea clear.”
LIVE
Work‑pack written
Product story, customer journey, what we will not do, and the tests that prove it. This pack is the source of truth — not the later code.
LIVE
Click‑through / wireframe
The owner clicks the journey like a customer. Scope that is not on the screen cannot sneak into a ticket later. A working HTML mock, not a slide deck.
DRAFT · in design
Pack locked
After the click‑through, the work‑pack is signed. Negative qualifiers stay in. Changing the pack later is a new idea, not a quiet edit.
DRAFT · in design
Ticket created
The locked work‑pack becomes a ticket (parent + sub‑issues). It enters the backlog. The click‑through is attached.
LIVE
Can we actually do this?
A reviewer who was not in the room that invented it gives a thumbs‑up, a bounce, or two questions. Complex work escalates to a stronger model.
LIVE
Worth it vs hard
Priority × difficulty × business value. Labelled and sized so the sequence serves the P&L, not the loudest idea.
PARTIAL
Ready for this ticket
A ticket‑specific “ready” list — not a generic checklist. Missing proof stays in the backlog.
LIVE
Placed in a cycle
Ready work is put into a delivery cycle. Nothing starts because it is exciting.
LIVE
Rapid prototyping (vibe coding)
The feature is built fast from the locked pack and tried locally. You never touch the production branch.
LIVE coding standards · draft, in review
Owner acceptance
Does this do the job for a customer? A human clicks it. An AI cannot sign this gate. Feasibility was already cleared upstream.
HUMAN GATE · business
Productionise
Take what already works to production‑grade: make it run everywhere it must, parameterise what repeats, clear the debt — not a rewrite.
LIVE
Prove it, then demo
Automatic suites (unit, integration, “did we break yesterday”). Then the owner sees it again. Merge and release only after both.
HUMAN GATE · technical
Shipped
The work goes out — into the product, the process, or the client instance. Same method, different pack.
LIVE
Learn, write the rule
Every bounce becomes a written rule, a test, or a doc. Silence is not health. Easy fixes can be coded by the fleet; humans only spend time on what is worth it.
PARTIAL
Ask · Show · Ship: automation is earned, never assumed
Every class of work sits on a three‑rung ladder. Nothing jumps to “just let the agents run” on a hunch. It climbs only on recorded evidence. A single disagreement sends it back down — with a written lesson. And even the top rung is sampled: trust is never permanent.
You must approve first
The human gate blocks the work from going out. Everything starts here.
It goes out — you review after
The work delivers immediately. You review it later, in a batch. We record how often you disagree.
Trusted — runs on its own
Fully automatic under a strict written policy. You are not in the loop until something unusual happens — or until the sample check.
Trust by evidence, never by ambition. A class earns Ask → Show → Ship only through consecutive clean reviews — and a single disagreement demotes it, with the lesson written down. The system heals itself: it does not wait for a quarterly process review.
Three standing limits — in plain English
Checks catch mistakes. Standing limits contain what any agent can do if a check misses. Safety is designed to survive a missed check — the customer never sees the blast.
The three guardians
Write the rule, don’t ask for a feeling
If a decision can be a lookup or a formula, we write the rule. We do not ask an agent to “have a feel.” Cheap automatic checks run before the costly model.
Engineer: deterministic‑via‑code · checks before the modelLIVE · canonicalDon’t trust incoming text as an order
Tickets, emails and web pages are data, never instructions. Each agent gets the smallest key that does its job, and the key dies when the job ends. Agents can only call the systems you named.
Engineer: zero‑trust on data · sanitise intake · least‑privilege · egress allowlistLIVE · canonicalIf we’ll do it twice, make it a setting
Nothing decidable is hand‑built twice. A one‑off that will recur becomes a parameter, a config, or a fetch — not a hero rewrite.
Engineer: no throwaway · parameterise‑everythingLIVE · canonicalFour things that can go wrong — and what stops them
The helpful agent that still breaks it
Deletes the wrong thing or loops forever. It works in a sealed box we can kill; its death unclaims the work; size limits stop a runaway bill.
Engineer: sandbox + kill + resource limitsThe hidden order in a document
Someone (or a page) hides an instruction in text the agent reads. We clean incoming text. The agent can only call named systems. The person or agent who checks the result never saw the raw file.
Engineer: sanitised intake · egress allowlist · fresh‑context reviewerThe agent with the keys to the kingdom
Prevented from existing. No production data, no release rights, no secrets on the prompt. Secrets are injected into the box — the agent never sees them.
Engineer: short‑lived least‑privilege · secret injection, not prompt exposureThe poisoned plugin or library
A supplier update arrives with a trap. We pin exact versions. Any change to that lock list stops auto‑approve and needs a human look.
Engineer: supply chain · universal pinning · lockfile forfeits ShipPlus a second, independent reviewer network roadmap · not purchased yet — another set of eyes that does not share the first agent’s blind spots. And a watch the running system layer roadmap · iterative — dashboards and service promises (how fast, how often it may fail) added as we hit real problems, not as a big‑bang project.
A ticket, made real
The unit of work is a ticket carrying the locked work‑pack. Both the fast lane and the production lane build from this exact artefact — the pack is the source of truth, not the later implementation. The click‑through from the prototype phase is attached before this ticket exists.
Onboarding: unverified‑email reminder banner
As a new user, I want a clear reminder to verify my email, so I can finish setup without hunting for the original message.
- Click‑through / wireframe of the customer journey (prototype phase)
- Business story + product story + what we will not do
- How we will know it worked · how we undo it if it didn’t
- Tests written in the same language the release pipeline will run
Scenario: User has not verified their email
Given a signed‑in user whose email is unverified
When they open the dashboard
Then a "Verify your email" banner with a resend action is shown
Illustrative example. Ticket ID and field values are placeholders.
Four phases, two human gates
The whole pipeline as one strip — every step, grouped by phase, with the two human gates marked. The detailed operator table (entry / exit gates, tools, owners) lives in the internal reference.
✋ = a human gate — a person must sign (one business, one technical). Amber = in design: rapid prototyping & visuals, before a ticket exists.
The commercial case
Any business process, one engine
The same governed engine runs software and non‑software work — sales, support, operations, marketing — via swappable domain packs. Software is how we practise on ourselves. The method we install isn’t limited to code.
Spend follows the cost of a mistake
Cheap models execute low‑risk routine. High‑cost frontier is reserved for high‑business‑impact decision‑making. We account in units of work shipped, not in “we used the fanciest model.”
Reliable because it is checked, not inspected
Safety comes from automatic checks and sealed boxes, not from a human staring at every line. The main line heals itself on failure. Every mistake becomes a written rule so it cannot recur.
Your machines, your named connections, your rulebook
Nothing important is trapped behind a vendor screen. It runs on your infrastructure — your servers, your data, the systems you named, the rules you signed. Every client is an isolated instance sharing only the method.
It compounds, not plateaus
Every decision becomes a record, every outcome becomes evidence, every bounce becomes a rule. Throughput and quality improve month over month — the same method we sell is the method we use.
Where we are — honestly
KEEL is our target architecture. Here is the honest split, so nothing on this page oversells.
| LIVE today | Hostile shaping, the locked work‑pack, the board with a ticket‑specific ready list, feasibility by a reviewer who was not in the inventing room, fast lane → owner acceptance → productionise → prove + demo, two human decisions. |
| Partial | Automatic “worth it vs hard” scoring, write‑the‑rule capture after every bounce, formal Ask / Show / Ship mapping across every class of work. |
| In design | See‑it‑first click‑through before the ticket (rapid prototyping & visuals) — not a board state yet. Coding‑agent standards drafted and in review; they govern the rapid‑prototyping lane. |
| Roadmap | Independent second‑reviewer network (approved, not purchased), watch‑the‑running‑system dashboards and service promises (iterative, not a big‑bang), auto‑undo on a bad merge, graph reviews, higher‑tier board governance. |
We never claim: closed revenue, FCA status, guaranteed outcomes, or “full KEEL live in production.”
This is the method we sell and run — presented at the maturity it has actually reached.
If a CEO hears the engineer word
We lead with plain English. The engineer’s word is in brackets after it — precise for your technical team, invisible to everyone else.
| In plain English | Engineer’s word |
|---|---|
| Agents can only call the systems you named. Everything else is closed. | (engineer: egress allowlist) |
| Each agent gets the smallest key that does its job. The key dies when the job ends. | (engineer: least‑privilege credentials) |
| Standing limits on what an agent is allowed to touch — not a vibe, a written limit. | (engineer: guardrails) |
| A sealed box. If the agent goes wrong, the blast stays inside. We can kill the box. | (engineer: sandbox) |
| A poisoned library or plugin. We pin exact versions; a lock‑list change always gets a human look. | (engineer: malicious dependency / supply chain) |
| If a check fails, the work stops in the box. It does not reach the customer. | (engineer: short‑circuit / relay) |
| A human is in the loop — a person must decide. | (engineer: HITL) |
| Ready to start / done enough to ship. Written per ticket, not a generic poster. | (engineer: DoR / DoD) |
| The test written in the same English the release pipeline will run. “Given / When / Then.” | (engineer: Gherkin / Cucumber) |
| A written service promise (how fast, how often it may fail) plus a dashboard that flags a breach. Roadmap — iterative. | (engineer: SLO / observability) |
| Our fast lane: build quickly from a locked pack, tried locally. Governed by coding‑agent standards (drafted — in review). | (engineer: vibe coding / rapid prototyping) |
| Take what already works and make it production‑grade: runs everywhere it must, parameterised, no new debt. | (engineer: productionise) |
See the method run on your process
We install one governed engine, tuned to your workflow, on your infrastructure. Software is how we prove it — the same discipline runs your operations, sales, or support. Ask us for a walkthrough tailored to your business.
Book consultation