The prompt is the smallest part of a coding agent

A coding agent starts with a prompt, but it succeeds or fails in the runtime around that prompt. The useful mental model is smaller and more mechanical: prompt, loop, harness.

Why is the prompt the smallest part?

A Claude-style coding agent is better understood as a three-layer system: the harness owns the environment, the execution loop mediates model-tool interaction, and the prompt supplies compact instructions. Anthropic’s tool-use contract says Claude emits structured tool_use requests, then the application executes the tool and returns tool_result blocks . That means the prompt can ask for careful behavior, but the harness is what can enforce permissions, sandboxing, context assembly, hooks, logging, and stop conditions.

Quick Answer: The prompt is the smallest part because a coding agent’s reliability comes from its harness and loop: typed tool calls, returned observations, permissions, sandboxes, hooks, and lifecycle controls. Anthropic’s 2026 releases emphasized 1M-token context windows and 128k output caps as runtime surfaces, not prompt text .

The boundary matters because prompts are advisory while tool policy is executable. A prompt can say “inspect before editing,” but a harness can restrict writes, require approval for shell commands, load project memory, expose MCP servers, trigger hooks before or after tool use, and stop the agent when a verifier passes or a turn budget is exhausted. The seed video is useful as a prompt for this investigation, but the durable evidence is in the public agent and tool-use documentation .

"The client application executes the tool," — Anthropic tool-use documentation (source: Anthropic)

Recent platform changes point in the same direction. Anthropic’s June 30, 2026 Sonnet 5 release listed a 1M-token context window, 128k maximum output tokens, adaptive thinking on by default, and introductory pricing of $2 per million input tokens and $10 per million output tokens through August 31, 2026 . Its July 24, 2026 Opus 5 release listed a 1M-token context window, 128k maximum output tokens, thinking on by default, and $5/$25 per million input/output pricing . Those are harness and lifecycle controls: context, output caps, sandboxes, events, and managed sessions.

class CodingAgent:
    def __init__(self, prompt):
        self.prompt = prompt
        self.tools = ["read", "edit", "run tests"]
        self.loop = ["observe", "plan", "act", "verify"]

    def solve(self, task):
        return (
            f"Task: {task}\n"
            f"Prompt: {self.prompt!r}\n"
            f"Agent: tools={self.tools}, loop={self.loop}\n"
            "Point: the prompt starts the work; tools, feedback, and verification do most of it."
        )


print(CodingAgent("fix the bug").solve("make the program correct"))

What must the harness own before the loop starts?

The harness must own everything the model should not guess: workspace files, current git state, the user request, model instructions, tool schemas, permission mode, project memory, and external connections. In practice, Claude Code, OpenAI Codex, SWE-agent, and mini-SWE-agent all put environment preparation outside the model response, then let the model operate inside that prepared frame.

For a coding agent, the runnable prerequisites are concrete. Before the first model call, the harness should know which repository is active, whether the worktree is dirty, what files or logs are relevant, which instructions apply, which tools are allowed, and whether edits, shell commands, network calls, or MCP servers require approval. Claude Code documents this split through terminal access, project context, CLAUDE.md memory, MCP, hooks, permissions, skills, and subagents .

System	Harness responsibility before the loop	Why it matters
Claude Code	Loads project files, memory, tools, MCP, hooks, and permission rules .	The model acts with bounded project context instead of relying on prompt text alone.
OpenAI Codex	Prepares user input, instructions, tools, and prior items before unrolling the agent loop .	The loop is a product runtime, not just a chat completion.
SWE-agent	Initializes an environment, keeps a shell session, compresses history, and executes actions through SWEEnv .	Tool output becomes structured feedback for the next step.
mini-SWE-agent	Shows the lower bound: short instructions plus shell access can work, but the harness still carries execution risk.	Minimal prompts do not remove the need for sandboxing and verification.

The scale pressure in 2026 makes this separation more important, not less. Anthropic’s release notes list Claude Sonnet 5 on June 30, 2026 with a 1M-token context window and 128k max output tokens, followed by Claude Opus 5 on July 24, 2026 with the same context and output limits . Bigger context does not automatically mean better context; noisy files, stale logs, and irrelevant history can still steer bad edits. The harness should select, label, compress, and audit context before the execution loop begins.

How does the execution loop run?

The execution loop is the agent’s state machine: it sends the model messages plus tool schemas, runs any requested tools outside the model, returns observations, and repeats until the model stops asking for tools. In Anthropic’s tool-use contract, tool_use keeps the loop alive, while end_turn, max_tokens, stop_sequence, or refusal ends or interrupts the turn, according to the Anthropic tool-use documentation.

1. Send the working state. The harness sends the user request, compacted conversation history, relevant project context, and typed tool schemas. The model should see what it can ask for, not direct access to the shell or filesystem.
2. Read the model response. If the response contains tool_use blocks, treat them as structured requests. Do not assume the model has already executed anything.
3. Dispatch each requested call. The application runs the requested file read, edit, shell command, test command, MCP call, or other tool under the harness’s permission and sandbox rules.
4. Append real observations. The harness returns tool_result blocks containing stdout, stderr, file contents, test failures, permission denials, or other concrete results.
5. Call the model again. The model reasons over the new observations and either requests another tool call or produces a final response.
6. Stop only on a non-tool stop reason. A final answer should be emitted after a non-tool stop condition, not merely because one command ran.

"The client-side application is responsible for executing the tool," — Anthropic, tool-use documentation at Anthropic

This is the practical version of ReAct: reasoning, acting, and observing are interleaved so the model can ground later decisions in tool output instead of guessing. That pattern reduces unsupported answers, but it does not remove the need for verification. A model can still misread a stack trace, overfit to the first matching file, or stop after a shallow check.

Verification belongs inside the loop, before the final answer. After a shell command, feed back exit status and output. After a file read, feed back the relevant content. After an edit, run the smallest meaningful verifier: a focused test, typecheck, lint rule, or reproduction command. OpenAI describes Codex as an orchestrated loop around user input, model instructions, tools, and prior items in its Codex agent loop writeup.

class CodingAgent:
    def __init__(self, prompt):
        self.prompt = prompt
        self.tools = ["read", "edit", "run tests"]
        self.loop = ["observe", "plan", "act", "verify"]

    def solve(self, task):
        return (
            f"Task: {task}\n"
            f"Prompt: {self.prompt!r}\n"
            f"Agent: tools={self.tools}, loop={self.loop}\n"
            "Point: the prompt starts the work; tools, feedback, and verification do most of it."
        )


print(CodingAgent("fix the bug").solve("make the program correct"))
Captured stdout:
Task: make the program correct
Prompt: 'fix the bug'
Agent: tools=['read', 'edit', 'run tests'], loop=['observe', 'plan', 'act', 'verify']
Point: the prompt starts the work; tools, feedback, and verification do most of it.

Where should minimal prompt text stop?

Minimal prompt text should stop at behavioral intent: define the agent’s role, the workspace boundary, the inspect-before-edit norm, a preference for tests as verification, blocked-state behavior, and concise final reporting. Anthropic’s Agent SDK documentation says a minimal default system prompt can support tool calling, while the claude_code preset or a custom prompt string adds product-specific behavior . That boundary keeps the prompt readable instead of turning it into a policy engine.

The prompt should not replace deterministic controls. Tool schemas, deny and ask rules, sandbox policy, lifecycle hooks, and callback checks are better expressed as code because they are typed, testable, and auditable. Claude Code’s hooks run at lifecycle points such as PreToolUse, PostToolUse, PermissionRequest, Stop, and PostCompact . Those checks belong in the harness, not in a paragraph asking the model to be careful.

• Put in the prompt: role, project boundary, inspect before edit, prefer runnable verification, ask when blocked, report changed files and test results.
• Put in the harness: allowed tools, permission modes, sandboxing, approval rules, hook execution, logging, and retry or stop conditions.
• Put in evals: whether the agent edits the right file, stops after enough evidence, and handles failed verification without looping.

The gotcha is permission ordering. Anthropic’s Agent SDK evaluates hooks, deny rules, ask rules, permission mode, allow rules, and then canUseTool-style callbacks; under some configurations, auto-approved calls can make later callback logic unreachable, producing a CLAUDE_SDK_CAN_USE_TOOL_SHADOWED warning . If safety logic is shadowed there, adding more prompt text will not fix it.

What should builders try after the minimal prompt works?

After a minimal coding-agent prompt works, the next iteration should move outward: add explicit stop budgets, verifier steps, durable memory boundaries, hook logging, and narrower tool schemas before adding more prose. Claude Code’s current primitives include skills, subagents, MCP servers, hooks, permissions, and session-level controls, but those belong to the harness and runtime layer rather than the agent prompt itself Claude Code features .

Use failures as routing signals. If the agent edits the wrong file, inspect context assembly, retrieval, repository scanning, and task framing. If it keeps retrying the same failing test, tighten the execution loop with max-turn rules, stop conditions, and a required verifier step. If it attempts a risky shell command, fix permissions, sandbox policy, deny rules, or hooks instead of hoping a longer instruction will restrain it; Claude Code documents hooks for lifecycle events such as PreToolUse, PostToolUse, PermissionRequest, Stop, and PostCompact Claude Code hooks guide .

The useful expansion path is incremental. Skills can package repeatable workflows; subagents can isolate context and tools for delegated tasks; MCP servers can expose external systems through typed interfaces; hooks can record decisions or block risky calls; session-level overrides can change runtime behavior without rewriting the base prompt Claude Code subagents . Treat each addition as product control surface, not as hidden prompt mass.

class CodingAgent:
    def __init__(self, prompt):
        self.prompt = prompt
        self.tools = ["read", "edit", "run tests"]
        self.loop = ["observe", "plan", "act", "verify"]

    def solve(self, task):
        return (
            f"Task: {task}\n"
            f"Prompt: {self.prompt!r}\n"
            f"Agent: tools={self.tools}, loop={self.loop}\n"
            "Point: the prompt starts the work; tools, feedback, and verification do most of it."
        )


print(CodingAgent("fix the bug").solve("make the program correct"))

This verified snippet is intentionally small: the prompt starts the task, while tools, feedback, and verification carry the work. The practical test is simple: remove roughly half the prose from the prompt, keep the same harness controls, and run the same task again. If behavior changes, encode that rule outside the prompt where it can be tested, logged, and enforced.

Frequently asked questions

What is a system prompt in a coding agent?

A system prompt is the instruction layer that defines the agent’s role, behavior, and response boundaries. In a coding agent, it should stay compact: describe how the agent should work, but leave permissions, sandboxing, tool access, and execution policy to the harness. Anthropic’s Agent SDK docs distinguish custom system prompts from the broader product behavior supplied by presets and runtime controls: Claude Code Agent SDK system prompt docs.

Does Claude execute tools by itself?

No. Claude requests tool use through structured output; the surrounding application executes the tool call and returns the result. Anthropic’s tool-use flow describes this as a loop where the model emits a tool request, the client runs the tool, and the client sends back a tool result: Anthropic tool-use docs.

What is the difference between a harness and an execution loop?

The harness owns the runtime around the model: project context, tool definitions, permissions, sandboxing, logs, state, and user interaction. The execution loop is the repeated model-tool cycle inside that runtime: send context and tools, receive tool requests, dispatch calls, return results, and stop when the task reaches a defined stopping condition. OpenAI describes Codex in similar terms as an orchestrated loop around tools, user input, and prior items: OpenAI Codex agent loop writeup.

Why not put all agent rules in one large prompt?

Putting all rules in one large prompt makes failures harder to inspect. If permissions, context loading, retry behavior, and verification policy are all expressed as prose, it is difficult to tell whether a failure came from model reasoning, missing context, a weak tool schema, or an unsafe runtime setting. Deterministic controls such as Claude Code permissions and hooks are easier to audit, test, and change: Claude Code permissions and Claude Code hooks.

What should a minimal coding-agent prompt include?

A minimal coding-agent prompt should define the role, workspace boundary, inspect-before-edit behavior, verification preference, blocked-state behavior, and concise reporting expectations. It should not try to encode every tool rule or runtime policy. For a practical reference point, Claude Code exposes product behavior through features such as project context, tools, subagents, hooks, and permissions outside the prompt itself: Claude Code features overview.