This public, non-exam architecture walkthrough applies the series’ design practices to a fictional municipal permit-information assistant. It helps residents understand published permit guidance and prepare a request for staff review; it does not approve permits, change records, or give legal advice. The aim is to show traceable production choices, not to simulate an assessment or claim official coverage.

The design spine is a bounded Claude API workflow with deterministic orchestration, rather than an autonomous Claude Agent SDK loop: scoped read-only tools or MCP retrieval stay separate from an authenticated staff action path; prompt and schema contracts lead to semantic and authorization checks; context is reduced while durable provenance is retained; and evaluations, fallback, escalation, and human approval close the operating loop.

The Production Scenario and Requirements

The city has a public website with current permit guides, fee schedules, and contact details. Residents ask conversational questions that can be ambiguous or depend on their address, project type, or local rules. Staff need a draft intake summary with source links, but only authorized staff may create a case in the city’s case-management system.

The architecture therefore needs grounded public answers, clear uncertainty handling, language-access support, an auditable staff handoff, and a strict separation between information and case creation. These requirements are architectural assumptions for this scenario. The accountable city team would still need to define privacy, retention, accessibility, and legal-review requirements before implementation.

Architecture Choice: A Bounded Assistant with Controlled Tools

Use a Claude API application for the resident-facing interaction and a small orchestration service for authentication, retrieval, output validation, logging, and handoff. Give the resident flow read-only tools for a curated public-guidance index and a contact-directory lookup. Do not expose a case-creation tool in that flow.

For staff, use a separate authenticated flow that can prepare a structured intake proposal. A deterministic service validates required fields, source references, and staff authorization before a case-management action is available. This division is an architectural recommendation: a prompt should never be the only barrier separating a public chat from a privileged record change.

Claude tool use is designed around structured tool calls that an application or Anthropic service executes. The application retains responsibility for deciding which tools are available and for handling their results.

Tool and Model Context Protocol Design

The public-guidance retrieval capability can be implemented as a narrowly scoped local tool or as a Model Context Protocol (MCP) server. MCP has host, client, and server roles; the protocol architecture keeps full conversation history with the host and describes isolated, focused server capabilities.

For this scenario, an MCP server exposes only search_guidance and get_guidance_document operations over approved public content. Each result carries a document identifier, publication date, URL, and excerpt. The host supplies the minimum input needed for the operation, validates server responses, and does not allow one server to read another server’s conversation state. These are deliberate least-privilege choices aligned with the protocol architecture, not claims that MCP automatically secures a deployment.

The case-management connector stays outside that server or uses a separately authenticated server with a different client and explicit staff authorization. Its interface accepts a typed proposal, not arbitrary natural-language instructions. This makes the privilege boundary visible in code, configuration, and audit records.

Claude Code and Delivery Workflow

Use Claude Code as a development workflow aid, not as a production runtime control. A repository can contain documented project instructions, tests, interface schemas, threat-model notes, and CI checks. Claude Code supports extensibility through skills, hooks, and MCP servers; verify current feature behavior and permission settings before relying on an extension in a delivery pipeline.

A recommended delivery sequence is: a developer proposes a change; Claude Code helps inspect the repository and draft a plan; deterministic CI validates the schemas, tests, and policy checks; and a protected deployment identity performs release steps. Human owners review changes to tools, access scopes, prompts, and evaluations. This sequence is a governance recommendation, not an assertion that any Claude Code workflow independently approves or deploys software.

Prompts and Output Contracts

The resident prompt identifies the assistant as an information guide, provides the retrieved documents as attributed data, requires it to cite available source links, and instructs it to say when published guidance is insufficient. XML-style structure can separate policy, retrieved evidence, and user input; Anthropic documents XML tags and examples as techniques for clarifying complex prompts.

The staff intake stage is separate. It emits a JSON Schema-constrained proposal with the stated project details, missing fields, source identifiers, and a recommended routing label. Anthropic documents structured outputs for schema-constrained, parseable responses and strict tool use for constrained tool inputs, subject to model and platform availability.

The orchestration service then performs semantic checks: source identifiers must resolve to current public guidance, the routing label must be allowed, sensitive fields must meet policy, and a staff member must explicitly approve any case creation. Schema validity is not proof that a proposed summary is accurate or that a privileged action is authorized.

Context and State Lifecycle

In this fictional scenario, the proposed service keeps a short conversation state for the active resident session and retrieves only the documents relevant to the current issue. As an application-designed provenance and retention choice, it stores durable staff handoff data in an application-controlled record, including source versions and the validation outcome, rather than depending on an ever-growing chat history.

Tool results, definitions, and conversation history consume the context window. Anthropic documents context management options including server-side compaction, context editing, and tool-context controls; feature and model support must be checked before use.

The proposed budget keeps policy and current evidence available, summarizes completed low-risk turns with their source identifiers, and retains privileged-action records outside model context. That is a context-lifecycle recommendation; it does not replace an evaluation, audit, or retention policy.

Evaluation and Operations

The team defines separate success criteria for grounded answers, correct source citation, safe refusal of case creation, routing-label validity, accessibility of the response, latency, and staff-review usefulness. Anthropic’s evaluation guidance recommends defining measurable criteria and building evaluations with deterministic or model-based graders as appropriate.

For this fictional system, the proposed regression suite includes ordinary guidance questions, missing-address cases, stale-document simulations, conflicting user instructions, a failed retrieval, and a request to create a case without staff authorization. These are original engineering tests, not exam questions. As a recommended operational telemetry design, the service records prompt and tool configuration versions, source document versions, validation outcomes, latency, and non-sensitive failure categories.

For a retrieval outage, the assistant returns a transparent unavailable-state response and routes the resident to official contact channels rather than inventing requirements. For an ambiguous or high-impact case, it prepares an evidence-backed handoff for staff. Human review remains before record creation and whenever policy or evidence is insufficient. These fallback and escalation policies are recommended operating choices.

Common Architecture Mistakes

Avoid putting both public retrieval and privileged record changes behind one unrestricted tool. Avoid allowing a prompt to stand in for authorization. Avoid treating a fluent, schema-valid summary as a verified permit determination. Finally, avoid keeping every tool result in the conversation when a stable source reference and a durable handoff record are what the next stage needs.

The better design makes each boundary inspectable: what the assistant can read, what it can propose, what code validates, what a person must approve, and what evidence is retained. That clarity is more valuable than an impressive-looking autonomous flow.

Conclusion

Explicit boundaries can support reliable Claude-system outcomes, but they do not make an architecture reliable by themselves. The fictional permit assistant illustrates how read-only public guidance, scoped tool interfaces, separate staff authorization, schema plus semantic validation, disciplined context control, measured operations, and ongoing evaluation can work together without granting the model unbounded authority or treating the system as an exam exercise.

Authoritative Sources