The Anatomy of a Coding Agent: Thinking Protocols, Tool Calls, and Context Strategy
From Software to Agents
How are agents different from traditional software?
Traditional software performs pre-defined actions triggered by users. The sequence of actions behind each button is thoroughly designed and implemented by software engineers in advance. In this model, uncertainty is treated as a bug: the program should behave deterministically given the same inputs.
Agents, on the other hand, embrace uncertainty. An agent receives a goal, then:
- Interprets requirements (often incomplete or ambiguous),
- Plans by decomposing the goal into sub-tasks,
- Selects and uses tools (files, APIs, command line, web search, etc.),
- Verifies outcomes and updates its plan based on results,
- Communicates progress and asks for clarification when needed.
The key difference is agency: the system can decide what to do next without being explicitly told the step-by-step procedure.
Take Claude Code as an example. When I “vibe-code” with it, I usually prepare a brief Product Requirement Document (PRD) outlining the purpose, target users, key functionalities, architectural constraints, and design style. Then I ask it to “develop this product based on the PRD”, hit Send, and step away—returning later to iterate on a functional prototype.
If we examine what happened in between, Claude Code typically does the following (not in a fixed order, but as needed):
- Gather context — read local files, inspect repository structure, search docs, recall earlier messages.
- Plan — sketch milestones and a to-do list.
- Execute — install packages, run commands, write and refactor code, create tests, fix errors.
- Branch and recover — try an approach, hit an error, backtrack, choose another approach.
- Summarize — report what changed and what remains, and ask the human to confirm key decisions.
What is striking is that the user can provide only a high-level instruction, and the system works out the operational details by combining reasoning with tools—much closer to how a human teammate operates.
How do agents think and act in a system — the system architecture
How is Claude Code capable of doing all that? To answer this, we need to dissect the architecture of an agentic system: the orchestration layer that wraps an LLM with memory, tools, permissions, and interaction patterns.
1) Entry Layer
Similar to the front-end of any software, the Entry Layer is where users interact with the agent. For Claude Code, this is typically a chat-like interface, plus additional “entrants” such as:
- slash commands,
- file attachments,
- code diffs and review UI,
- run/stop controls.
This is where user intent is expressed. But intent is often fuzzy, and small UI design choices (defaults, warnings, confirmation dialogs) can profoundly shape risk outcomes.
2) Session Layer
The Session Layer manages the ongoing dialogue and keeps the agent’s task state coherent. It typically includes:
- conversation history and system instructions,
- user-provided artifacts (PRDs, screenshots, code snippets),
- task metadata (goals, constraints, deadlines),
- intermediate plans and decisions.
A “session” becomes a container of accountability. Policies that used to apply to a single API call may need to apply to a sequence of actions carried out under one conversational mandate.
3) Agent Loop (Plan → Act → Verify)
At the core is an agent loop that runs repeatedly until the goal is satisfied or the user stops it:
- Gather context (retrieve relevant files, docs, prior decisions)
- Act (execute tool calls)
- Verify (tests, linting, sanity checks, diff inspection)
Source: How Claude Code works — Claude Code Docs
The LLM functions as the “brain” that decides which action to take next, while tools provide real-world leverage.
While existing governance often assumes a clear boundary between decision and execution, Agent loops blur this. The agent can both decide and execute—with speed, iteration, and persistence. It breaks down an ambiguous task into concrete steps, enters the agent loop for execution, and sometimes calls on subagents to complete side-tasks, each running in a similar agent loop.
4) Permission Layer
The Permission Layer defines and enforces what the agent is allowed to do:
- Read permissions (which files, which repositories, which data sources)
- Write permissions (what can be modified, where changes can be committed)
- Execution permissions (what commands can be run; what network calls can be made)
- Escalation and consent (when human approval is required)
In mature systems, permissions are scoped (time-bound and resource-bound) and audited (every sensitive action leaves a trace). In an agentic system, permission is still a first-class governance mechanism. Instead of relying solely on “acceptable use policy”, agentic systems operationalize policy into enforceable controls.
5) Tools
Tools are the agent’s hands:
- filesystem read/write
- package management
- test runners and build systems
- code search
- browser/web retrieval
- APIs to external SaaS systems
Each tool is a risk surface. Governance needs a “tool registry” view: what tools exist, what they can access, and what safeguards wrap them.
6) Extensions / MCP Servers (Capability Expansion)
Claude Code and similar systems increasingly support an “open tool ecosystem”: plugins, extensions, and MCP servers. This is analogous to mobile app stores or browser extensions—but with an important twist: extensions can be executed as part of autonomous chains.
Extension ecosystems should require certification, permission prompts, kill-switches, and provenance tracking—because third-party tools can become part of a high-impact action chain.
Memory, Context Engineering, and Transparency
Claude Code embodies sophisticated context engineering. Its context system can be discussed in three layers:
1) Persistent Memory
Persistent memory stores durable knowledge: preferences, recurring project conventions, long-lived repositories, and stable policies (e.g., coding style, security constraints). In Claude Code, this means a CLAUDE.md file in the user’s home directory that retains key information such as user profile, strict “deny” policies and so on. Users can inspect and edit the persistent memory easily, but it also raises the question of risk of deletion by negligence.
2) Session Memory
Session memory includes everything the agent uses to reason within the current task: message history, intermediate plans, retrieved file snippets, tool outputs, and decisions.
Most agents, including Claude Code, practices regular compression to retain only important information. Agents cannot load the entire world; they selectively retrieve relevant context and summarize it to fit within limited attention.
Governance value: If the system can show what it retrieved and why, it becomes more auditable and less “black box”.
3) External State (Repo / Git as Accountability Substrate)
For ease of rewinding any action on local disks and forking conversation, Claude Code incorporates a git-based mechanism by invoking the system's native version control tools. For coding agents, Git is more than version control; it becomes an accountability mechanism:
- every change is diff-able,
- every commit can carry intent and rationale,
- every regression can be traced.
This shifts governance from “trust the model” to “trust the process + artifacts”.
Transparency: what should be logged?
To support oversight without exposing secrets, an agentic coding system should ideally log (at an appropriate access level):
- high-level plan and milestones,
- tool calls (what tool, what scope, what result),
- diffs produced (with sensitive redaction where needed),
- tests run and outcomes,
- approvals given/denied and who gave them.
This directly responds to two governance needs:
- technical: how context retrieval, state management, and decision-making work at scale;
- policy: how we reduce the “black box problem” to something inspectable and auditable.
Control & Intervention Layer: Permissions and HITL
In an agentic system, purely autonomous execution and purely manual oversight are two ends of a spectrum. To balance them, Claude Code integrates a fine-grained, interactive control layer that turns permissions and human-in-the-loop (HITL) dynamics into a unified governance mechanism, rather than relying on one-time admin configurations.
Scoping Permissions
A robust permission model should support:
- time scope: allow once, allow for the session, or allow persistently;
- resource scope: a folder, repo, or domain allowlist;
- operation scope: read vs write vs execute vs network;
- data-class scope: secrets, PII, regulated data.
Approval Mechanics and HITL
Human-in-the-loop is built directly into the agentic loop, acting as a policy lever at sensitive boundaries. The system can request approval for actions such as writing to files, running risky commands, accessing external services, or publishing artifacts.
Humans can intervene to steer or stop the agent via:
- interrupts (stop current action chain),
- clarifying messages (change requirements mid-flight),
- review gates (approve diffs, commands, or deployments),
- forced exit (terminate the run).
The key design goal is that approvals and interventions must be meaningful (clear risk explanation) and non-fatiguing (avoid prompting for every trivial step). However, this lever only works if the human sees the right information at the right time, the system is honest about uncertainty, and the interface makes “stop” easy and socially acceptable.
Auditability
A governance-aligned design treats all “permission and intervention events” as first-class audit objects:
- what was requested,
- what was approved or denied, and by whom,
- what was actually executed,
- what artifacts were changed.
This aligns strongly with zero-trust principles: “never trust, always verify”—but applied to agent actions rather than just network traffic.
An Open System: skills, tools, and MCP servers
Modern agents are “platforms”, not closed products. Users can add:
- new tools,
- new skills,
- new MCP servers,
- organization-specific integrations.
This openness is what makes agents powerful—but also what makes them governance-challenging:
- the capability boundary is no longer stable,
- third-party tool quality varies,
- the agent can stitch tools together in novel ways.
We need governance that is adaptive, not static—more like cloud security posture management than traditional software certification.
The Bridge to Digital Governance: Technical decisions are policy decisions
Claude Code's architecture is not merely a technical blueprint; it is a blueprint for modern digital governance. In traditional software, governance is often an external compliance layer applied post-development. In agentic systems, technical architecture is governance strategy.
The mapping is direct: the fine-grained Permission Layer operationalizes Zero Trust Architecture; the tool registry and MCP ecosystem map directly to supply chain risk management; context engineering and logging redefine data lifecycle and auditability. When we shift our perspective from a single coding tool to organizational digital governance, it becomes clear that technical decisions are inherently policy decisions.
The rise of agents challenges the existing digital governance framework because:
- the “actor” is no longer purely human or purely software,
- decisions and execution are intertwined,
- action chains can be long, fast, and partially opaque,
- the probabilistic nature of an LLM-powered agent means actions are not always reproducible,
- capabilities evolve via extensions,
- uncontrollable evolutionary costs (token and compute consumption during autonomous multi-agent loops),
- risk of goal drift over long, complex reasoning chains where the agent deviates from its original mandate.
A deep dive into Claude Code suggests several lessons for digital policy in the age of AI:
1) Treat agents as operators, not features
Policy frameworks should treat agents as semi-autonomous operators acting under delegated authority. That implies:
- explicit delegation scope,
- role-based access control for agents,
- clear accountability mapping to human owners.
2) Shift from document-based compliance to control-based governance
Instead of relying only on policies written on paper, build enforceable controls:
- scoped permissions,
- approval gates,
- logging and audit trails,
- provenance of tools and code changes.
3) Make transparency usable, not performative
Logs are only helpful if they are understandable and reviewable. Systems should surface:
- “what I did”
- “why I did it”
- “what I’m about to do next”
- “what could go wrong”
4) Govern the tool ecosystem (extensions) like critical infrastructure
Extension and MCP ecosystems need:
- permission manifests,
- code signing / provenance,
- automated risk scoring,
- revocation and kill-switches,
- least-privilege defaults.
5) Build for failure: assume misalignment, error, and abuse
Agents will make mistakes. Some will be exploited. Governance must assume failure and mitigate impact via:
- sandboxing and containment,
- rate limits and blast-radius reduction,
- continuous monitoring and anomaly detection,
- incident response playbooks for agent behavior,
- evolutionary cost management: enforcing budget caps on tokens and compute to prevent runaway loops,
- deviation monitoring: detecting and halting the agent when it drifts from its original mandate.
Conclusion
Claude Code is not only a productivity tool; it is a preview of how agency will reshape software and, by extension, digital governance. As agents become capable of planning, acting, and verifying with increasingly broad tool access, policy must evolve from static rules toward operational control systems: scoped permissions, auditable action chains, and accountable delegation.
The core message is simple: in an agentic world, architecture is governance. The design decisions we make—about memory, tooling, permissions, and interfaces—are not merely technical choices. They are policy choices that determine safety, accountability, and trust at scale.