model that runs in a loop, using tools, until a goal is reached. — A chatbot answers your question, once — An agent acts, observes what happened, and acts again — That loop is what turns a text predictor into something that gets work done — Everything that follows is an elaboration on it
that fixes bugs across a 100,000-file repo, runs the tests, opens a clean PR. — Team B: a chatbot that forgets message three and invents a file that doesn't exist. — Same weights. Same API. Wildly different products. — So what's the variable? Everything wrapped around the model.
software system around the model — and in 2026 it is where the differentiation actually lives. — The loop that lets the model act — The tools it can call — The context it's allowed to see — The guardrails and the feedback that tells it whether it worked
S What "agentic AI" actually means "An agent is a language model that runs in a loop, using tools, until a goal is reached." — A model that can reason and decide what to do next — Tools — functions it can invoke: search, read a file, run code, send an email — A loop that feeds each result back so it can decide the next step — A chatbot answers once. An agent keeps going.
S So what is a harness? The harness is the software system that operates the loop. The model decides what to do; the harness makes it happen — safely, cheaply, observably. — Executes the tool calls the model requests — Decides what the model gets to see at each step — Enforces permissions, handles failures, retries, loops — Tracks progress — and knows when to stop or ask a human
S The mental model The model is stateless and amnesiac. Change the production and the same actor gives a completely different performance. — Every turn, the model wakes up with no memory — It reads whatever text is placed in front of it — It produces exactly one output, then forgets again — The harness is the whole production around that moment — script, props, stage, safety curtain.
S Why the harness matters more than you think — Model gains are converging; harness gains are not. Same model, double-digit benchmark swings from scaffold alone. — Long tasks amplify small errors. 99% per step over 50 steps = 60% success. — Autonomy without control is a liability. Spend, shell access, customer email. — All three fixes live in the harness. None live in the weights.
S The compounding-error math If a model is 99% reliable per step, a 50-step task succeeds about 60% of the time. — 0.99 ⁵⁰ ≈ 0.605 — a 40% failure rate on a task nobody would call hard — Verification, retries, checkpoints, course-correction — Every one of those is harness machinery, not model capability — This single curve is why demos impress and products disappoint
1 O F 7 1 · The system prompt The constitution. The harness's standing orders. — Who the agent is, what it may do, how it should behave — Beginner: "You are a helpful coding assistant." — Production: "Read before editing. Prefer small diffs. Run tests after every change. If tests fail twice, stop and report. Never push to main…" — In mature products this runs to thousands of words — engineered like code
2 O F 7 2 · The tool layer The hands. Tool design is API design for a very literalminded user. — Descriptions are prompts. The model picks tools by reading them. — Fewer, sharper tools win. Tool sprawl confuses models like a 40-item menu confuses diners. — Return errors it can act on. "Permission denied, use request_access first" > a stack trace. — Make dangerous tools narrow. send_email(draft_id) beats run_arbitrary_code().
3 O F 7 3 · Context management The working memory — and the highest-leverage part of the whole system. "Context engineering" has largely displaced prompt engineering as the core skill. — Truncation & retrieval — show only the relevant slice — Compaction — summarize the history, replace it, keep going for hours — Structured note-taking — the agent writes progress notes to files and re-reads them — Just-in-time loading — don't preload "in case"; give it a tool to fetch
4 O F 7 4 · Memory The long-term store. Usually layered. — Project memory — CLAUDE.md / AGENTS.md in the repo: your conventions, your build commands — User memory — preferences learned across sessions: prefers TypeScript, hates bullet points — Episodic memory — records of past runs, retrieved when a similar task comes round again — Context is per-session. Memory is what survives the session.
5 O F 7 5 · Guardrails, permissions, sandboxing The brakes. One question, asked continuously: should this action actually be executed? — Permission tiers — reads free, writes checked, irreversible actions need a human — Sandboxing — isolated containers, restricted filesystem and network — Filtering — scan tool results for injection, scan outputs for leaked secrets — Hard budgets — spend, tokens, time, and loop iterations
6 O F 7 6 · Verification and feedback The eyes. The single most reliable way to improve an agent is to give it a way to check its own work. — Coding agents run compilers, linters, and test suites after each change — Research agents cross-check claims across sources — Browser agents screenshot the page to confirm what actually happened — LLM-as-judge — a second model reviews the first against a rubric before anything ships
7 O F 7 7 · Observability The flight recorder. Debugging an agent without traces is like debugging a distributed system without logs: technically possible, spiritually devastating. — Log every model call, every tool invocation, every token spent — Traces let you replay a failed run and find the exact step it went sideways — Then fix the prompt, the tool, or the policy responsible — LangSmith, Langfuse, Braintrust, OpenTelemetry GenAI conventions
N G T H E L O O P The plan–act–verify rhythm Naive agents dive straight in. Mature harnesses impose a rhythm. — Plan first — break the goal into a task list, often via an explicit planning tool — Act in small steps — one change at a time — Verify each result — before moving on, not at the end — Then update the plan and repeat
N G T H E L O O P Structured outputs — Any output another program will read should be schema-constrained — Modern APIs support it natively — forced tool calls, validated generation — Freeform text is for humans — Parsing prose with regex is a choice, and it is the wrong one
N G T H E L O O P The whole idea, in miniature Everything in this talk is an elaboration of these four lines. while not done: response = model.generate(context, tools) # model decides results = execute(response.tool_calls) # harness acts, safely context = manage(context + results) # harness curates memory
A G E N T Sub-agents and orchestration Once a task outgrows one context window, an orchestrator decomposes the goal and spawns sub-agents. — Each sub-agent starts fresh — its own context, its own narrower toolset, one focused brief — Only the conclusion comes back — the orchestrator receives the answer, not the working history — This is context isolation, not parallelism — ten sub-agents burn ten full windows while the lead holds ten summaries — The standing trade-off — more capability and coverage, for many times the tokens
A G E N T Three topologies Most jobs don't need any of them. When one context window truly can't hold the task, you'll know. — Orchestrator–workers — one lead plans and delegates; by far the most common — Pipelines — draft → critique → revise, each stage its own agent — Debate panels — several agents attempt the same problem and a judge synthesizes; expensive, for high-stakes answers — Brief them like strangers — say how much effort a task deserves, make briefs self-contained, give each an isolated workspace
failure in an afternoon. That afternoon is the entire syllabus. — Build the naive loop — one API, two tools, a while-loop, ~100 lines, no framework — Add organs one at a time — structured outputs → errors → planning → verification → context → permissions → tracing — Write ten evals before you scale anything — Build thin harnesses around thick models — expect to delete pieces as models improve
model still needs four things that no amount of training will supply. They are the permanent interface between an intelligent system and human intent. — Authority — what may it do? — Context — what should it know? — Verification — why should we trust it? — Observability — what did it do, and why?