Five Agent Anti-Patterns — Anthropic's Certification Exam Answers All Point the Same Way: Give Less

What the Claude Certified Architect exam is

Start with the exam itself. Claude Certified Architect is Anthropic's first official technical certification. The Foundations tier carries the code CCAR-F, and Pearson VUE delivers it either online-proctored or at a test centre. Sixty questions, 120 minutes, scored on a 100 to 1,000 scale with a passing mark of 720. The credential is valid for twelve months.

It is closed-book with no AI assistance, and it covers agentic architecture, MCP integration, Claude Code workflows, prompt engineering, and context management.

But this article is not about the credential. The point is that the question list is useful even if you never sit the exam. The speaker's reasoning is simple: Anthropic sees more than anyone else about how people actually use its systems and where they break them. If that company writes the questions, the question list is the list of things that break in the field.

The speaker has taught computer science for over thirty years, and he says he came to this exam while looking for something to hand students at a time when he has to tell them a computer science degree no longer guarantees a job.

Why start from the wrong answers — the anti-pattern catalogue

There is a method underneath the talk: start not from what you should do but from what you should not.

The precedent he cites is the software design pattern movement of the early 1990s. As object-oriented programming settled in, catalogues of "do it this way" patterns appeared — and at almost the same time, catalogues of anti-patterns, of "do not do this." The list of ways to fail landed faster in practice than the list of ways to succeed.

That is what we need now, he argues: an anti-pattern catalogue for agents. Advice on building agents well is everywhere; a list of what quietly breaks them is rare.

The Edison line he quotes fits: "I have not failed. I have only found ten thousand ways that don't work." The five below are five of those ten thousand that people step on often.

The weighting says it first — design is the largest slice

Here are the five domains and their weights from the exam blueprint. The numbers below are as shown on the presentation slide.

When the loop got filled in — a 1966 proof

Before the anti-patterns, the talk detours to 1966 to explain why agents suddenly feel different now.

In the early days of computing, programming languages were multiplying and people argued over whose language could do more. In 1966 Corrado Böhm and Giuseppe Jacopini settled it with a proof: any computation needs only three things. Executing statements in sequence, branching on a condition, and looping.

Map that onto AI today and the picture sharpens. Firing off a prompt and getting an answer is sequence. Branching on a condition is something many people already do. But the loop was missing — feeding the answer back in, getting another, feeding it back again.

Part of why agents feel different is that models got better, but structurally it is the moment that third piece got filled in. Which is why the first anti-pattern is about the loop.

Anti-pattern one — do not use the response directly; look at why it stopped

Start with the most common mistake: call the model, take the answer, use it as is.

First a misconception to clear. An LLM cannot execute tools. It cannot do anything except predict the next word probabilistically. Hand it a tool and it still cannot run it — it can only tell you "call this tool with these values." Your code is what actually calls it.

So when the response arrives you do not use the answer; you look at stop_reason first — why the model stopped. If it is tool_use, run the tool, feed the result back, and go around again. If it is end_turn, exit the loop.

There is one more. When the model stops because it ran out of tokens, a response still comes back, and it still reads plausibly. But it is a truncated answer. Without checking stop_reason you take it for a finished answer and use it. This is where things go wrong quietly.

Exiting the loop is also where a human belongs. Check the confidence; keep it if it looks good, escalate if it does not.

while True:
    resp = client.messages.create(
        model="claude-opus-5",
        messages=messages,
        tools=tools,
    )

    # Look at why it stopped before using the answer
    if resp.stop_reason == "tool_use":
        result = run_tool(resp)          # your code runs the tool
        messages.append(result)          # feed it back, go around again
        continue

    if resp.stop_reason == "max_tokens":
        raise RuntimeError("truncated — do not treat this as a finished answer")

    break                                # end_turn: exit

Anti-pattern two — do not pile rules into one file; put them where they apply

The second concerns generating code with Claude Code. You write what you want it to know into a markdown file called CLAUDE.md, and the common anti-pattern is piling every rule into that one file.

Anthropic recommends splitting it into levels. A CLAUDE.md in your home directory applies to every project, one at the project root applies to that repository only, and one inside a directory applies only when you work in that folder. All three load and merge, and when they conflict the most specific file wins.

Put everything in one file and instructions needed only in one folder follow you into unrelated work. They collide quietly. It does not surface as a failure — results drift slightly off, and you cannot see where the conflict happened.

This connects to an earlier piece here, "How do you write a CLAUDE.md that Claude actually follows?" That one was about how to write a single file. This is about where to put it.

Anti-pattern three — do not attach every tool; split the agent

The third is about running several agents. The analogy in the talk is exact. You hire a carpenter and he shows up with plumbing tools, carpentry tools and electrical tools, announcing he can do anything. You probably do not want that person. You wanted a proper carpenter.

The slide puts the line at four or five tools; the speaker said one or two out loud. Either way the direction is the same. Past that line, reasoning quality drops and tool selection gets unstable. So instead of growing the tool belt, split the agent — make each one do a single thing. It is the old functional-programming rule that a function should do one thing, carried straight over.

Alongside that: do not let a subagent's context spill into the main one. Context is tokens and tokens are money, but the bigger point is that more context makes the model more confused and the answer less accurate.

The most striking code in the talk was a critic agent — an agent built to check earlier work — and what it receives is exactly two things: the claim and the evidence. The reasoning that produced the claim is deliberately withheld.

Giving less information to the agent whose job is verification sounds backwards, and the reason is groupthink. Put several agents together talking to each other and they converge on one idea. Like being at a party where everyone wants pizza except you, and you go along rather than spoil it. Agents behave the same way. So each agent gets only its own slice.

Anti-pattern four — isolate long output, and compact when it grows

The fourth is letting context grow unbounded.

Two remedies. One is isolating subtask output. Work that produces a lot of output — scanning all the logs for errors, say — goes into a separate context. The talk calls it a fork. The verbose output stays in there, and only a summary comes back to the main conversation.

The other is compacting long sessions. Count the tokens and run a compaction past a threshold. The threshold in the talk's code was 150,000 tokens.

Two reasons to be frugal with context. Context is tokens and tokens are money, that is one. The other is that more context makes the model more confused and the answer less accurate.

It is easy to think a million-token window means you can put everything in. The opposite holds: limiting what goes in is what makes it accurate.

Anti-pattern five — do not call the agent interactively inside CI

The last is running inside a pipeline, and the anti-pattern is a little funny. Call the agent in conversational mode and it stops at a permission prompt — "may I do this?" — waiting for an answer nobody will give. Waiting for a human where there is no human.

Run it non-interactively and take the output as JSON so the pipeline can read it.

One addition here is the Batch API. Bundle prompts and work into a batch and the token cost is halved, with results promised within 24 hours. If the answer is not needed right now, that is the right place for it.

One thing to try today

One thing runs through all five: every answer gives less. Fewer tools, less context, less information.

Handling agents well gets talked about as the ability to attach more, and this exam picked the opposite — knowing what not to give.

If you pick one thing to check today, make it the third. Open the agent, custom GPT or MCP setup you are using and count the tools attached. Past four or five, odds are half of them are never used. Detach that half, ask for the same work, and the answer changes.

Then CLAUDE.md. If one file has more than twenty lines stacked up, find the lines needed only in one folder and move them into that folder's CLAUDE.md. Not deleting — relocating.