Coding Agent Architecture: The Six Components That Actually Matter

When a coding agent underperforms, the instinct is to upgrade the model. According to LLM research engineer Sebastian Raschka, that instinct is usually wrong. The model is rarely the problem. The harness is.

Raschka’s breakdown of coding agent architecture — published to his 177,000-subscriber Ahead of AI newsletter — identifies six components that determine whether a coding agent actually works in practice. The analysis lands at an inflection point: Claude Code and OpenAI’s Codex CLI have made coding agents mainstream, and teams are increasingly building custom internal agents against the same underlying models. The divergence in outcomes isn’t explained by which model you’re calling. It’s explained by the six layers wrapped around it.

The Six Components

1. Live Repo Context The agent needs access to real, current repository state — not stale snapshots cached at session start. Coding agents that work from outdated context produce changes that conflict with what’s already in the codebase, compounding errors across multi-step tasks.

2. Prompt Shape and Cache Reuse Prompt structure directly affects key-value cache efficiency and, by extension, latency and cost. Well-shaped prompts position stable context early and variable context late, maximizing cache hits across repeated calls in the same session.

3. Tool Access and Use The action space of a coding agent is defined by its tools: file read/write, shell execution, search, test runners. Tool design is as important as tool availability — poorly scoped tools produce agents that thrash through trial-and-error rather than executing deliberate steps.

4. Minimizing Context Bloat Context windows fill fast in multi-step coding tasks. Every file read, every tool output, every prior exchange accumulates. Agents without explicit context management strategies degrade as sessions extend — not because the model gets worse, but because the signal-to-noise ratio collapses.

5. Structured Session Memory Tracking what was done, what was decided, and what failed is distinct from context. Memory is structured state — a record of commitments and outcomes that persists across the session and informs subsequent decisions without requiring the full transcript in the active window.

6. Delegation with Bounded Subagents Spawning subagents for discrete sub-tasks only works reliably when scope and return contracts are explicit. Unbounded subagents drift — they solve adjacent problems, consume context unpredictably, and produce outputs the parent agent can’t cleanly consume.

Why the Harness Wins

Raschka’s core claim: “The harness can often be the distinguishing factor that makes one LLM work better than another.” This explains a pattern that’s been visible since Claude Code and Codex CLI launched to the same audience. Both call capable underlying models. Their performance divergence on real engineering tasks isn’t a model quality story — it’s a wrapper quality story.

The same principle holds for teams building custom coding agents on top of existing stacks. Two teams using identical models can ship agents with dramatically different reliability profiles depending on how they handle context management, memory structure, and subagent delegation. These aren’t implementation details. They’re the architecture.

Source: Ahead of AI

Content created with AI assistance and reviewed for accuracy.