Agentic Architecture Foundations: CCA-F Domain One Through the Lens of the Production Harness

CCA-F Domain One Through the Lens of the Production Harness

<!-- hal:authoritative:yaml -->

CCA-F Domain One Through the Lens of the Production Harness

§I — Frame

An agent is a loop. A model produces output. The output is read. Something acts on the output, or refuses to. The act produces new input. The model is called again. The loop continues until a stopping condition is met.

Every other thing the agent does — calls a tool, reads a file, sends a message, writes to memory — happens inside the loop. The agent is not the model. The agent is not the tool. The agent is the loop plus the harness that holds the loop plus the boundary between what the harness controls and what it does not.

This is the inaugural Anthropic Day cert lesson and it anchors the CCA-F exam's largest domain — Agentic Architecture, 27% of the blueprint. Every other domain on the exam (Claude Code 20%, Prompt Engineering 20%, Tool Design and MCP 18%, Context Management 15%) depends on the conceptual primitive named in this lesson: what an agent is, what it is not, and what the production harness's responsibility is.

The lesson treats agentic architecture through three named frames. The loop itself — its anatomy and its termination. The harness — what it controls, what it observes, what it forbids. The boundary — where the agent stops and the world it acts on begins. Each frame has implications for design decisions a CCA-F candidate must reason about, and each frame surfaces patterns the exam is likely to test.

§II — Foundations: The Loop

An agentic loop has four phases that compose in sequence and repeat.

Phase 1 — Input assembly. The harness collects the input the model will receive on this iteration. The input always includes the conversation history (system prompt, prior user messages, prior assistant messages, prior tool calls and tool results). The input may also include retrieved context (RAG results, file contents the agent requested, search results). The input may include freshly arrived signals (a new user message, a webhook event, a scheduled trigger). Input assembly is the harness's first job; the model sees only what the harness gives it.

Phase 2 — Model call. The harness sends the assembled input to the model API. The model produces output — text content, or tool-call requests, or both. Streaming or non-streaming, the model's output is structured: the harness parses it into typed parts (text content, individual tool calls with arguments) before passing it to the next phase.

Phase 3 — Action. The harness inspects the model's output and decides what to do with it. Text content is rendered to the user or stored for the next iteration's input. Tool calls are routed to handlers — the harness invokes the appropriate function, passes the model's arguments, captures the result, and stores the result for the next iteration's input. Some actions are gated by permission checks; some are forbidden outright; some require user confirmation before proceeding.

Phase 4 — Termination check. The harness decides whether to continue the loop or stop. Common stopping conditions: the model produced text without requesting a tool, indicating it considers the task complete. The model's output exceeded a budget (max tokens, max iterations, max wall-clock time). The user requested a stop. An error rate threshold was breached. The harness applies its stopping rules and either re-enters Phase 1 or exits the loop.

The loop's anatomy is simple. The complexity lives in the harness's decisions inside each phase — what to include in input assembly, how to handle multi-step tool calls, what permission gates apply to which action, when to stop. The CCA-F exam tests fluency with these decisions because the decisions are what differentiate a production agent from a toy.

§III — Mechanism: The Harness

The harness is the code that runs the loop. Anthropic's claude-agent-sdk is one harness; Claude Code is another (a specific harness optimized for software-engineering tasks); custom harnesses authored on top of the bare Messages API are a third. Each harness makes specific decisions about what to control, what to observe, and what to forbid.

What the harness controls. Input shape. Tool registration. Permission gates. Conversation memory. Termination policy. Error handling. Logging. Recovery from partial failures. Cost budgets.

What the harness observes. Model outputs (text and tool calls). Tool results. Latency at every layer. Token consumption per turn. Permission denials. Loop iteration count. User interventions.

What the harness forbids. Any tool call the harness did not register. Any output the model attempts to use to escape the harness (prompt-injection attempts in tool results, attempts to call tools by name the harness does not expose). Any action that violates the configured permission set.

The CCA-F exam frames these responsibilities concretely. A question may show a harness configuration and ask which of several model behaviors would be permitted; the answer depends on what the harness registered, gated, and observed. A different question may show a tool-result chain and ask which of several next-step actions the harness should take; the answer depends on the harness's termination and error-handling policies.

The Claude Agent SDK exposes the harness as a Python or TypeScript framework. A representative agent definition looks like this:

from claude_agent_sdk import Agent, tool, Permission

@tool(description="Read a file from the workspace")
def read_file(path: str) -> str:
    return Path(path).read_text()

@tool(description="Write content to a file in the workspace")
def write_file(path: str, content: str) -> None:
    Path(path).write_text(content)

agent = Agent(
    model="claude-opus-4-6",
    tools=[read_file, write_file],
    permissions=[
        Permission.READ_FILE(scope="workspace/**"),
        Permission.WRITE_FILE(scope="workspace/output/**"),
    ],
    max_iterations=20,
    max_tokens_per_turn=8000,
)

result = agent.run("Read every config file in workspace/ and summarize the differences.")

Every line carries a harness decision. The model field selects which model the agent calls. The tools field is the full set of capabilities the model has access to; nothing else is reachable. The permissions field constrains where the tools can operate. The max_iterations field bounds the loop. The max_tokens_per_turn field bounds the per-call cost.

A CCA-F-certified candidate can read a harness configuration like this and reason about its implications: what the agent can do, what it cannot, how the loop terminates, what happens on tool errors, what observability the harness provides.

§IV — The Boundary

The boundary is where the agent stops and the world it acts on begins. The boundary's design is the most consequential decision in agentic architecture because it determines what the agent is permitted to do that has consequences in the world.

Three boundary classes recur across production agent designs.

Read-only boundary. The agent can observe the world but not change it. Tools read files, query APIs, search documents, retrieve data. No tool writes, sends, or deletes. The risk model is information disclosure only — the agent may surface sensitive data, may produce outputs that reveal system state, but cannot break things. Read-only agents are the safest deployment surface and the natural first step for any team adopting agentic systems.

Confined-write boundary. The agent can change a specific subset of the world. Tools write to a scratchpad, draft a message, create a file in a designated directory. The writes are real but scoped. The risk model expands to include incorrect or harmful writes within the scope — the agent may produce a wrong file, may save data in the wrong format, may overwrite something the user needed. Confined writes require the user to be willing to review the writes and to recover from errors within the scope, but the scope's boundary is the safety guarantee.

Permission-gated action boundary. The agent can perform actions of consequence — send messages, execute trades, modify access controls, delete data — but only after explicit user permission for each instance of each action. The harness gates the action behind a permission check; the user reviews the proposed action and approves or denies; only on approval does the action execute. The risk model is the user's diligence in review. Permission-gated boundaries enable powerful agents while keeping the consequential decision-making in human hands.

The CCA-F exam tests fluency with boundary selection. Given a use case, what boundary class is appropriate? Given a harness configuration, what risk class is the boundary in? Given a tool definition, does the tool sit inside or outside the boundary? These questions are the practical core of agentic-architecture competence.

The choice of boundary is the choice of risk model. A team that wants to deploy an agent for sensitive workflows starts with the read-only boundary and earns the right to widen by demonstrating that the agent's behavior under the narrower boundary was sound. Production agents that operate at the permission-gated action tier have typically passed through the read-only and confined-write tiers first; the team's confidence in the harness's permission-gate is built by experience with the earlier tiers.

§V — Practice Questions

A. Block the call because /etc/passwd is a sensitive path. B. Execute the call because the tool was registered and no gate forbade it. C. Defer to the model's judgment about whether the path is appropriate. D. Prompt the user for confirmation by default.

Answer: B. The harness only forbids what is explicitly gated. A tool registered without a permission gate is invokable on any argument the model produces. The defense against this case is the permission gate, not the tool registration. A CCA-F candidate must internalize that capability is constrained by gates, not by good intentions in the model's prompt.

A. Execute the tool call but do not call the model again; surface the tool result and exit. B. Refuse the tool call, raise an error, and exit. C. Execute the tool call, call the model with the result, and on the 20th iteration's model output check whether to continue. D. Execute the tool call, call the model, and continue indefinitely because the budget is advisory.

*Answer: C. max_iterations is the bound on loop iterations. Iteration 19 is allowed; iteration 20 will be the last. The harness executes the current tool call (part of iteration 19's action phase), assembles input for iteration 20, calls the model, and then on iteration 20's termination check decides whether to exit. The bound is a hard ceiling, not an early-exit trigger.*

A. Read-only — the agent observes ticket content but writes nothing. B. Confined-write — the agent writes drafts to a designated draft directory; the rep reads and sends manually. C. Permission-gated action — the agent proposes a send; the rep approves; the harness sends. D. Open action — the agent sends directly; the rep reviews afterward.

Answer: B. The use case calls for the agent to produce drafts that the human reviews and sends. The write is real (the agent produces persistent draft output) and confined (the writes go to a specific draft surface, not to the customer). The human is in the loop for the consequential action (send). This is the textbook confined-write boundary use case. Option C (permission-gated action) is appropriate when the agent should propose the send action directly; option B is appropriate when the agent's job ends at the draft.

§VI — Connection to Today's Ops + Dev Lessons

Today's Ops lesson named the release-engineering discipline for production frontend systems. The harness that runs Claude-powered agents is a production system in exactly this sense. A new harness version — improved permission logic, better tool-error handling, refined termination policy — ships through the same release-engineering discipline. Canary slicing for harness versions is the same primitive as canary slicing for frontend versions. The agent users get atomic-rollouts of the harness for the same reason traders get atomic-rollouts of the dashboard.

Today's Dev lesson named the browser-side telemetry pipeline. The same pipeline pattern applies to agentic systems that surface a web-based operator interface. Performance Observer for the operator-facing dashboard, TypeScript-typed wire schemas for the telemetry payloads, HTML-native timing surfaces for end-to-end latency attribution — all relevant when the agent has a browser frontend through which the operator engages with it.

§VII — Closing

Agentic architecture is the discipline of designing the harness around the loop and choosing the boundary the loop operates through. Every CCA-F question on Domain 1 reduces to fluency with these primitives. A candidate who can read a harness configuration, identify what the agent can and cannot do, and reason about the risk model the boundary implies is positioned to answer correctly on the exam and to design responsibly in production.

The next Anthropic Day lesson will move to Domain 2 (Claude Code as a specific harness for software-engineering tasks). Each Sunday lesson advances one domain block until the full CCA-F surface is covered, with the agentic-architecture frame established here as the spine.

Read the Ops lesson before this one to ground the production-harness analogy. Read the Dev lesson alongside this one to see the operator-interface telemetry layer that closes the agentic loop's observability surface.