Deconstructing Agentic Architectures: A Deep Dive into the Claude Code Harness and Implementation

The rise of "agentic" coding tools, such as Claude Code, has fundamentally shifted the perception of Large Language Models (LLMs) from simple chat interfaces to autonomous software engineers. However, beneath the surface of these seemingly intelligent entities lies a sophisticated orchestration layer known as an Agentic Harness. To understand how these agents function, we must move past the "magic" and examine the deterministic software loop that manages state, tools, memory, and safety.

The LLM: A Stateless Token Predictor

At its core, an LLM is not an agent; it is a stateless text predictor. Whether utilizing Claude 3 Opus or Son/net, the underlying mechanism remains constant: the model predicts the most probable next token in a sequence based on the provided context.

Crucially, the model possesses no inherent memory of previous interactions and no intrinsic ability to interact with your local file system. It is entirely dependent on the Context Window—the total amount of information (tokens) passed into the prompt during a single inference call. If an event or piece of data does not exist within that window, it effectively does not exist for the model.

The Agentic Harness: The Orchestration Layer

An agent is defined by its harness. While the LLM acts as the "brain," the harness provides the body and the senses. An effective agentic architecture consists of five primary building blocks:

1. The Model: The inference engine (e.g., Anthropic's Claude series).
2. Tools: I/O interfaces that allow the model to interact with the external world.
3. Memory: A mechanism for persistent information retrieval.
4. Context: The structured assembly of all data fed into the current prompt.
5. Guardrails: Software-defined constraints and permission systems.

1. Tool Calling and JSON Schemas

The most critical feature of an agent is Tool Calling. It is a common misconception that the model "runs" code or executes bash commands. In reality, the model merely outputs structured text—typically in JSON format—that requests a tool execution.

The harness provides the model with a "menu" within the system prompt. This menu includes:

• Tool Name: (e.g., read_file, bash_command).
• Description: A natural language explanation of when to use the tool.
• Parameter Schema: A JSON schema defining the required arguments (e.g., path as a string).

When the model decides to act, it outputs a payload such as:

{
  "type": "tool_call",
  "name": "write_file",
  "arguments": {
    "path": "src/main.py",
    "content": "print('Hello World')"
  }
}

The harness intercepts this output, parses the JSON, executes the actual Python function (the implementation), and then feeds the result back into the context window for the next iteration of the loop.

2. Memory: Persistent Context Injection

Since LLMs are stateless, "memory" is an illusion created by the harness through file-based persistence. In advanced implementations like Claude Code, memory is managed via specific artifacts such as claude.md.

This involves two distinct strategies:

• Always-on Memory: Files that are injected into every system prompt to provide permanent project context.
• On-demand Memory: The model uses a tool (like read_file) to search through a memory directory or specific Markdown files when it encounters a gap in its knowledge.

3. Context Engineering: Assembling the Prompt

The "intelligence" of an agent is often a direct result of high-quality Context Engineering. A single prompt sent to the model is actually a massive, concatenated string comprising several layers:

• System Prompt: The foundational instructions (e.g., "You are Claude Code...").
• Tool Definitions: The JSON schemas for all available tools.
• Skill/Knowledge Definitions: Markdown-based instructional files.
• Conversation History: The accumulated messages array, including previous user queries and assistant responses.
• Tool Results: The outputs from previously executed tool calls.

As this context window fills up—potentially reaching hundreds of thousands or even millions of tokens—the complexity of managing this "wall of text" increases. If the context becomes too saturated with irrelevant history, model performance can degrade.

4. Guardrails: Enforcing Safety via Software Logic

Guardrails are not part of the LLM's weights; they are if/else statements within the harness. For example, a Human-in-the-loop (HITL) guardrail is implemented by checking if a tool call involves a "destructive" action (like rm -rf).

If the harness detects a high-risk command in the JSON payload, it pauses execution and prompts the user for manual approval. The model cannot override this because the decision to execute or abort happens in the Python/Node.js runtime, entirely outside the LLM's predictive capabilities.

Implementing a Minimal Agentic Loop in Python

Building a functional agent requires a recursive or iterative loop. Below is the architectural logic required to implement an agentic turn:

1. Initialize: Load system prompts and tool definitions.
2. The Loop (up to $N$ turns):
   • Send messages array + tools schema to the LLM.
   • Receive response.
   • If response is Text: Print to user and terminate/continue.
   • If response is a Tool Call:
     • Check Guardrails (e.g., Is this command in the allow_list?).
     • Execute the corresponding Python function.
     • Append the tool call and the result to the messages history.
     • Repeat the loop with the updated context.

By implementing this loop, we transform a simple text predictor into an autonomous agent capable of navigating file systems, executing code, and solving complex engineering tasks through iterative reasoning.