Anthropic's CCA Exam as a Field-Guide for Agentic Engineering

How do you prepare computer science students for a job market in which their degree no longer guarantees a path to employment? Frank Coyle, who introduces himself as a longtime computer science educator now teaching at Berkeley, approaches that question through practical agent engineering. The Claude Certified Architect exam provides a syllabus: its scenarios expose the kinds of decisions developers face when building with Claude. Coyle’s rationale is that Anthropic sees how customers use its systems—and where those systems cause trouble.

The preparation starts with experimentation. Coyle quotes Sister Corita Kent: “Nothing is a mistake. There's no win and no fail. There's only make.” Reading supplies concepts; making something forces you to discover what those concepts leave unresolved. A failed attempt still teaches you how the system behaves.

Coyle follows with the saying he attributes to Thomas Edison about finding ten thousand ways that do not work. That connects experimentation to the object-oriented design-pattern movement of the early 1990s. Agent engineering also has recurring patterns, but anti-patterns are especially useful diagnostic tools: understanding why a design fails helps distinguish plausible solutions from appropriate ones.

The certification launched in March 2026 with partner access. Coyle describes a timed, proctored exam and reports individual access for $99, with an attempt once every six months; those access terms are his account, not established here as current registration policy. The questions are multiple choice, but their difficulty comes from realistic scenarios and constraints rather than isolated terminology.

The five domains span orchestration, development workflows, structured output, tools, and reliability. Coyle’s domain slide gives the following allocation:

These topics connect directly to implementation: configuring Claude Code, expressing outputs as JSON, integrating tools through Model Context Protocol, and controlling what enters the context window. They remain useful areas of study whether or not you sit the exam.

Coyle says each exam selects four of six production scenarios at random and centers its questions on those four. His walkthrough uses anti-patterns to identify what makes a solution unsuitable under a scenario’s constraints.

The scenarios introduce a recurring set of boundaries:

1. Customer support resolution: control the agent loop and inspect stop_reason rather than treating every returned response as finished.
2. Code generation: configure Claude Code for the project it is working in.
3. Multi-agent research: decide how specialists report to an orchestrator, whether to use a hub-and-spoke arrangement, and how much information each participant needs.
4. Developer productivity: isolate subtasks. Coyle compares this to multithreaded programming: shared memory creates synchronization and locking problems, while independent work reduces coordination requirements.
5. Continuous integration: make Claude Code useful in automated pipelines.
6. Structured data extraction: produce structured results from source material.

Structured extraction appears in the scenario overview; the detailed walkthrough proceeds through CI before the closing remarks.

Coyle invokes Boris Cherny and OpenClaw’s Peter Steinberger as examples of developers describing their work increasingly in terms of designing loops that prompt agents. The emphasis feels new, but the underlying control structure is not. He recalls early disputes over the relative power of Fortran and COBOL, then turns to Böhm and Jacopini’s 1966 paper.

The familiar programming vocabulary is sequence, conditional selection, and iteration. Coyle uses it to explain the progression from a sequence of prompts, through conditional routing, to a loop that repeatedly acts on new results. The historical result assumes suitable operations and state; adding a loop alone does not establish that an arbitrary prompt system is Turing complete. The practical connection is that iteration lets a workflow use feedback to decide its next action instead of stopping after a predetermined sequence.

For a customer support agent, the first anti-pattern is accepting a response simply because the model returned one. Coyle’s demonstration instead uses a while True loop: call the model, inspect why generation stopped, and decide what the application must do next. The request includes messages representing the conversation context, the task, and the available tools.

A tool request is a proposal for execution. In the client-tool arrangement Coyle demonstrates, the model prepares the tool name and parameters; application code performs the operation. This is the relevant boundary behind his statement that the model cannot execute tools itself. In current API terminology, stop_reason is a Messages API response field, and this explanation concerns client tools rather than the separately supported server-side tools.

When stop_reason is tool_use, the application executes the requested tool, records its result, and calls the model again. Preserving both the assistant’s request and the corresponding tool result gives the next call the information needed to continue. The Python control flow can be expressed as follows, with tool execution supplied by the application:

import json


def run_support_loop(client, model, messages, tools, run_tool):
    history = list(messages)

    while True:
        response = client.messages.create(
            model=model,
            max_tokens=2048,
            messages=history,
            tools=tools,
        )

        if response.stop_reason != "tool_use":
            return response

        history.append({
            "role": "assistant",
            "content": [block.model_dump() for block in response.content],
        })

        results = []
        for block in response.content:
            if block.type == "tool_use":
                value = run_tool(block.name, block.input)
                results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": json.dumps(value),
                })

        history.append({"role": "user", "content": results})

The application’s run_tool function owns dispatch and execution. The loop returns the whole response when it reaches a different stopping condition so the caller can inspect that condition before accepting the answer.

After a completed turn, Coyle proposes checking whether the answer is suitable and escalating to a human when it is not. He describes this as checking confidence, without specifying a score or threshold. Completion and acceptance are separate decisions.

Token limits create another branch. A response may be partial even though it contains plausible text. In current Messages API terminology, max_tokens means generation reached the requested output limit, not necessarily that the entire context window is exhausted. Treat end_turn as a completed model turn, tool_use as a request for further action, and max_tokens as a condition requiring recovery or review before using the output as a finished answer.

Claude Code’s CLAUDE.md files provide persistent Markdown instructions. Coyle presents a three-level hierarchy, illustrated on the slide as user, project, and directory scopes. Broad preferences belong near the top; project conventions and directory-specific guidance belong closer to the work they govern.

The hierarchy controls which guidance is available as the system works through a codebase. The slide summarizes conflicts as the most specific file winning. Treat that as Coyle’s framing rather than an enforced precedence mechanism: current Claude Code documentation describes additional scopes, loads nested instructions when relevant files are read, and treats these files as model context rather than hard configuration rules. The useful design principle is to keep instructions scoped to the work they describe.

A multi-agent research system must get useful work back from its agents without turning every agent into a generalist. Coyle’s anti-pattern is one agent loaded with tools for everything. His analogy is hiring a carpenter who arrives with plumbing, electrical, and carpentry equipment and promises to do any job. For a carpentry task, a specialist may be the better fit.

The corresponding software principle resembles a function that does one thing. Coyle recommends narrow agent responsibilities, perhaps with one or two tools available to each specialist. He then extends the boundary to context: a worker’s accumulated material should not automatically spill into the main conversation. More context consumes tokens, and irrelevant material can make the next decision harder. A large context window is capacity, not an instruction to fill it.

The critic agent makes this concrete. After an agent produces a claim, pass the critic the claim and its evidence, without the thought process that produced the claim. The critic has what it needs to evaluate support while receiving less material that might steer it toward the original agent’s conclusion.

Coyle describes the failure mode as groupthink: agents collaborating through a shared conversation can converge on one idea. His analogy is a party where everyone wants pizza except one person, who eventually goes along. Giving each agent its own informational slice is intended to preserve independent evaluation. The boundary is selective: the critic still needs the evidence, just not the entire conversation that led to the proposal.

The developer-productivity scenario applies the same boundary to long sessions. Two anti-patterns reinforce each other: allowing every subtask to dump its complete output into the primary thread, and allowing that thread to grow without limit. Isolate the subtask first, then decide what information should return.

Coyle’s example is log analysis: scan the logs for errors in a separate context. In current Claude Code skills, context: fork is skill frontmatter that requests subagent execution. A skill for that task can carry an actionable instruction:

---
name: summarize-log-errors
description: Scan project logs and summarize errors.
context: fork
---

Scan the project logs for errors.
Return a concise summary of the problems, with representative
log lines and file locations. Do not return the complete logs.

The separate context holds the worker’s investigation instead of adding all of it to the primary conversation.

The worker returns a summary of the problems, which the main conversation can use without absorbing the full intermediate output. Coyle then adds a second control: monitor context size and compact long sessions. His example invokes /compact above 150,000 tokens; that is an illustrative trigger, not a stated product default. Compaction reduces accumulated context, but Coyle explicitly says he does not know the implementation of Anthropic’s algorithms.

That leads to application-specific compression. Coyle points to a book by Sam Bhagwat being distributed at the event, noting that he has no connection to its author. He recalls a passage around page 32 describing custom context-compression logic and a base class developers can extend. The architectural opportunity is to preserve what matters to the application when compressing its data, rather than assuming every detail deserves equal space.

Continuous integration exposes a different anti-pattern: an interactive agent waiting for answers in an unattended pipeline. Permission questions that make sense at a developer’s terminal can stall a job when nobody is there to respond. Coyle recommends configuring noninteractive execution; the engineering requirement is to establish the permitted work before the pipeline runs.

For deferrable work, the Message Batches API offers a separate cost tradeoff. Asynchronous Message Batches requests receive a 50% discount on input and output token prices relative to standard API calls. This is cheaper processing of tokens, not a reduction in the number of tokens used, and it is an API service rather than a generic Claude Code batch mode. Coyle’s spoken timing is “at least twenty-four hours,” but the slide shows ≤24h and the service announcement specifies processing within 24 hours.

The distinction is whether the work can wait. A pipeline with someone waiting for its result needs an unattended path without unnecessary delay. A collection of prompts that can finish while the developer takes a nap, takes a day off, or goes on vacation can trade immediacy for lower token prices.

Coyle closes by adapting the opening quotation: “there's no exam, only make.” The certification supplies problems to practice, but building is the work that turns them into understanding. He invites readers to stay in contact and points them to his website, codesupremeai. The name reflects his enthusiasm for jazz and John Coltrane’s A Love Supreme: an appropriately personal ending to a field guide built around experimentation.