TL;DR
An agent is a model plus a harness, and the harness is what makes it reliable in production. Paul Iusztin's post names six harness concepts: agent loop, tool calling, context management, checkpointing, permissions and sandboxing, and guardrails. The list is a sound vocabulary but a shallow treatment. The comments add what a staff engineer would: observability and evals, and the fact that checkpoint-and-resume is only safe when side effects are idempotent.
Source: LinkedIn, Paul Iusztin (Decoding AI; author at Manning), published 2026-11-03, 101 reactions and 68 comments when read on 2026-11-04. One infographic, "6 Must Know Terms About AI Harnesses", drawn as a customer-support order example. Read signed out, so this is a paraphrase and only 10 of the 68 comments were visible.
The six terms
The infographic gives each term one flow. The right-hand column is what each one means once you have to build it.
| Term | The post's picture | What it means in a production harness |
|---|---|---|
| Agent loop | Request, model, tool call, read result, "Done?"; loop until yes, then answer | The termination test is the design. Bound it with step and token budgets, and treat "model says done" as a claim to verify, not a stop condition. |
| Tool calling | Model asks for order status, tool returns "Delivered", model replies | Tools are a typed API for a non-deterministic caller. Schemas, error messages the model can act on, and output sizes all shape behaviour as much as the prompt does. |
| Context management | Policy, instructions and old chat; old chat compacted; prompts and hooks assemble the context for this step | Context is assembled per step, not accumulated. Compaction is lossy, so decide what must survive it (task state, constraints, decisions) and keep it outside the transcript. |
| Checkpointing | Save "order delivered", interruption, restart and load, resume | State save is the easy half. Resume replays the steps after the checkpoint, so every write tool needs an idempotency key or a record that it already ran. |
| Permissions and sandboxing | Permission check allows "read order", blocks "issue refund" | Classify tools by blast radius (read, reversible write, irreversible write). Enforce in the harness, not the prompt, and run code in a sandbox with scoped credentials. |
| Guardrails | Draft ready, human approval, wait or send | A human gate is one guardrail among several (input and output filters, policy checks). Put gates on irreversible, outward-facing actions, and design the wait state so the run can park and resume. |
What the post misses
The gaps are where production harnesses actually fail, and the commenters found most of them.
Observability and evals (the missing seventh term). Several commenters raised it. A completed task doesn't show the agent took the right steps. You need traces of every step and tool call, run logs you can replay, and evals that score the trajectory as well as the final answer.
Checkpointing has two halves. One commenter split it into saving state and replaying side effects: resuming shouldn't send the email twice. Tag tools as read or write and give writes idempotency keys. Another said to build checkpointing and permissions first, because most builds never check that replay is safe.
Sub-agent context isolation. Context management in the post is single-agent compaction. Long runs also need sub-agents with their own clean context, returning summaries, so the parent's window survives.
Failure handling is named but not drawn. The post says the harness handles failures, but none of the six flows has a retry, a timeout or a bad tool output. One commenter put it plainly: demos work, then production breaks on retries, bad tool outputs and human handoff.
No cost or budget control. A loop with no step or spend ceiling is an outage waiting to happen. It belongs next to the agent loop.
The post also never says which harness it describes. The second roadmap's URL slug is "claude-code-from-scratch", which suggests it is built around Claude Code. That link wasn't opened.
Review checklist for a harness
The loop has a step budget, a token or spend budget, and a check on "done" that isn't just the model's say-so.
Every tool has a typed schema, bounded output, and errors the model can act on.
Each tool is classified as read, reversible write or irreversible write, and the harness (not the prompt) enforces it.
Write tools carry idempotency keys, so resuming from a checkpoint can't repeat a side effect.
Task state, constraints and decisions live outside the transcript and survive compaction.
Long tasks delegate to sub-agents with isolated context.
Irreversible or outward-facing actions pass a human or policy gate, and the run can park while it waits.
Every run is traced and replayable, and evals score the trajectory as well as the outcome.
Retries, timeouts and malformed tool output have a tested path.
Related entries
This is R006 in the research index.
R005, Second Brain OS: the five-layer map of AI agents. The closest entry. Both say an agent is the model plus a system around it. R005's loop, gate and harness layers map onto this post's agent loop, guardrails and permissions, and tool calling. R005 also makes evals a layer of its own, which is the seventh term this post's commenters say is missing.
R004, The best Claude setup is no setup. R004 is about what you put in the harness's configuration; this post is about what the harness does. Permissions here line up with R004's "default to Auto": Auto is safe only when the harness classifies tools by blast radius.
R002, The 5 layers of agent memory. Context management and checkpointing are working and episodic memory in R002's terms. Shivani Virdi, R002's author, comments here that context management is the key factor.
Sources
Paul Iusztin, "6 terms you must understand if you're building AI agents", LinkedIn, 2026-11-03.
Linked from the post but not opened: AI Agent Foundations course and Harness Engineering roadmap.