The safest AI system is not the smartest one. It is the one that cannot do the wrong thing even when it is wrong — a harness that hands out narrow jobs, checks the result with something that was not the worker, keeps the approve button in a human's hand, and writes a receipt for every action. This is the pattern, with a working fleet as the worked example.
There are two common ways to build with AI agents, and both are bad. The first lets the agent do almost nothing, so it is safe and useless. The second hands it broad credentials and a free-form shell, so it is powerful and dangerous — and the danger does not show up in the demo. It shows up on a Tuesday when the agent deploys the wrong folder to the live site, or invents a URL in a report, or, having read a web page that told it to, quietly emails a file somewhere it should not go.
The agent harness is the third way. The agent can see everything relevant, propose exactly what it wants to do, and touch nothing until a check passes and a person says yes. A harness is not a smarter agent. It is a smaller job, an independent reviewer, and a receipt.
This article is the general pattern. The worked example throughout is the fleet Artificial Mind Hive runs on its own products — WALO, Service Pricer, Agent Book, and the open-source Walrus Tusk hub — because it is the one whose record NU can check line by line. Nothing Unseen shares a publisher with all of them. The standard here is receipts: the public pages, the public repository, the live Agent Board, and the founder's build log, including the failures.
The Artificial Mind Hive homepage on a desktop screen: "Many states. One release." and the studio's method line. The products below it are the fleet this article uses as its example.
The problem owners actually have
Picture an owner — a contractor, a shop, a one-person studio — who wants an AI to do real work: change the hours on his website, fix his email authentication, draft a hundred pages, check that a deploy went out. Three things go wrong, and they are the same three things everywhere.
It drifts. Given a big job and a long leash, a model wanders. The job was "update the hours"; the result is a rewritten homepage with a new tagline, because the model decided the page could be better. Nobody asked, and nobody reviewed.
It invents. On October 20, 2026, one agent in the AMH fleet reported that it had published a preview page and pushed a branch. Neither existed. A second agent, assigned the same day to check the first one's work, caught it before the owner saw it. The founder's note on the incident was that he should have caught it too, before telling the owner — and the fix was structural, not a stern prompt: every claim of "published" or "live" in an agent's report is now fetched from the hosting provider and marked passed or failed in the report itself.
It writes without review. The AMH homepage was buried four times in three weeks of late summer 2026 by AI sessions holding a full-power hosting token, each running a plain deploy command against the wrong project. The fix was not a better model. It was renaming the production branch so the default deploy command cannot reach the live domain, plus a guard that checks the live page title and rolls back.
Underneath those three is the one the security people name: an agent that reads untrusted content (a web page, an email, a customer's message) and has both private data and a way to send things out will eventually be talked into leaking the one through the other. No prompt fixes that. Structure does.
The owner's real requirement, then, is not "a smarter agent." It is: show me the change before it happens, let me approve it in one tap from my phone, check that it actually worked, undo it if it did not, and keep a record I can read. That is a harness.
How the industry handles it today
The best public writing on this has converged on the same shape from different directions.
Anthropic's "Building effective agents" (December 2024) draws the line between workflows — where code orchestrates models through predefined steps — and agents — where the model directs its own process — and advises starting with the simplest composition that works. Its catalog of workflow patterns includes orchestrator-workers (a central model breaks a task into subtasks and delegates), and evaluator-optimizer (one model produces, another evaluates in a loop), and it recommends human checkpoints at points of risk. A harness is an orchestrator-workers workflow with an evaluator and a human gate bolted on.
The research on self-checking is sobering. Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet" (2023), found that asking a model to review its own answer without external feedback often made it worse, not better. Dhuliawala et al., "Chain-of-Verification Reduces Hallucination in Large Language Models" (2023), found the gains come from drafting independent verification questions and answering them separately — that is, from structure that keeps the check at arm's length from the draft. Yao et al., "ReAct" (2022), showed that interleaving reasoning with tool observations grounds a model in what the world actually returned. The lesson for a harness: the verifier should be a different pass, preferably a different model, and wherever possible not a model at all.
The security frame. The OWASP Top 10 for LLM Applications names prompt injection and excessive agency as headline risks and recommends least privilege, human-in-the-loop for high-impact actions, and limiting the tools an agent can call. Simon Willison's "lethal trifecta" — private data, untrusted content, external communication — is the one-line threat model. The NIST AI Risk Management Framework organizes the same concerns into govern, map, measure and manage. And the oldest guidance is still the clearest: Saltzer and Schroeder's 1975 principles of least privilege and separation of privilege — give each program only what it needs, and require two independent conditions for the sensitive thing.
The operations frame. Site reliability engineering solved the "did the change actually work" problem years ago: canary releases that expose a change to a small slice and check real signals before full rollout, release engineering that makes rollbacks cheap and routine, and the rule that a deploy is not done until a check that is not the deployer says it is done. Hosting platforms make the undo cheap; Cloudflare's Pages rollbacks restore a previous deployment in one call.
The logging frame. NIST SP 800-92 on log management covers what to keep and why. RFC 6962, Certificate Transparency, is the canonical design for an append-only log whose tampering is detectable — the strong version of what a harness audit chain does locally.
The substrate. The Model Context Protocol, announced by Anthropic in November 2024, gives agents a standard way to call named tools with typed arguments. That is what makes "bounded tools instead of a shell" practical: the harness exposes exactly the tools it means to, and the agent cannot call anything else.
What the industry has not done much of is put all of it together in one small system an owner can run from a phone. That is the worked example.
How the harness does it
The pattern has nine parts. Each one below is stated generally, then shown as it exists in the AMH fleet.
The hive cards on artificialmindhive.com. The Walrus Tusk card is the harness in one sentence: jobs, not chats; objective, limits, receipts; risky writes wait for one human click.
1. The job packet
A harness never hands a worker "the project." It hands a packet: a specific objective, the sources it may use, hard limits (no writes, no browsing outside this list, this many turns), the required output shape, and the evidence it must return. The packet is small enough that a cheap model can do the job and small enough that a reviewer can tell whether it did.
In the fleet, the hub's harness records every job as a hashed packet, so the job's terms cannot be quietly changed after the fact. A front-desk agent (the docs call him Jack) splits an owner's request into pieces for specialist profiles. Fourteen skill playbooks — safe deploys, live checks on phone and desktop, landing rollback, mail loopback, lean handoffs, security review, research with real sources, and so on — attach themselves to a job when it matches, so the worker gets the relevant rules without the whole manual. A "landing guide" preflight briefs each worker with its target, limits and hard-no list before it starts.
2. Bounded tools, not a shell
The worker gets named tools with typed arguments, and nothing else. No shell, no arbitrary HTTP, no file system. Each tool has a policy: allow, approve, or block. Reads are allowed. Writes dry-run by default and return a diff. Deletes require their own explicit confirm.
In the fleet, the tools are the Walrus Tusk hub's MCP catalog — about fifty built-in, more federated — and every mutating tool is a dry run unless the call carries an explicit apply flag. Git access is fenced to agent-prefixed branches with no force pushes, no branch deletes, and no edits to the workflow files that run the agents. When an outside agent destroyed a Worker through a raw execute tool in October 2026, the fix was one policy line blocking that tool, and it has stayed blocked. Each agent holds its own revocable key; outside agents get no hub key at all.
3. The independent check
The worker's result is not accepted because the worker says so. A second pass tries to refute it. The best second pass is not a model: an HTTP fetch that checks for a 2xx, no redirect, and an expected marker on the page catches the most common failures — "the deploy succeeded" when the page now serves the wrong site, "the page is live" when the URL 404s — with zero AI cost and zero chance of being talked into agreement. Where a model is needed for the check, it should be a different model with a different prompt that does not see the worker's reasoning.
In the fleet, the deterministic checks are explicit: a verified deploy gate requires an explicit 2xx, rejects redirects, and can require a release marker; a site-health check can require expected text, which is exactly the check that would have caught the AMH homepage serving a different product with a cheerful 200. The harness runs a verifier pass with a separate small model. And since October 20, the cloud runner reads every URL an agent claims to have published, straight from the hosting provider, and stamps the report "Live check passed" or "Live check failed," handing a failure to a different agent.
The docs page at artificialmindhive.com/wtdocs. "Deterministic verification" is the term the project uses for the check that is not a model.
The fleet also uses agents to check each other, which is a weaker but useful form of the same principle: on the founder's instruction, one agent was assigned to pass-or-fail another's day of work against the live site, and a third was asked for a ship-or-fix vote. The second agent returned "fix first" over a numbering mismatch the first had missed. That is the evaluator-optimizer loop with the evaluator genuinely independent.
4. Approval in a human hand
The harness surfaces the proposed change in a form a person can read in ten seconds — a diff, a before/after, a one-line summary with a link — and waits. Approval is one tap. Nothing that changes the world happens without it, and the approve step should be rare enough that the human actually reads it.
In the fleet, the apply flag is the gate for every write. For an owner on WhatsApp, approval is a reply: "yes," "1," "2 but shorten it." A team job — "everyone: draft a landing idea" — collects proposals and votes, but nothing ships until the owner texts "team go." WALO's own homepage sample ends the way the whole system is designed to end: "Nothing sent until you say send."
The crew section on walohq.com. "With a rollback ready" is the harness's promise stated for a phone user.
5. The receipt
Every action leaves a record that was not written by the worker: what was asked, which tool was called with which arguments, what the dry run showed, who approved, what the check returned, what it cost. The record should be tamper-evident — hash-chained, so an altered line breaks the chain — and it should be readable by a person without a terminal.
In the fleet, the MCP server appends one JSON line per applied change — timestamp, action, domain, record, before, after, never the token. The harness keeps a hash-chained event log in one Durable Object per user. Each cloud job writes its token count and estimated cost as the first line of its report, and WALO answers "tasks today" and "spend week" from those. The public Agent Board shows an anonymized feed of every job with its status — including Failed, which the fleet does not hide. And since late October, WALO records the result of every WhatsApp send — the message ID the provider returned, any error code, and delivery callbacks — because the founder learned that "accepted" is not "delivered," and a missing reply should be diagnosed from a receipt, not a guess.
The Agent Board at phone width on November 1, 2026. The feed is the public half of the receipt.
6. Continuity without the whole history
A cheap worker cannot carry the whole project in its context, and should not; the more it holds, the more it can leak and the more it can drift. The harness keeps a compact memory — the owner's setup, the last few decisions, what is in flight — and hands each worker only the slice it needs. Old chatter expires on a schedule; decisions and receipts are kept.
In the fleet, that is the "continuity keeper": a briefing retained on a 4/7/30-day window, bulky evidence expiring first. Every cloud job starts with a short brief about the owner and his last dozen WALO messages for context. Handoffs between agents are capped at three hops so a job cannot bounce forever. Quick questions take a read-only lane with a small turn budget; site jobs take the careful lane with the full tool set. When one agent's quota runs out — Grok and Gemini both hit limits in October — the job is handed to another with the brief, not restarted from nothing.
7. Rollback is a first-class move
The harness assumes the check will sometimes fail, and makes undo cheap and automatic. The previous good state is captured before the change; a failed check restores it without asking; the report says so.
In the fleet, the site-patch tool snapshots the live deployment's manifest, applies the change, runs the health check, and rolls back on failure. The first real rollback fired on October 15, 2026 — a patch with the wrong expected page title — and worked. A separate guard watches the live homepage title and can restore the last good deployment in seconds. And there is a rule from the record that belongs in every harness: when migrating a service, never tear down the old path in the same step; an eleven-day outage in August came from pointing configuration at a hostname that an earlier cleanup had already deleted.
8. A front door for strangers
Outside agents — someone else's Grok bot, a partner's assistant — should be able to join the system without receiving any of its power. They get a separate, narrow door: join, check in, post a note, set a status, and wait for the owner to approve them. They never get the key that can edit DNS or sites.
In the fleet, that is Agent Book's own MCP endpoint. A guest joins with its own key, sits in a pending state until the owner approves, and then appears on the roster as live or idle depending on whether it has checked in recently. The founder's rule is written down: the hub key can edit DNS and sites, so it must never go to outside agents; this is the safe front door.
Agent Book at amhagentbook.com: the plain-English view of what each agent is doing, who it hands to next, and what it needs from the owner. The "Hit a limit — it stopped rather than burn the rest on weak ideas" card is the harness ethic on a sticky note.
9. Honest labels and honest cost
A harness should say which model did the work and what it cost, every time, and should never upgrade silently. If a free-tier model ran the job, the record says so; the paid lane is a visible switch.
In the fleet, the landing page names who does what: Claude, Codex, Grok or a Grok Bot drives the job; Gemini helps with pictures and research; bounded steps run on a free small Llama by default with a paid Kimi K2 lane as a labeled profile; local Ollama models join from the owner's PC when it is on. Token spend is the first line of every report.
The FAQ at artificialmindhive.com/wtfaq, at phone width. The first three answers are "No," "No," and "Never," which is the right order for a harness to answer in.
Under the hood, in plain English
Read the parts above as one line and the architecture falls out: channel → coordinator → job packet → worker → bounded tools with policy → independent check → human approval → apply → live check → rollback if needed → receipt.
Where each piece runs, in the fleet, without any secrets:
- The channel is WhatsApp through WALO, or an AI app with a custom connector, or a terminal. Only an owner's message can start a job.
- The coordinator is one durable object per user on Cloudflare's edge — a small stateful program that holds that user's queue, schedules, audit chain and crew roster, and nothing of anyone else's. Durable Objects are the natural home for "exactly one of these per user, with its own storage."
- The workers are cloud runners on GitHub Actions, woken by a one-line commit to a dispatch branch when a job is posted, each running the agent's own command-line tool under the owner's own subscription. They have no shell access to anything but their own scratch space, and they can only act through the hub's tools. When hosted minutes run out, the same workflows run on self-hosted runners on the owner's PC with a single variable flipped.
- The tools are the Walrus Tusk hub, a Cloudflare Worker that holds the hosting token server-side, exposes named operations over MCP, checks a per-tool policy before every call, rate-limits with an exact counter, and dry-runs writes. The agent harness is a second Worker reached only over a private service binding.
- The checks are plain HTTP fetches with expected status, no-redirect, and expected-marker rules; a small verifier model where judgment is needed; and, for published claims, a read-back from the hosting provider.
- The receipt is a JSON line per applied change on the hub, a hash-chained log per user in the harness, a public anonymized feed on the Agent Board, token spend per job, and WhatsApp send receipts in WALO.
The edge is a good fit for this not because it is fashionable but because the pieces are tiny and the state is per-user. A harness coordinator does almost nothing most of the time; it waits for a job, hands out a packet, and records a result. Paying for an always-on server to do that is waste. One durable object per user, waking on demand, matches the shape of the work. The one thing the edge cannot do is reach a model on a user's laptop, which is why the fleet's local lane is a small program on the PC that claims jobs and posts results, not a Worker calling localhost.
What it costs, and what is free
The pattern costs nothing; it is a way of arranging things you already have. AMH's implementation is open source under the MIT license.
Running it: a self-hosted hub fits inside Cloudflare's Workers Free plan (100,000 requests a day, 10 ms CPU per request); the Paid plan starts at $5 a month and is required for some larger models on Workers AI. Cloud workers on GitHub Actions draw on the included monthly compute allowance GitHub's billing page lists for free accounts, then per-minute rates; self-hosted runners cost whatever the machine already costs. The agents' own reasoning runs on the owner's existing AI subscriptions rather than per-token API keys.
The real cost of a harness is the owner's attention, and a harness that asks for approval forty times a day will be ignored forty times a day. The design goal is few, legible approvals: dry runs that read in one glance, checks that are automatic, and a default of "read-only unless asked." The fleet's "one request, one agent, one saved result" line on the WT page is that goal stated as a rule.
Honest limits and what is still being built
A harness does not make the agent smarter. It makes the agent's mistakes smaller and visible. A worker in a harness still drifts, still invents, still gets prompt-injected by a web page it was told to read. The harness ensures that the drift is bounded by the packet, the invention is caught by the check, and the injection cannot reach a write without a human. It does not ensure the work is good.
The check only catches what you check for. The AMH homepage served a different product for hours with a perfectly good 200 status because the guard checked status, not title. The fix was to check title. The next failure will be something the check does not cover yet; the record is a list of checks that were added after something slipped past.
Tamper-evident is not tamper-proof. A hash chain lets a reader detect an altered log. It does not stop the operator of the system from altering it. The witnessed version — RFC 6962's public, append-only, externally monitored logs — is the honest upgrade, and the fleet does not have it.
Humans approve wrong things. Every approval gate assumes the human reads the diff. The fleet's own record includes the founder approving a change and then asking for it to be undone the same day, because his instruction was misread — "I need old, not new." A harness makes that reversible; it does not make it impossible.
Agents check each other imperfectly. Cross-agent review caught a fabricated page and a numbering error. It also, in the same week, produced one review that was simply out of quota and had to be handed off. Independent verification is only as independent as the verifier's budget.
The free lane is weak. A free small model does extraction and comparison well and judgment badly. The fleet labels it honestly; the labeling does not make it stronger.
Quotas are a real failure mode. Grok ran out of credit; Gemini's free key hit its rate limit; GitHub's hosted minutes ran out at month end. Each produced a handoff or a lane switch rather than a crash, which is the harness working — but a harness built on free tiers is a harness that will pause at inconvenient times.
The rollback path is lightly tested in production. It has fired correctly once, on a real mistake. It has not been deliberately failure-tested against the main AMH site.
The pattern was learned the expensive way. Four homepage burials, an eleven-day outage from a premature teardown, a fabricated phone number in a customer reply, a bot that set reminders in the wrong timezone, a payment email library that reported success on failure. Every one of those is in the founder's record and every one of them became a rule. That is the strongest argument for the pattern and the most honest description of how it was arrived at.
Still being built, per the public docs and the record: server-code deployments for self-serve users, a first-class local-model lane, automatic backups of agent-written content, and the externally witnessed log.
A 30-day playbook
For a team that has one autonomous agent and wants a harness around it:
Days 1–3: Inventory the blast radius. List every credential the agent can reach and every write it can make. For each: could this delete a site, send a message, move money, or leak a file? Those are the writes that get a gate. Write the list down; it is the first page of the receipt.
Days 4–7: Take away the shell. Replace open-ended access with named tools over a protocol — MCP if your agent speaks it. Each tool does one thing. Writes dry-run by default and return a diff. Deletes require a separate confirm. If a tool cannot be made to dry-run, it goes behind "approve."
Days 8–10: Write the packet template. Objective, allowed sources, hard limits, output shape, evidence required, turn budget. Try it on your three most common jobs. If a job does not fit in a packet, it is two jobs.
Days 11–14: Add the check that is not a model. For every write that touches something public: fetch it afterward, require the status you expect, reject redirects, require a marker. Make a failed check roll back automatically. Test the rollback on purpose, on a test target, before you trust it.
Days 15–18: Add the human gate. Route every approve-policy write to a place the owner already looks — a chat, a phone. Make the message a diff and a one-line summary. Measure how many approvals a day you are asking for; if it is more than a handful, raise the dry-run default and lower the ask.
Days 19–22: Add the receipt. One line per applied change, never containing a credential; a hash chain if you can; cost per job; a feed of job outcomes that shows the failures. Read it daily for a week.
Days 23–26: Add the second pass. A different model, a different prompt, no access to the worker's reasoning, asked to refute the result. Or a second agent assigned to grade the first. Keep what survives.
Days 27–30: Open the front door, narrowly. If outsiders need in, give them a join-and-approve endpoint with read-and-note tools only. Never the key. Then decide, from the receipt, whether the harness earned its friction.
Frequently asked
Is a harness just a prompt that says "be careful"? No. A prompt is advice to the model. A harness is structure around it: tools it cannot exceed, checks it cannot talk its way past, an approval it cannot grant itself, and a log it did not write.
Does this slow everything down? Yes, by design, at the writes. Reads run immediately. The dry-run and check add seconds; the approval adds however long the human takes. The fleet's quick lane answers plain questions in about half a minute; site jobs take minutes. The alternative is faster right up to the deploy that buries the homepage.
Can the worker see the whole codebase or account? It should see what its packet allows and nothing else. In the fleet, workers have no shell, no secrets, a browsing allowlist, and tools scoped to the owner's own accounts.
Why not one strong model with a good prompt? Because the research says models are bad at checking themselves, the security guidance says to limit agency, and the record says a strong model with a strong credential will eventually make a strong mistake. A harness lets you use a cheap model for the bounded work and spend the strong one on judgment.
What is the minimum viable harness? Named tools, dry-run by default, one human approve step on writes, one non-model check afterward, one log line per action. Everything else — verifier models, continuity, rollback automation, the front door — is an upgrade.
What happens when a check fails? The change is rolled back to the captured previous state and the report says so. In the fleet, that is automatic for site patches and the report lands on WhatsApp.
Who approves when the owner is asleep? Nobody, which is the point. Jobs that need approval wait. Jobs that do not — read-only watches, drafts, research — run around the clock with zero write capability.
Can outside agents use the system? Through a separate, narrow door: join, check in, post, wait for approval. Never through the key that can write.
Is any of this specific to Cloudflare or GitHub? No. The fleet runs on them because one durable object per user and on-demand runners fit the shape of the work. The pattern is hosting-agnostic.
Where is the pattern's own record? In the public repository's commit history, the Agent Board's feed, and the three companion articles below.
Where to learn more
- Cloudflare Ops MCP, Now AMH Walrus Tusk — the specific implementation: tools, credential model, the seven bugs, the harness Worker.
- Quote Follow-Up: Where Service Pricer and WALO Fit Together — the same posture ("nothing sent until you say send") in a contractor's WhatsApp.
- Service Pricer: The Contractor SaaS Built Around Quotes, Jobs, and Real Operator Pain — the business the fleet serves.
- The product pages: Walrus Tusk, the docs and FAQ; the public repository; Agent Book; the Agent Board on WALO; Artificial Mind Hive; and Apiary, where this article is mirrored.
Sources (the record)
- Anthropic — Building effective agents (Dec. 2024): workflows vs. agents, orchestrator-workers, evaluator-optimizer, human checkpoints — Anthropic
- Anthropic — Introducing the Model Context Protocol (Nov. 2024) — Anthropic
- Model Context Protocol — specification (2025-06-18) — modelcontextprotocol.io
- Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet" (2023) — arXiv
- Dhuliawala et al., "Chain-of-Verification Reduces Hallucination in Large Language Models" (2023) — arXiv
- Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (2022) — arXiv
- OWASP — Top 10 for LLM Applications (prompt injection, excessive agency) — OWASP GenAI Security Project
- Simon Willison — The lethal trifecta for AI agents (June 2025) — simonwillison.net
- NIST — AI Risk Management Framework — NIST
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls (least privilege, separation of duties) — NIST
- NIST SP 800-92 — Guide to Computer Security Log Management — NIST
- RFC 6962 — Certificate Transparency (witnessed append-only logs) — RFC Editor
- Saltzer & Schroeder — The Protection of Information in Computer Systems (1975) — MIT
- Google SRE Workbook — Canarying Releases — Google
- Google SRE Book — Release Engineering — Google
- Cloudflare — Pages rollbacks — Cloudflare
- Cloudflare — Durable Objects — Cloudflare
- Cloudflare — Agents SDK — Cloudflare
- Cloudflare — Workers limits (Free plan) — Cloudflare
- Cloudflare — Workers pricing — Cloudflare
- GitHub — GitHub Actions documentation — GitHub
- GitHub — Self-hosted runners — GitHub
- GitHub — Billing for GitHub Actions — GitHub
- AMH WT (Walrus Tusk) — public repository and README — GitHub
- Walrus Tusk — product page — Artificial Mind Hive
- Walrus Tusk — documentation — Artificial Mind Hive
- Walrus Tusk — FAQ — Artificial Mind Hive
- Artificial Mind Hive — studio homepage — AMH
- Agent Book — agent roster and outside-agent front door — AMH
- WALO — Agent Board (public job feed) — WALO / AMH
- WALO — homepage (the WhatsApp crew, "Nothing sent until you say send") — WALO / AMH
Originally published on Nothing Unseen, an Artificial Mind Hive (AMH) site. AMH is owned by Austin Little. Product pictures are screenshots of the live sites; tap any picture to open the product.