Anthropic CCAR-F: Claude Architecture Lab: Build a Bounded Support Agent End to End

A useful Claude architecture exercise should force an engineer to choose what the model is allowed to decide, what the application must enforce, and how the system behaves when evidence is missing. This end-to-end lab builds a bounded support-incident assistant: it can investigate a service report, retrieve approved runbooks, propose a diagnostic next step, produce a structured handoff and stop safely when authority or information is insufficient. It deliberately does not give a language model unrestricted access to production changes.

This lab exercises the design decisions associated with Anthropic CCAR-F through a practical support incident. Its pseudocode is not production-ready: identity, policy, concurrency, logging and provider integrations need genuine implementation and tests. The Anthropic syllabus defines exam scope; the following decisions are engineering examples, not recalled examination questions.

Define a narrow, testable support problem

Assume engineers receive incidents involving application latency, failed deployments and unexpected service errors. The assistant may classify the incident, inspect authorized telemetry, compare recent deployment changes, retrieve incident runbooks and draft a recommendation. It may not edit infrastructure, reveal a different team’s private data or declare an incident resolved without a human or deterministic system verifying the outcome. Every answer must identify the evidence used and express unresolved conflicts instead of smoothing them away.

Turn that into acceptance criteria before adding the model. An ordinary read request should succeed within the response-time target, a permission denial must halt protected retrieval, a missing source must be represented as missing rather than fabricated, and a failed diagnostic tool must not be confused with an all-clear result. Every proposed action should carry an explanation and a source reference that an authorized engineer can inspect.

Start with a fixed sequence: validate the request, read incident facts, retrieve relevant policy, summarize evidence and propose a next step. A bounded Claude agent earns its place only when real ambiguity requires adaptive tool selection. Otherwise, the deterministic sequence is easier to test, authorize and recover.

Represent the agent loop as explicit application state

Define states such as INTAKE, RETRIEVE, ANALYZE, AWAIT_TOOL, REVIEW_REQUIRED, COMPLETE and FAILED_SAFE. Keep the incident ID, authorized user, remaining tool budget, pending calls and last verified source version in durable application state. A transcript can provide context, but it is not the sole record of whether an operation has completed or what the user can access.

while state.is_active():
    assert user_is_authorized(state.user, state.incident)
    if state.steps >= step_budget:
        state = FAILED_SAFE("Investigation limit reached")
        break

    response = ask_claude(relevant_verified_context(state), available_read_tools)
    if response.requests_tools():
        for request in response.tool_requests:
            result = validate_and_run_read_tool(request, state.user)
            append_evidence_or_typed_error(state, result)
    elif response.has_reviewable_answer():
        state = REVIEW_REQUIRED(response.recommendation)
    else:
        state = FAILED_SAFE("Insufficient verified evidence")

The preceding pseudocode omits production details such as deadlines, limited concurrency, error budgets and authorized side-effect handling. In Agent SDK loops, stop reasons show what a model turn requires next; only the application can verify that the real-world task, approval and external mutation actually finished.

Expose narrow MCP tools with meaningful errors

Define one tool at a time, beginning with get_service_health and get_recent_changes. For each, specify valid identifiers, a maximum time range, permitted environments, sanitized output fields and evidence timestamps. The target service must validate those parameters and enforce authorization. A malicious or accidental model request for a protected incident must fail even if it is formatted as a perfectly valid tool call.

Use distinct error states: not_found, not_authorized, temporarily_unavailable, invalid_request and source_stale. Do not collapse them into a blank response. A missing incident number may warrant clarification; a denied read requires stopping; an intermittent monitoring failure may permit a bounded retry; stale documentation requires a refresh before making a claim. The model should receive enough information to explain the situation truthfully without leaking credentials or raw internal stack traces.

MCP standardizes interfaces, not permission. MCP boundaries constrain identity and allowed operations; tool selection and explicit error states then decide how the agent responds when an available capability cannot complete the task. These distinctions also matter when the integration uses a non-MCP API.

Delegate only the work that benefits from specialization

When two independent facts are needed, such as a recent deployment timeline and a service-health trend, a coordinator may request each from a specialist in parallel. The deployment specialist should receive deployment-history read tools; the monitoring specialist should receive bounded telemetry tools. Neither should inherit unrelated secrets, writable infrastructure permissions or every conversation message by default.

Define the specialists’ output contracts before running them. Each returns an observation, a source reference, a checked timestamp, uncertainties and an explicit status. If they disagree—monitoring suggests recovery while deployment history shows a new change—the coordinator must preserve the disagreement and request evidence, not average two summaries into a confident story. Parallelism reduces latency only when the tasks can actually proceed without shared mutable state.

A subagent handoff should preserve source references, timestamps, completed task artifacts and unresolved decisions. When a coordinator restarts, it can verify saved evidence instead of repeating a mutation or granting a specialist authority to commit an irreversible action.

Use Claude Code to make the implementation reviewable

Place the sample application in a small repository with separate files for the tool contracts, policy checks, context adapter and tests. Team instructions should state where evidence fixtures live, which test command to run, which services may be contacted in development and which deployment commands are forbidden to the assistant. Keep secrets out of instructions and test fixtures. A local hook can provide early feedback, but shared CI and repository permissions must enforce the organization’s actual policies.

Before asking Claude Code to implement a tool, require a plan identifying affected modules, authorization tests, failure cases and rollback steps. Claude Code settings should constrain repository permissions, while planning and CI controls prevent unreviewed changes from reaching deployment. Reusable skills should be scoped to actual repeatable tasks and maintained as code changes.

Add a test that deliberately gives the assistant an untrusted runbook line instructing it to skip authorization. The service policy must still reject the disallowed call. A passing unit test where the model happened to ignore the text is not adequate proof: run repeated trials and preserve target-service checks so the architecture does not rely on probabilistic obedience.

Use structured records to separate observations from conclusions

A final incident record might contain the incident identifier, the set of verified observations, source references, conflicting facts, proposed next diagnostic step and review status. Do not force a single conclusion when one source is stale or two monitoring records disagree. Schemas protect the interface shape; they do not guarantee that a field is true or permitted to be used.

Structured outputs enforce interface shape, but a valid schema can still contain false facts. Build evaluation cases with missing, conflicting and adversarial evidence. Few-shot examples, batches and multi-pass review help reveal failure modes; final business actions still require independent verification and policy checks.

Recover state and compare deployment choices deliberately

Persist only what the next authorized step requires: case state, the exact source identifiers, review decisions, task results and operation timestamps. Context compaction may summarize earlier conversation, but should not erase evidence provenance or an unresolved approval. Simulate a restart between a diagnostic tool call and a human review. The recovered system should either recognize the existing result or re-run only a safe read under current permissions; it should not infer success from an old assistant message.

Every retrieved source needs an identifier, timestamp and freshness check. A changed policy or deployment state can invalidate an earlier recommendation even after compaction. Reliable context management preserves original evidence and pending approvals across summaries and session restarts.

Direct Claude API access, Amazon Bedrock, Claude Platform on AWS and Vertex AI have different identity, region, contractual and data-processing boundaries. Selecting among Claude deployment models requires evaluating those constraints against the workload rather than assuming model compatibility makes providers interchangeable.

Finish with an evidence-led architecture review

Make the final review practical. Can an engineer see which source justified every important claim? Can a malicious tool result change the assistant’s permissions? Can the application stop after a bounded number of steps? Does a delegated specialist have fewer permissions than its coordinator? What happens after a timeout or session restart? Can an auditor distinguish what the model proposed from what the production system actually did? The right answers should be demonstrated by tests, not inferred from a polished diagram.

Record each requirement, alternative, authority boundary, tradeoff and verification result in a decision log. A simple design with enforceable constraints often beats an elaborate agent network. A design review should reject any operation whose evidence source, permission boundary or expected failure behavior cannot be identified. The decision log makes those omissions visible before a system is allowed to perform consequential work.

This lab is complete when another engineer can inspect its contracts, run its negative tests, trace every important source, recover an interrupted case and explain which person or service can authorize actions. Those outcomes are valuable independent of an exam: they are the attributes of a Claude application that an organization can operate and trust.