I recently passed Claude Certified Architect, Foundations (CCAR-F), Anthropic’s scenario-based certification for people who design production applications on Claude. The credential itself is a milestone. What stuck with me afterward is simpler and harder: agentic AI is easy to demo and difficult to operate.
The exam does not reward trivia about model names. It throws you into realistic situations—support workflows, research pipelines, CI with Claude Code, multi-step tool use—and asks which architectural choice you would make when latency, cost, safety, and maintainability all pull in different directions. That mirrors what I see in consulting every week. The first chatbot sketch ships in an afternoon. The system that still answers correctly six months later, under real documents, real permissions, and real users who do not read the docs, is a design problem.
This post is not an exam recap. It is how I think about agentic systems design and context management after studying for the certification and shipping LLM work in production.
Why the hype curve hides the hard part
We are in a phase where “agent” has become a marketing default. A loop that calls an API twice is not automatically an agent; neither is a chain with a fancy name. What actually changed is that models became good enough to plan, use tools, and recover from partial failure—if you give them a structure that fails gracefully when they cannot.
Prototypes feel great because:
- You control the prompts and the demo questions.
- Context fits in one window because you curated the example.
- Tool errors are rare or hand-waved.
- “Human in the loop” means you, sitting next to the laptop.
Production removes those guardrails. Users paraphrase. PDFs are scanned sideways. APIs time out. Someone asks for data they are not allowed to see. The model still produces fluent text. Reliability is mostly architecture, not a bigger model.
The Foundations certification encodes that mindset: Claude Code, the Agent SDK, the Messages API, and MCP are not a checklist of buzzwords. They are levers for separating concerns—what the model decides, what code enforces, and what context it is allowed to see.
Agentic systems design: structure before charisma
When I design an agentic system, I start from the decision the organization needs, not from “make it autonomous.”
Define the boundary of agency
Not every step should be model-driven. A useful pattern:
| Layer | Who owns it | Typical responsibility |
|---|---|---|
| Policy | Your application | Auth, quotas, allowed tools, PII rules |
| Orchestration | Code (SDK, graph, workflow engine) | Steps, retries, branching, human gates |
| Reasoning | Model | Interpret intent, choose among allowed actions |
| Execution | Tools / APIs | Side effects with idempotency and audit logs |
If the model can trigger an irreversible action without a deterministic check, you do not have an agent—you have a liability with good prose.
Prefer explicit graphs over implicit loops
Open-ended “keep going until done” loops are fine in notebooks. In production, I want named states, exit conditions, and maximum iteration budgets. LangGraph-style graphs, workflow runners, or even a boring state machine often beat a single mega-prompt because they make failure visible: you can see which node mis-routed, which tool returned garbage, and where to add a validator.
The certification scenarios push the same idea: when should work be parallelized? When must it be sequential because context builds on prior tool output? When is a sub-agent worth the extra cost versus one orchestrator with narrow tools?
Tools are contracts, not Python functions with hope
Each tool should have:
- A narrow description (what it is for and what it is not for).
- Structured inputs with validation before the call.
- Structured outputs the model can parse—or better, outputs that code parses so the model never sees raw JSON soup unless necessary.
- Clear error surfaces (“not found” vs “forbidden” vs “upstream 503”) so the orchestrator can retry, escalate, or refuse.
MCP fits here as a standard way to expose capabilities to agents without hard-wiring every integration into the prompt. The architectural win is discoverability and permission boundaries; the operational win is swapping backends without retraining your entire prompt library.
Evaluation is part of the design, not a phase after launch
Agentic systems fail in compound ways: wrong tool, right tool with wrong args, good answer with no citation, good citation to the wrong paragraph. I plan eval harnesses early—trace-level checks, golden tasks, regression sets built from real support tickets (redacted)—the same way I would for RAG faithfulness. If you cannot measure “did it use the right tool for this intent,” you cannot improve it.
Context management: the silent budget
Every agent is a context budget problem dressed up as intelligence. The model only sees what you put in the window; everything else is folklore.
Separate “instructions,” “state,” and “evidence”
Confusing these is the fastest way to blow the window and confuse the model:
- Instructions — Stable system behavior, tool rules, tone, refusal policy. Change rarely; version in git.
- State — What step we are on, compact summaries of prior turns, structured scratchpad fields maintained by code.
- Evidence — Retrieved chunks, API payloads, user uploads. Ephemeral, often large, must be cited or discarded.
Mixing evidence into instructions (“here are 40 PDF pages in the system prompt”) teaches the model that everything is equally authoritative. It is not.
Retrieve, do not dump
For knowledge-heavy agents, RAG is still the workhorse: chunk with metadata, filter by tenant and ACL before retrieval, hybrid search when keywords matter, and return only what the turn needs. I treat retrieval as a compiler optimization—dead code elimination for tokens.
When the Agent SDK or Claude Code pulls repository context, the same principle applies: scoped context beats “send the whole monorepo.” Hooks, rules files, and .claude configuration are not aesthetics; they are how you keep the model focused on the subtree that matters.
Compaction and memory are policies, not features
Long-running agents need explicit summarization boundaries: after N tool calls, after a sub-task completes, or when the window crosses a threshold. Summaries should be structured (“open questions,” “decisions made,” “IDs still needed”) so the next turn does not hallucinate closure.
“Memory” products are tempting shortcuts. Durable memory without governance becomes stale or leaky context. I default to: store facts in systems of record (CRM, ticket DB, vector store with TTL), inject only what the policy allows for this session, and log what was retrieved for audit.
Multi-agent context: fan-out costs real money
Splitting work across sub-agents can improve quality, but each handoff duplicates instructions and summaries. Architecturally, ask whether sub-agents get fresh minimal context plus a brief from the orchestrator, rather than a copy of the entire thread. The exam’s multi-agent scenarios are really about information hiding: what does each participant need to know to act, and what should they never see?
From certification to Monday morning
Passing CCAR-F validated that I can reason about tradeoffs under pressure—tool design, orchestration, API usage, MCP, Claude Code in delivery pipelines. Day to day, the certification aligns with what I already push on engagements: thin vertical slices, measurable acceptance criteria, and honesty about when a workflow should stay assistive (human approves) versus autonomous.
If you are building agentic systems today, the skills that compound are not prompt tricks. They are:
- Drawing hard boundaries around tools and data.
- Managing context like a scarce resource with retrieval, compaction, and clear separation of instruction vs evidence.
- Testing traces, not vibes.
- Choosing orchestration that fails visibly instead of loops that fail silently.
Demos will keep getting easier. Production will keep punishing designs that treat the context window as infinite and the model as infallible. That gap is where architecture lives—and why, after the hype settles, the people who can design agentic systems that hold their ground will still be in demand.
Anthropic’s official program page for the credential is Claude Certified Architect – Foundations. Exam policies, blueprints, and preparation materials live in Anthropic Partner Academy; always treat the published exam guide as the source of truth.