Six Core Components of a Coding Agent Explained with Code

LLM, Reasoning Model, and Agent

LLM is the base next‑token model. A reasoning model is an LLM fine‑tuned to spend more compute on intermediate reasoning, verification, or search. An agent adds a control loop that decides which tool to call, when to update state, and when to stop.

Six Core Components of a Programming Agent

##############################
#### Six Agent Components ####
##############################
# 1) Live Repo Context -> WorkspaceContext
# 2) Prompt Shape And Cache Reuse -> build_prefix, memory_text, prompt
# 3) Structured Tools, Validation, And Permissions -> build_tools, run_tool, validate_tool, approve, parse, path, tool_*
# 4) Context Reduction And Output Management -> clip, history_text
# 5) Transcripts, Memory, And Resumption -> SessionStore, record, note_tool, ask, reset
# 6) Delegation And Bounded Subagents -> tool_delegate

1. Live Repo Context

The agent first gathers stable facts about the repository: current branch, file layout, README, AGENTS.md, and recent commits. This workspace summary is cached so each prompt starts with concrete repository information instead of a blank slate.

2. Prompt Shape and Cache Reuse

Rules, tool descriptions, and the workspace summary change little between turns, so a stable prompt prefix is built once and reused. Only the short‑term memory, recent dialogue, and the new user request are appended each round, avoiding the cost of rebuilding a full prompt each time.

3. Tool Access and Use

Tool calls move the interaction from chat‑like text to executable actions. The framework defines a whitelist of tools with explicit names, input schemas, and permission checks. Before execution the runtime validates that the tool is known, the parameters are well‑formed, user approval (if required) is obtained, and the path lies within the repository. Only when all checks pass does the agent run the command (e.g., subprocess.call).

Validation steps include:

Is the tool known?

Are the parameter formats legal?

Is user approval required?

Is the requested path inside the workspace?

When all checks succeed the tool is executed; otherwise the action is rejected.

4. Minimizing Context Bloat

Long context is expensive and noisy. The agent employs two compression strategies:

Clipping overly long document fragments, tool outputs, or memory notes.

Transcript reduction or summarization: keep recent events detailed while aggressively summarizing older ones.

Duplicate file reads are de‑duplicated to further reduce token usage.

5. Structured Session Memory

Two layers of history are maintained:

Working Memory : a distilled, editable summary of the most relevant state, fed into the prompt.

Full Transcript : a JSONL log of every user request, tool output, and LLM reply, enabling full restoration after shutdown.

The full transcript stores the complete conversation, while the working memory provides a compact view for the model.

6. Delegation with Bounded Subagents

Sub‑agents can handle parallelizable sub‑tasks (e.g., locating a symbol definition) but inherit only the necessary context and operate under strict boundaries (read‑only mode, limited recursion depth). This prevents uncontrolled interference when multiple agents act on the same repository.

Comparison with OpenClaw

OpenClaw is a general‑purpose local agent platform that can perform programming tasks, but it is not specialized for repository‑centric coding assistance. The coding agent focuses on a narrow set of operations—workspace summarization, tool execution, prompt caching, memory management, and bounded delegation—optimizing the developer workflow within a single codebase.

References

Mini Coding Agent source code: https://github.com/rasbt/mini-coding-agent

Visual attention variants article: https://magazine.sebastianraschka.com/p/visual-attention-variants