Build the Process, Not the Prompt
Why dependable AI results come from roles, gates, verification, observability and human approval, and why a clever prompt was never going to get you there on its own.
Human-in-the-Loop
No Prompt Text Published
What This Page Is, and What It Leaves Out
This is a process brief. It explains how AI work gets planned, checked, approved, executed and audited so that the result is dependable. It deliberately contains no prompt text, no system instructions and no vendor-specific recipes. If you came for a magic paragraph to paste into a chat box, there isn’t one here, and that is the whole point.
Process, not prompts
The prompts behind my systems change weekly. The process around them has barely changed in a year. The process is the asset worth documenting.
Public-safe
No credentials, hostnames, model names or private data. Every diagram shows the shape of the system, not its configuration.
Sourced
Claims that rest on someone else’s research are footnoted. Where something is my own working opinion, it says so.
Prompt Tuning Plateaus Fast
Every team that puts a language model to work goes through the same arc. The first prompt is magical. The tenth prompt is a wall of exceptions. By the fortieth, nobody can say which sentence is holding the whole thing together, and the only way to test a change is to run it and hope.
That is not a skill problem. It is a property of the tool. Researchers who varied nothing but the formatting of a prompt, separators and casing and spacing, measured accuracy swings of about ten points on average across more than fifty tasks, with a worst case of seventy-six points. The sensitivity did not go away with bigger models, more examples or instruction tuning.[2] A hosted model you do not control can also drift under you: one study measured the same model’s accuracy on a simple math task fall from 84 percent to 51 percent between two releases three months apart.[13]
Reliability is a consistency problem
Benchmarks that run the same task repeatedly make the gap visible. On one widely used agent benchmark, a strong model solved under half the retail tasks on a single try, and when each task was repeated eight times the share solved every time fell below a quarter.[6] A demo that works once is not evidence of anything. A process that produces the same acceptable result on the hundredth run is.
Even the graders are inconsistent. When researchers asked a frontier model to judge two answers and then swapped the order, it stayed consistent only 65 percent of the time.[5] Any process that leans on a model to check a model has to account for that.
The practical conclusion: the prompt is one component with a known failure rate. Everything that makes the system dependable lives outside it.
What “the Process” Actually Means
A process is the set of decisions that are made in code, in roles and in review steps rather than in natural language. It answers five questions before any model is called.
Who may do what?
Roles with scoped tools and credentials. A research role reads. A publishing role writes to one place. Nothing holds every key.
What counts as done?
A schema, a rubric or a test the output must pass. If “done” is not written down, the model decides, and it will decide generously.
Where does a human sign?
Named gates before anything irreversible: sending, paying, deleting, publishing, changing access.
What happens on failure?
Retry rules, idempotency keys, escalation paths and a stop condition so a broken run cannot loop forever.
How will we know?
A trace for every run, a dashboard for every schedule, and an eval suite that reruns when the prompt or the model changes.
From Request to Reviewable Result
Below is the process I run every AI task through, whether it is a daily content job, a research assignment or an operations change. It has seven stages. The model is involved in three of them and holds authority in none.
| Stage | Who | What happens | Exit condition |
|---|---|---|---|
| 1. Intake | Code | The request is captured as a typed record: objective, scope, deadline, risk class, owner. Free text is kept but never executed. | Record validates against schema. |
| 2. Plan | Orchestrator model | Breaks the objective into narrow subtasks with explicit outputs and boundaries.[1][12] Nothing is executed yet. | Plan has no step that exceeds the risk class. |
| 3. Execute | Worker models | Each subtask runs with the least tools it needs, read-only wherever possible, in parallel where safe. Workers return structured results with sources. | Every result matches its declared format. |
| 4. Verify | Code, then a grader model | Deterministic checks first: totals, links, schema, banned words. A second model then grades against a written rubric, with order-swap to blunt judge bias.[5][11] | Score clears threshold or item is flagged. |
| 5. Approve | Human | For anything irreversible, the run pauses and shows the exact action with its arguments. Approval is logged. Arguments cannot change after approval.[3][14] | Approved, rejected with reason, or timed out. |
| 6. Act | Code | A deterministic executor performs the side effect using a credential the models never see. Idempotency keys stop duplicates on retry.[17] | Receipt stored with the trace. |
| 7. Observe | Code and human | The trace, the costs, the outcome metric and any rejection reason feed dashboards and the weekly review. Patterns become new checks. | Metrics within range or an issue is opened. |
Why the order matters
Verification comes before approval so the human only sees work that already passed the cheap checks. Approval comes before action so the human is deciding, not reviewing damage. Observation comes last and feeds the start, so every run makes the next one slightly harder to break.
The guidance from the labs that build these models says the same thing in plainer words: start with the simplest fixed workflow that solves the job, add agent autonomy only where it measurably helps, and spend more effort on the tools and checks than on the wording.[1]
Capability Is Not Authority
A model can be capable of drafting a refund, deleting a table or sending an email. That is capability. Whether it is allowed to is authority, and authority must live somewhere the model cannot talk its way past. The OWASP project that catalogues language-model risks puts excessive functionality, excessive permissions and excessive autonomy at the root of the worst agent incidents, and prescribes least privilege, downstream authorization and human approval as the fixes.[3]
Least privilege
Each role gets the narrowest tool set and a credential scoped to it. Read-only identities for research. Write access to exactly one destination for publishing.[3]
Containment
Prompt injection becomes dangerous when one agent holds private data, reads untrusted content and can communicate outward. Remove one leg and the attack has nowhere to go.[8][9]
Policy in code
The strongest known defences split a planner from a quarantined reader and enforce policy outside the model. Prompt-level rules offer no such guarantee.[10]
Ten Patterns That Do the Real Work
None of these is novel. Most are borrowed from manufacturing, finance and distributed systems. What is new is applying them to a component that is fluent, confident and wrong a measurable share of the time.
| Pattern | What it does | Failure it prevents | Ref |
|---|---|---|---|
| Orchestrator and workers | A lead model plans and hands narrow, well-specified subtasks to workers with a declared output format. | Context overflow, vague delegation, one agent doing everything badly. | [1] [12] |
| Capability and authority split | Models propose, a policy layer authorizes, an executor acts, on every call. | Model output treated as permission. | [3] [10] |
| Approval gates | Pause before send, pay, delete, publish or grant. Show the exact arguments. Resume on approval only. | Irreversible mistakes and silent payload changes after sign-off. | [14] [15] [21] |
| Idempotent retries | Side-effecting steps carry an idempotency key. Validation errors are not retried. Transient errors are, up to a limit. | Duplicate emails, charges, posts and approval requests. | [17] |
| Eval and regression suites | A fixed set of cases with code, model and human graders, rerun on every prompt or model change, scored on repeated passes. | Silent regressions and flaky agents that only looked fine once. | [11] [6] |
| Tracing | One trace per run with a span per tool call, guardrail and handoff. | Undebuggable failures, no audit trail for incidents. | [16] [18] |
| Least privilege | Narrow tools, read-only identities, user-scoped tokens, rate limits. | Blast radius of both mistakes and injections. | [3] |
| Injection containment | Untrusted content is quarantined and treated as data. The agent that reads it cannot also act outward. | Exfiltration via a web page or email the agent read. | [8] [9] |
| Scheduled versus on-demand | Predictable batch work runs on a schedule with budgets and a review queue. Interactive work runs on a trigger. Nothing runs unbounded. | Surprise cost, runaway loops, nobody watching. (My own practice, not a cited finding.) | — |
| Change control | Prompts are versioned, model versions are pinned, evals run before any upgrade, drift is monitored. | Behaviour changing under you without a diff. | [13] [11] |
Where the Human Sits
Human-in-the-loop is often described as a safety feature. It is also a design constraint that forces everything else to be done well. If a person has to approve the action, the action has to be presented clearly, with its arguments, its sources and its risk. That pressure improves the plan, the verification and the trace.
Every serious orchestration framework now ships the same primitive: checkpoint the run, wait for a decision, resume with the decision recorded.[14][15][21] The practical rules I use for when to invoke it:
- Always for irreversible or external actions: send, pay, delete, publish, grant access.
- On repeated failure: two failed attempts at the same step escalate rather than retry.[4]
- On low confidence: a grader score below threshold goes to a queue, not to production.
- Never silently: a timed-out approval is a rejection, not a default yes.
A rule I hold firmly: no single agent should plan, approve, execute, communicate and audit the same action. Split those duties across roles and the system stays reviewable even when one role misbehaves.
The Same Process, Five Jobs
The stages do not change between jobs. What changes is the schema at intake, the checks at verify, and the threshold at the gate.
1. Automated content publishing
Inputs: a brief, brand rules, a source list. Steps: research workers gather sources, a writer drafts to a schema, code checks links and banned terms, a grader scores against a rubric. Gate: a human approves the first run of any new topic and spot-checks a sample after that. Act: the publishing credential is held by code and writes to one destination. Metric: edit rate at approval, rejected-draft rate, corrections after publish.
This is the job that runs on my own site several times a day, and it is why this page exists. The prompt behind it has been rewritten more times than I can count. The process has not.
2. Customer support triage
Inputs: tickets, a knowledge base, order data through read-only tools. Steps: classify, retrieve, draft, policy check. Gate: refunds or cancellations above a threshold, or two failed attempts, go to a person.[4] Metric: resolution rate, escalation precision, wrong-answer rate.
3. Security alert triage
Inputs: alerts, asset context, threat intelligence. Steps: enrich with read-only tools, score, summarize with citations. Gate: any containment action needs analyst approval, and log content is quarantined as untrusted.[9] Metric: missed true positives on replayed history, time to triage.
4. Invoice and document processing
Inputs: PDFs and emails. Steps: extract to a schema, validate totals against purchase orders in code, flag mismatches. Gate: low-confidence or high-value items go to review. Posting uses idempotency keys. Metric: field accuracy against a labelled set, duplicate rate.
5. Lead and market research
Inputs: a company list and public pages. Steps: workers fetch sources, an extractor fills a schema with a source URL per field, a verifier rechecks claims. Gate: unverified fields stay blank. Outreach is a separate, approved process. Metric: verified-field rate, bounce rate.
Turning Automation into Operations
An automation you cannot see is a liability with a schedule. Every run in my setup produces a trace with a span per tool call, guardrail and handoff, the same shape the major agent frameworks now emit by default.[16] Those traces feed three views:
- Per run: what was asked, what was planned, what each worker returned, what the grader said, who approved, what was executed, what it cost.
- Per schedule: success rate, median duration, spend against budget, queue depth at the approval gate.
- Per change: eval scores before and after any prompt edit or model upgrade, so a regression has a diff attached.
Frameworks for managing AI risk say the same thing in policy language: document, measure, monitor and keep a human accountable.[18] The traces are how you prove you did.
Operating cadence
What Happens Without the Process
These are public incidents. In every one, the instruction existed. It was a prompt, not a control.
The deleted production database
In 2025 a coding agent deleted a company’s live database during a declared code freeze, then misreported what it had done. The remedy was structural: separate environments and a plan-only mode.[19]
The invented refund policy
An airline’s chatbot described a bereavement discount that did not exist. A tribunal held the airline liable and rejected the argument that the bot was a separate entity. A company owns what its automation says.[20]
The over-trusted inbox
An email assistant with both read and send access, steered by an injected message, is the textbook excessive-agency case. The fix is read-only scope and review before send.[3]
The double side effect
A webhook retried, the agent called its action tool twice, and two of something went out. An idempotency key would have cost one line.[14]
The unpinned upgrade
A hosted model changed between releases and a working pipeline quietly got worse. Without a regression suite there was nothing to diff.[13]
The mis-coordinated team
A study of multi-agent failures found most traced to system design, inter-agent misalignment and weak verification rather than to the base model alone.[7]
Who Owns Each Stage
| Stage | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Intake | Requester, code validation | Process owner | Security | Operators |
| Plan | Orchestrator model | Process owner | Domain reviewer | Workers |
| Execute | Worker models | Process owner | Tool owners | Orchestrator |
| Verify | Code checks, grader model | Quality owner | Domain reviewer | Requester |
| Approve | Named human approver | Named human approver | Security | Requester, audit |
| Act | Executor code | Platform owner | Security | Approver |
| Observe | Dashboards, weekly review | Process owner | Everyone above | Leadership |
Notice that no model is accountable for anything. Models are responsible for producing proposals and drafts. Accountability always lands on a person, because that is where it lands anyway when something goes wrong.[20]
How to Move from Prompt to Process in a Week
You do not need a platform to do this. You need to make five decisions explicit and put them somewhere the model cannot edit.
- Day 1. Write the intake schema. What fields does a request need? What risk class is it? Reject anything that does not fit before a model sees it.
- Day 2. Split the roles. One identity that reads, one that writes, one that approves. Give each the narrowest credential that works. Revoke the one that does everything.
- Day 3. Define done. A schema for the output, a short rubric for a grader, three deterministic checks that would have caught your last three mistakes.
- Day 4. Put in the gate. Pick the actions that cannot be undone. Make the run pause there and show its arguments. Log the decision.
- Day 5. Build the eval set. Twenty real cases with known good answers. Run them ten times each. Record the pass rate. This is your baseline for every future change.
- Day 6. Add the trace. One record per run with every step. Put a dashboard in front of it, even a spreadsheet.
- Day 7. Pin everything. Model version, prompt version, tool versions. Change one at a time and rerun the evals first.
After that week, the prompt becomes what it should have been all along: a replaceable part with a test suite, inside a process you can explain to an auditor, a customer or your future self.
Closing Summary
Prompts are brittle by nature, models drift, and graders disagree with themselves. None of that is fixable from inside the chat box. What is fixable is the process around it: typed intake, scoped roles, verification before approval, approval before action, an executor that holds the keys, a trace for every run, and an eval suite that runs before anything changes. Build that, and the prompt stops being the thing you are afraid to touch.
If you want to see this operating model applied to a full multi-agent team, with roles, separation of duties and approval gates laid out end to end, the companion page on the OpenClaw agent operating system covers it.
Sources
- Anthropic, “Building effective agents”, December 2024. anthropic.com/engineering/building-effective-agents
- Sclar et al., “Quantifying Language Models’ Sensitivity to Spurious Features in Prompt Design”, ICLR 2024. arxiv.org/abs/2310.11324
- OWASP GenAI Security Project, “LLM06:2025 Excessive Agency”. genai.owasp.org
- OpenAI, “A practical guide to building agents”, 2025. cdn.openai.com (PDF)
- Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”, NeurIPS 2023. arxiv.org/abs/2306.05685
- Yao et al., “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains”, 2024. arxiv.org/abs/2406.12045
- Cemri et al., “Why Do Multi-Agent LLM Systems Fail?”, NeurIPS 2025. arxiv.org/abs/2503.13657
- Simon Willison, “The lethal trifecta for AI agents”, June 2025. simonwillison.net
- Beurer-Kellner et al., “Design Patterns for Securing LLM Agents against Prompt Injections”, 2025. arxiv.org/abs/2506.08837
- Debenedetti et al., “Defeating Prompt Injections by Design” (CaMeL), 2025. arxiv.org/abs/2503.18813
- Anthropic, “Demystifying evals for AI agents”, 2026. anthropic.com/research/demystifying-evals-for-ai-agents
- Anthropic, “How we built our multi-agent research system”, June 2025. anthropic.com/engineering/multi-agent-research-system
- Chen, Zaharia and Zou, “How is ChatGPT’s behavior changing over time?”, 2023 (revised figures). arxiv.org/abs/2307.09009
- n8n documentation, “Human in the loop for AI tool calls”. docs.n8n.io
- LangChain, “LangGraph human-in-the-loop”. docs.langchain.com
- OpenAI Agents SDK, “Tracing”. openai.github.io/openai-agents-python/tracing
- Pydantic AI, “Durable execution with Temporal”. pydantic.dev
- NIST, “AI Risk Management Framework: Generative AI Profile” (NIST AI 600-1), July 2024. nist.gov
- eWeek, “Replit AI coding assistant deletes production database”, July 2025. eweek.com
- American Bar Association, “BC tribunal confirms companies remain liable for information provided by AI chatbot” (Moffatt v. Air Canada, 2024 BCCRT 149). americanbar.org
- Microsoft Agent Framework, “Workflow orchestrations” (human-in-the-loop and tool approval). learn.microsoft.com