Consider one data point from agent engineering: LangChain moved its coding agent from outside the top 30 to the top 5 on Terminal Bench 2.0 by changing only the harness around the model — with no model change at all. The same model, radically different results.
That gap — between what a model can do and what the system around it lets it do — is why so many agent initiatives stall between demo and production. The stack — protocols, frameworks, models — makes agents possible, as we covered in the first article of this series. It does not make them reliable. Gartner warns that over 40% of agentic AI projects may be cancelled by 2027 due to runaway costs, unclear value, or missing risk controls. Many production failures originate outside the model itself: weak task design, poor context, excessive permissions, missing evaluation, unclear ownership, and uncontrolled operating costs.
The teams that ship — Stripe with 1,300+ machine-written pull requests a week, JPMorgan moving from pilots to hundreds of production use cases — share a formula worth memorizing: Agent = Model + Harness. This article is about the second half of that equation: the engineering discipline that has emerged around agents over the past eighteen months, and the governance that turns a working demo into a system you can trust with real workflows.
The Four-Layer Engineering Stack: From Prompts to Loops
A useful way to organize the emerging discipline of agent engineering is into four layers, each minding something larger than the one below.
1. Prompt engineering — the words you send the model. One exchange. Still necessary, no longer sufficient, and no longer where the leverage is.
2. Context engineering — what enters the model’s window. Retrieved knowledge, memory, examples, guardrails — and the critical split between static context (always loaded, expensive on every call) and dynamic context (loaded on demand via skills and RAG). Google Research’s 2026 SDLC whitepaper calls this “the real skill” of AI-assisted development — and the logic is straightforward: with 85% of professional developers now regularly using AI tools for coding, access to strong models is no longer a differentiator. The quality of context, tools, examples, and constraints increasingly is.
3. Harness engineering — everything around the model for a single run. Tools, sandboxes, hooks, sub-agents, observability. This is the layer behind the benchmark statistic above: the harness, not the model, is where most of the reliability lives. It is also where most budgets don’t go — teams spend on model access and skimp on the scaffolding that determines whether that model succeeds.
4. Loop engineering — a term practitioners began using in mid-2026 after teams at Anthropic, Google, and elsewhere independently described the same shift: stop prompting the agent, and design the system that prompts it. A loop discovers its own work — from CI failures, issue queues, inboxes — hands it to worker agents in isolated environments, verifies the result, persists state outside the context window, and reschedules itself. This is now shipping as product primitives: Claude Code’s /goal runs until an independent evaluator model confirms a verifiable condition, and scheduled routines run work with no session open; OpenAI’s Codex offers equivalents.
The progression matters because each layer changes what “reliability” means. A prompt fails once. A loop with standing authority fails continuously, at scale, while nobody is watching.
What Stripe’s Minions Actually Teach
A widely cited case of loop engineering is Stripe’s “Minions”: internal agents, built on a fork of the open-source Goose harness, that ship those 1,300 weekly PRs from a Slack trigger.
The counterintuitive lesson is that Minions’ reliability comes not from a stronger model but from the constraints around it:
- A deterministic orchestrator assembles context before the LLM wakes up. The model never decides what to look at; the system decides for it.
- Hard-coded gates run linters and checks the agent cannot skip. Quality is enforced by infrastructure, not requested by prompt.
- Every PR still passes human review. Autonomy in generation, none in merging.
The design principle underneath all three: anything deterministic logic can solve never goes to a probabilistic model. The LLM is reserved for the part of the task that genuinely requires generation; everything else is ordinary, testable software.
The same pattern applies well beyond software engineering: deterministic intake, scoped tools, non-skippable checks, and human approval can govern compliance reviews, operations, and financial workflows just as effectively as pull requests.
How to Keep Autonomous Agents Reliable and Under Control
Two principles matter for any team running agents unattended.
Separate the generator from the evaluator
Agents often overrate their own outputs, especially when the evaluator sees the same context and reasoning path as the generator. Tuning an independent, skeptical evaluator is far more tractable than making a generator self-critical. True independence comes from separate instructions, evidence sources, and execution paths — ideally combined with a different model or model family, though a different model alone does not guarantee it. The strongest evaluators act — run the tests, click through the UI — rather than just read the code.
If this sounds familiar to anyone from banking, it should: it is the decades-old maker–checker principle, applied to AI. The same institutional logic that never lets one employee both initiate and approve a payment applies to an agent that both writes and validates its own work.
One practical caveat: built-in stop-condition evaluators typically judge from the agent’s own transcript — which the agent produces. Anchor verification to artifacts the generator cannot fake: real test exit codes in CI, not a claim of success in chat.
Budget for the silent costs
Autonomous loops accrue four debts that sound no alarm while running:
- Verification debt — a growing review backlog: unreviewed output accumulating, waiting to fail in production.
- Comprehension rot — loss of codebase understanding: the system growing faster than the team’s mental model of it.
- Cognitive surrender — automation bias in its chronic form: the habit of accepting whatever the machine hands back.
- Token blowout — uncontrolled inference spend: a bug spinning retries all night, billed by the token.
None of these appears on a dashboard by default, which is precisely what makes them dangerous. The guards are structural, not aspirational: an independent evaluator, a daily reading sample of the loop’s output, hard spend caps set before the first unattended run, and at least one checkpoint where the loop pauses for a human.
Governance: The Condition for Scale, Not the Brake on It
Verification controls make an individual run safer. Governance determines which runs are allowed, who owns them, and how much authority the system receives.
The statistics here are uncomfortable. Many organizations deploying agents still lack formal security policies for them. Prompt injection cannot currently be eliminated completely in agents that process untrusted content and can take consequential actions — OpenAI itself has said it is “unlikely to ever be fully solved” for browser agents. OWASP’s mid-2026 Agentic Applications Top 10 maps prompt injection to six of its ten risk categories.
The organizations succeeding anyway share a recognizable governance pattern:
An autonomy-by-risk matrix. Informational tasks can run at high autonomy with logging only. Operational actions need audit trails and undo. Anything moving money or filing with a regulator requires human approval by default. The key insight: autonomy is a management decision, not a technical setting. In practice, the matrix looks like this — with each control explained below:
| Risk tier | Example tasks | Autonomy level | Required controls |
| Informational | Research, summarization, report drafts, internal Q&A | High — runs unattended | Logging only |
| Operational | Updating records, triaging tickets, opening PRs, sending internal notifications | Medium — acts, human can undo | Audit trail + reversibility (undo path) + spend caps |
| Consequential | Customer-facing communications, code merged to production, configuration changes | Low — proposes, human approves | Human review gate + independent evaluator + complete decision and action records |
| Regulated / financial | Moving money, credit decisions, regulatory filings, KYC determinations | Human approval by default; narrowly scoped automation only under documented policy, limits, and audit controls | Mandatory approval for threshold actions + complete decision and action records + named owner + policy versioning + scheduled audit review |
Note that tier assignment depends on more than task type: reversibility, value at risk, customer impact, data sensitivity, and scale can move the same task up a tier. A $50 refund and a $50,000 refund are not the same risk.
Least-privilege tooling. Agents get specific tools scoped to specific tasks — “read this customer profile within this open case,” never “the CRM.” This is where the protocol layer from the first article pays off: an MCP server with a narrow scope is least privilege, implemented in infrastructure rather than promised in a prompt.
Complete decision and action records. Inputs, retrieved data, tool calls, model and prompt versions, applied policies, outputs, approvals, and executed actions — captured for every consequential run. This record is a debugging tool on Tuesday and a legal requirement when the regulator calls on Friday. In financial services, “the agent decided” is not an acceptable line in an audit response.
Untrusted input hygiene. Any loop whose discovery step reads external content — issues, emails, web pages — is a prompt-injection surface. Route untrusted inputs through deterministic parsing before they reach an agent with write access.
An agent registry. Every production agent, and especially every autonomous loop, is an entity with an owner, a permission set, spend limits, and an audit date. Loops deserve particular attention: unlike a one-off agent run, a loop holds standing authority.
The pattern among large financial institutions points the same way. JPMorgan, Goldman Sachs, BNY, Citi, N26 — the institutions that have scaled agent deployments — tend to pair expansion with formal controls, ownership, auditability, and risk-based autonomy, while organizations without comparable controls more often remain stuck in proof-of-concept purgatory. Teams that ship governance late tend to spend the following year retrofitting it under incident pressure; teams that ship it with the first agent spend that year scaling.
What This Means for Your Production Roadmap
Compressing the discipline into decisions you can act on this quarter:
1. Invest in the harness and the evals, not just the agent. Treat AGENTS.md files, system prompts, eval suites, and skills as versioned, reviewed code. Set the bar at the eval, not the demo: a working demo proves an agent can succeed once; a passing eval suite proves it succeeds reliably.
2. Ship governance with the first agent, not after the first incident. A 5–10 page policy covering autonomy levels, logging, red lines, and spend caps beats a perfect framework that arrives six months late.
3. Start small, verify hard, scale parallelism last. The first autonomous loop should be boring — CI triage, report generation, dependency audits — with an independent evaluator and a human review point installed before it earns more scope. Reliability is granted incrementally, the way you would extend authority to a new hire.
Why Judgment Determines Whether AI Agents Scale
The strategic throughline across this series is the same at every layer. Generation has become nearly free; judgment is the scarce resource.
The protocols make integration cheap. The frameworks make orchestration cheap. The open models make inference cheap. The loops make repetition cheap. What none of them provide is the judgment about what to build, which output to trust, and where the human checkpoint belongs.
That judgment — encoded in your architecture, your evals, and your governance — increasingly determines whether agent systems remain useful, controllable, and economically viable at scale. It cannot be downloaded from a registry or licensed under Apache 2.0. It has to be designed, and it compounds: every eval you write, every autonomy boundary you define, every audit record you wire in makes the next agent cheaper and safer to ship.
Nowhere is that judgment more consequential than in financial products, where an agent’s autonomy boundary is also a regulatory boundary. Least-privilege tool design for payment and customer data, audit trails that satisfy examiners, evaluator pipelines for KYC and lending workflows, deciding where the human checkpoint belongs when money moves — these are the problems our team works on daily. If you’re taking an agent from demo to production in a regulated environment, we’re happy to compare notes.