Components of a Coding Agent: How Tools, Memory, and Context Extend LLMs

Sebastian Raschka outlines the architecture of coding agents, which are systems that wrap LLMs in application layers to improve performance on coding tasks. He distinguishes between LLMs, reasoning models, and agents, explaining that much of the practical progress in LLM systems comes from the surrounding system components rather than just better models.
Key Components of Coding Agents
The article identifies six main building blocks that make coding agents effective:
- Repo context: Navigation and management of code repository information
- Tool design: Integration of external tools and functions
- Prompt-cache stability: Consistent prompt management across sessions
- Memory: State retention and session continuity
- Long-session continuity: Maintaining context over extended interactions
- Model choice: Selection of appropriate LLM or reasoning model
Architecture Layers
Raschka defines several key concepts in the agent ecosystem:
- LLM: The core next-token model
- Reasoning model: An LLM trained or prompted to spend more inference-time compute on intermediate reasoning, verification, or search over candidate answers
- Agent: A control loop around the model that decides what to inspect next, which tools to call, how to update its state, and when to stop
- Agent harness: The software scaffold around an agent that manages context, tool use, prompts, state, and control flow
- Coding harness: A special case of agent harness specifically for software engineering that manages code context, tools, execution, and iterative feedback
He notes that Claude Code and Codex CLI can be considered coding harnesses. The relationship is described as: the LLM is the engine, a reasoning model is a beefed-up engine, and an agent harness helps us use the model effectively.
Coding work involves more than just next-token generation—it requires repo navigation, search, function lookup, diff application, test execution, error inspection, and context management. Coding harnesses combine three layers: the model family, an agent loop, and runtime supports.
📖 Read the full source: HN AI Agents
👀 See Also

CLAUDE.md Files Are Often Organized for Developers, Not AI Models – Here's Why That Matters
CLAUDE.md files commonly place Hard Rules at line 47, after background and tech stack. By the time the model reads constraints, it has already constructed conflicting assumptions. A better structure puts hard rules first.

Claude Code Structure That Survived Multiple Real Projects
A developer shares a Claude Code setup that held up across 2-3 real projects with multiple skills, MCP servers, and agents. Key findings include using CLAUDE MD for consistency, splitting skills by intent, implementing hooks, and keeping context usage under 60%.

How to Access GPT-5.4 Early on OpenClaw via Dev Channel
The OpenClaw dev channel currently offers access to GPT-5.4 before its stable release. Users need to switch their gateway to the dev channel using a specific command and restart it to see the model in their list.

System Architecture for Vibe Coders: A Senior Engineer's Guide
A 10-year engineer shares how to approach app building with Claude Code: start at the system level, not the code. Covers the four components — frontend, backend, database, plumbing — with a deep dive into the plumbing: APIs, hosting, deployment, secrets, and security.