Axel Quack
Agents already spend. This essay is the layer underneath the payment MCP: what the agent is allowed to do, when it is allowed to stop, and who may run next.
By 2026 the public argument about agents is still mostly about models. Frontier versus open weights. Cloud versus local. Context window size as a product feature. That is the wrong flag.
The model is rented inference. The harness is the jurisdiction. Two teams with the same weights diverge because one gave the model a filesystem, a sandbox, least privilege, and a stop rule that is a check — and the other gave it a prompt and an unreliable API wrapper. Similar intelligence; different working conditions.
I have watched this on my own desk: OpenCode, Hermes, Goose, Ollama for what must not leave the LAN, vLLM when the box is a real GPU. Session on, prompt in, answer out — until the session dies, the same task is re-explained, and two hours of debugging become a token bill with no artefact. Prompt engineering captures maybe a tenth of what is possible. If the job is only a prompt, Zapier is cheaper.
The field already moved through context engineering and skill engineering. The layer almost nobody operates is three stacked decisions. LangChain wrote the anatomy in March 2026 and the loop essay in June. The names are not the point. The failure modes are.
H → L → G
Order of need: environment first, then a loop that actually finishes, then a graph. Starting with a graph before a single loop is stable just spreads unreliability.
| Harness | Loop | Graph | |
|---|---|---|---|
| Question | Can the model do the work safely? | Does it finish for a reason? | Who may run next? |
| Object | Runtime around the model | Bounded cycle | Directed workflow / state machine |
| Fixes | No files, no resume, wrong perms, lost state | Stops early, retries forever, “looks done” | Unreadable multi-step, no joins/approvals |
| Risk | Unbounded runtime with too many tools | Token burn, gaming the stop condition | Over-specified brittle paths |
| Do not confuse with | “Better prompt” | Prompt engineering | Knowledge graphs (entities, not control) |
LangChain’s one-liner is the whole essay: Agent = Model + Harness. If you are not the model, you are the harness.
Harness: delete the model from the diagram
Everything that is not the weights: system prompts, tool and MCP schemas, filesystem, sandbox, browser, orchestration (subagents, handoffs, routing), middleware (compaction, continuation, lint), permissions, traces, graders.
A raw model cannot keep durable state, execute code, see post-cutoff facts, install packages, restart a failed job, or enforce an approval. Those are harness features. Chat itself is already a harness — a while-loop that appends messages.
| Wanted behaviour | Harness move |
|---|---|
| Durable work, offload context, multi-session | Filesystem (+ git as versioned ledger) |
| Solve problems without a tool for every action | Bash / code exec |
| Safe, scalable execution | Sandboxes (allow-lists, network isolation, on-demand fan-out) |
| Memory past the window / past the cutoff | Files the next session can read; search; MCP |
| Context that does not fill with junk | Compaction, tool-output offload, skills loaded only when needed |
| Long-running work | Planning files + a loop that restates the original goal on a clean window; filesystem carries state |
Terminal Bench still shows large gaps for the same model in different harnesses. The same weights in OpenCode are not the same weights in a thin REST loop, and not the same weights behind Hermes or Goose. Changing the harness for your task still changes results — even as some of this is slowly absorbed into weights.
There is a coupling you cannot ignore. Coding agents that ship a full runtime (filesystem, bash, MCP, compaction) train and run with a harness in the loop. Changing tool semantics can tank performance: the model overfitted to that tool set. That does not mean OpenCode’s, Hermes’, or Goose’s harness is optimal for your job. Steal the pieces. Do not pick one runtime as a flag.
Too many tools is its own failure mode. Selection error. Noisy context. Permissions wide enough that “the agent did it” is not an audit trail. Least privilege is the difference between a lab and a liability.
Loop: evidence, not confidence
Every tool-using agent already has a tiny loop: call model → look → tool → repeat. Loop engineering starts when you design that cycle with a stop rule that is a check, not a self-report.
- Trigger — user, cron, webhook, failed test, new doc
- Goal — a state, not “keep improving”
- State — what the next cycle needs without replaying everything
- Action policy — what it may change, spend, or delegate
- Evidence — tests, schema, citations, diffs, metrics, a human
- Feedback — compact, actionable, not “try harder”
- Stop — success, budget, timeout, irrecoverable, escalate
“The agent says it is done” is not a terminal condition. Tests pass, links resolve, schema validates, reviewer approved — that is.
The 2026 operator line is: I don’t prompt the model anymore, I start loops that prompt the model. Products shipping /goal and /loop make the shift visible. A goal loop is the same idea: work until a check still passes after a real verification.
Do not mix loop types. They fail for different reasons:
| Kind | Runs until / when | Example |
|---|---|---|
| Turn-based | Each user command | Chat coding session |
| Goal-based | A check is met | Bug-fix until pytest is green |
| Time-based | Schedule | Daily briefing |
| Event-driven | Event, no user in the loop | Cron, webhook, a Slack channel that means “docs please” |
LangChain stacks four levels: agent until task complete → grader/retry → event-driven → traces rewrite the harness. Level 4 is the one that compounds. Organisations that log traces and feed them back into prompts and tools early get an advantage that is hard to copy. That is flag theory for agent ops: the loop is the asset, not the chat log.
Every grader/retry is another call. The standing rule still holds: simplest architecture that works; add agentic complexity only when the gain pays for the latency. Add a loop where cost of failure > cost of verification.
Anti-patterns: unbounded “keep trying”; the same model writes and grades with no split context or deterministic check; stopping because the model reported high confidence.
Graph: what is allowed to continue
Not “what the agent does.” What is allowed to continue.
Nodes = work (function, LLM, specialist agent, human). Edges = sequence, branch, fan-out, join, cycle, interrupt. State schema is first-class. A single loop is a graph with one node and a self-edge. Graph engineering embeds loops in nodes and adds routing on top. It does not replace loops.
This is not a knowledge graph. Entities and GraphRAG are a data problem. Workflow graphs are a control problem. Mixing the words is how teams buy a graph database when they needed a stop rule.
The extra structure is worth it for branches, parallelism, approvals, recovery, multiple specialists. It is not worth it for “one agent, three tools, run until done.” If the model must invent the plan, freezing every path into a diagram makes the system brittle. Start from traces of a simpler harness, then formalise stable paths.
A research brief as a worked example:
- Harness: browser, search, citation store, secrets, traces, approval UI
- Graph: scope → parallel research → screen → synthesise → draft → legal → publish (human gate before release)
- Loops inside nodes: retrieve again if coverage is weak; send the draft back if citations fail; scheduled refresh
The reviewer node should see the brief and an accuracy measure — not the writer’s scratchpad. Fresh context beats self-review.
A three-bug lab (integer divide, reverse-words returns a list, off-by-one dates) makes the cost trade-off clear:
| Round | What you buy |
|---|---|
| Harness only (read/write/test once) | Makes the work possible; proves failure |
| Loop (bounded attempts, feed the test log) | Accuracy; paid in latency |
| Graph (parallel coder nodes + suite reviewer) | Wall-clock, independent check — not more bug-fixing power |
If a team optimises the latency dashboard, they will delete the loop and silently drop from 3/3 to 2/3. That is a management failure, not a model failure.
Diagnose by symptom
| Symptom | Start here | Likely fix |
|---|---|---|
| Cannot reach the tool or data safely | Harness | Contract, perms, sandbox, context |
| Forgets across sessions | Harness | Durable state, progress file, git, compaction |
| First try close but unreliable | Loop | External grader, tests, bounded retry |
| Works after “success” / stops before proof | Loop | Evidence terminals + budget |
| Specialists must run in a known order | Graph | Nodes, edges, joins |
| Cannot find the failure in a long run | Graph + harness | Traces aligned to nodes |
| Workflow changes weekly | Simpler harness | Keep control model-driven; delay the diagram |
When something breaks in production: environment → feedback → flow. A workflow diagram cannot recover state the harness never stored. A large harness without a stop rule burns tokens.
Costly mistakes
- Draw 40 nodes before watching one capable agent solve the task
- Same model writes and grades without a split context or a deterministic check
- “Keep trying” as the loop spec
- Harness as dumping ground
- Blame the model for stale state, broken APIs, missing exits
- Start at the graph
Flag theory for agent runtimes
Classic flag theory diversifies banks, residencies, and legal entities. Agentic work needs the same instinct — pointed at runtime, not at the logo on the model card.
- Do not let one cloud host hold every tool, every secret, and every stop rule.
- Do not bind power in prompt text. Bind it in credentials, sandboxes, and evidence.
- Do keep a human-gated break-glass path (the same non-negotiable as in Conductance).
- Do treat MCP servers like HSMs: change control, pinned versions, least privilege.
- Do assume the model host will change behaviour. The harness you own is the part that survives a vendor swap.
On a sovereign lab the split is clean: Talos (or another immutable host) is the metal — API-only nodes, no SSH on the cluster. The harness is the agent’s working conditions on top of that host — OpenCode or Hermes on the desk, Goose where you want a different runtime, Ollama or vLLM for weights that stay home. The loop is how you know the job finished. The graph is only for the paths that have already proven stable.
Coding agents on a rich desktop already have most of the harness. The gap is usually loops (tests as stop) and trace feedback (logs rewrite the prompt). Self-hosted gateways already poll on a schedule; do not draw a graph until one goal passes its check. Enterprise buyers who ask “who is the agent, who is the supervisor, who holds the kill switch” are asking graph + human gates — they are not asking for a better system prompt.
Final thoughts
Conductance argued that agents already spend, on rails that already clear. This essay argues that spend is a loop with a credential, and that most “agent failures” are harness and stop-rule failures blamed on the model.
The next years will not replace the three-layer vocabulary. They will productise it until the words become as boring as “VPC.” Own the filesystem, own the proof that work finished, and only then draw who may run next.
Privacy is still a stack. The 2026 error is to treat the model as the whole problem.
The website and the information contained therein are not intended to be a source of advice. Agent architectures have operational, security, and legal consequences; verify configurations and threat models independently.
Addendum: LangChain harness/loop essays (2026-03 / 2026-06) and practitioner posts through August 2026; re-check upstream before deployment. Editorial assembly from a Markdown vault with AI assistance.