Agentic Coding Basics
What a coding-agent harness actually is
Prerequisites
None — this is where the course starts.
What You'll Learn
- Trace the agent loop: model → tool call → result → model
- Explain why the context window is the real cost
- Name the four knobs harnesses differ on
The loop, precisely
Strip away the branding and every coding agent — every one — is this control flow. The model is a function you call; the harness is the program that keeps calling it.
while (true) {
response = model(context) // the FULL context, every time
if (!response.toolCall) return response.text
result = harness.execute(response.toolCall)
context.push(response, result)
}The model reads the whole context and emits either plain text or a tool call — a structured request like "read src/auth.ts" or "run pnpm test".
The harness parses that call, checks it against permissions, and executes it on your machine. The model never touches your filesystem; the harness does.
The result — file contents, a test log, an exit code — is appended to the context, and the model is called again with everything accumulated so far.
The loop ends when the model answers with text and no tool call. That is the entire termination condition.
Six lines of pseudocode, and yet Claude Code, Codex, and every harness in this course is a different answer to the same question: what do you build around this loop?
The four knobs — and the lesson that turns each one
Harnesses feel different because each one takes a position on four design decisions. The rest of this course is one deep dive per knob, each on a harness that turns that knob all the way to one end.
| Knob | The question it answers | Extremes | Deep dive |
|---|---|---|---|
| Who owns the loop | Is the agent loop a fixed engine, or a layer you can replace? | fixed engine ↔ plugin-swappable | DeepSeek Harness |
| Context strategy | One big window that fills up, or disposable contexts you spawn and throw away? | one big window ↔ disposable subagents | Kimi Code CLI |
| Tool surface | How many tools does the model juggle — a minimal core, or batteries included? | minimal core ↔ batteries included | Pi |
| Model coupling | Built around one vendor, or agnostic across any provider you point it at? | single-vendor ↔ provider-agnostic | opencode |
Context is the real cost
Look at the pseudocode again: the model is called with the full context on every turn. That one detail drives most of agent economics. A 2,000-line file read on turn 3 is re-sent on turn 4, turn 5, and every turn after — you pay input tokens for it each time, and the model has to attend past it each time. Long sessions do not just get expensive; they get slower and noticeably less sharp, because the signal you care about is buried under everything that came before.
This is why "context strategy" is a knob at all. Compaction, session restarts, and disposable subagent contexts are all attempts to keep the window lean without losing what matters — and harnesses disagree hard on the right answer.
Feel it, don't just read it: the Duel on this site is a 90-second playable version of exactly this problem — one model drowning in its own context window versus an orchestrator that spends tokens carefully. Play the Duel →
💡 Pro Tips
- 1.Watch the tool calls scroll by on your next agent session instead of tabbing away. Ten minutes of reading the loop in action builds a better mental model than any diagram — including ours.
- 2.When an agent seems to get dumber late in a long session, suspect the context window before the model. Compact or restart with a short summary of where you are — it usually snaps back.
- 3.Big exploratory reads (whole directories, long logs) are the fastest way to flood a window. Prefer targeted reads, and reach for subagents when the harness offers them — that is the context-strategy knob in action.
- 4.Judge harnesses, not just models. The same model feels sharp in one harness and clumsy in another; the loop, the tools, and the context strategy are doing more of the work than most people credit.
Further reading
- Effective harnesses for long-running agents — Anthropic's own engineering write-up of why the machinery around the model decides whether long tasks finish. First-party grounding for this whole course.
- learn-harness-engineering — an open-source (MIT) course with deeper design breakdowns of several harnesses covered here. A good companion once you have the basics down.
The walkthrough, as text
-
1. The Agent Loop
A coding agent is a loop: the model proposes a tool call, the harness executes it on your machine, and the result goes back to the model. Read a file, run the tests, edit, re-run — every task is laps around this cycle until the model decides it is done.
-
2. The Context Window
The loop has one working memory: the context window. Every file read and every test log rides along on every subsequent turn — nothing is forgotten mid-task, so the window fills and the cost of each turn rises with it.
-
3. Tools: The Hands
Tools are how the model touches your machine. Read, write, edit, and a shell form the universal core — every harness ships these four in some form, whatever it names them. The model never runs anything itself; it only asks.
-
4. The Harness Itself
The harness is everything wrapped around the model: the loop, the context strategy, the tool surface, and the model coupling. Swap the model and the agent still works. Models are interchangeable; the harness is the product.
-
5. Where Harnesses Differ
Every harness turns four knobs: who owns the loop, how context is managed, how wide the tool surface is, and how tightly it couples to one model vendor. The four deep dives in this course each turn one knob all the way.
New lessons, straight to your inbox
5 more harness deep dives are on the roadmap. Subscribers read them first — free.
Check your inbox to confirm.