Claude Certified Architect – Foundations: A Detailed Guide to the Core Knowledge Areas

Artificial intelligence architecture is moving beyond simple chatbot development. Modern enterprise AI systems must connect to business applications, retrieve organisational knowledge, call external tools, follow security policies, manage long-running tasks and produce outputs that other software systems can reliably process.

The Claude Certified Architect – Foundations, commonly known as CCA-F, focuses on the architectural knowledge needed to design these systems using Anthropic’s Claude platform.

The certification is not simply about learning how to write prompts. It evaluates whether a practitioner can make appropriate technical decisions when designing production-ready Claude applications. This includes deciding whether a problem requires a direct model call, a structured workflow, a tool-using agent or a multi-agent architecture.

The certification content can be understood through five major areas:

1. Agentic architecture and orchestration
2. Tool design and Model Context Protocol integration
3. Claude Code configuration and development workflows
4. Prompt engineering and structured outputs
5. Context management and system reliability

Together, these areas provide a foundation for building secure, scalable and commercially viable AI solutions with Claude.

1. Agentic Architecture and Orchestration​

Agentic architecture is one of the most important areas of the Claude Certified Architect curriculum.

An AI agent is a system in which a language model is given a goal and is allowed to decide how to complete it. Instead of following a completely fixed sequence of steps, the model can plan actions, choose tools, review results and adjust its approach.

However, not every AI application needs an agent.

One of the most important skills for a Claude architect is knowing when to use a simple architecture and when greater autonomy is justified.

Direct model calls​

The simplest Claude architecture involves sending a prompt to the model and receiving a response.

Examples include:

• Summarising a document
• Classifying a support ticket
• Extracting information from text
• Rewriting an email
• Generating a report
• Producing structured information from an unstructured document

A direct model call is usually appropriate when the task can be completed using the information already provided in the prompt.

There is no need to introduce an agent if Claude does not need to interact with external systems or make multiple decisions.

Prompt chains​

A prompt chain divides a larger task into a sequence of smaller model calls.

For example, a document-analysis workflow might:

1. Extract key information from a document.
2. Classify the document.
3. Identify possible risks.
4. Produce a final report.

Each step receives the output of the previous step.

Prompt chains can provide greater control than a single large prompt. They also make it easier to test and debug individual stages.

However, prompt chains can increase latency and token usage. They should therefore be used when breaking the task into stages produces a meaningful improvement in quality or reliability.

Deterministic workflows​

A deterministic workflow is controlled primarily by application code.

The application decides:

• Which step happens first
• Which tool is called
• Which model receives the request
• What conditions determine the next step
• When human approval is needed
• When the process should stop

Claude may perform individual reasoning or generation tasks, but the overall workflow remains controlled by the software.

For example, an insurance-claim workflow may:

1. Validate the customer’s policy number using application code.
2. Retrieve the relevant policy documents.
3. Ask Claude to classify the claim.
4. Check the classification against business rules.
5. Escalate high-risk claims to a human reviewer.
6. Generate a customer response.

This architecture is often safer than giving an AI agent full control over the claims process.

Routing​

Routing involves sending a request to different prompts, models, tools or workflows depending on the type of task.

For example, a customer-service application may route:

• Billing questions to a billing workflow
• Technical problems to a troubleshooting workflow
• Refund requests to a controlled approval process
• General questions to a knowledge-retrieval system
• Sensitive complaints to a human agent

Routing can be performed using:

• Application rules
• Keyword matching
• A smaller classification model
• Claude itself
• A combination of deterministic and model-based logic

Good routing improves accuracy, reduces cost and prevents sensitive requests from being handled by inappropriate workflows.

Parallel processing​

Some tasks can be divided into independent subtasks that run at the same time.

For example, when analysing a company, separate workers could simultaneously examine:

• Financial performance
• Market position
• Competitors
• Regulatory risks
• Technology capabilities
• Customer sentiment

The outputs can then be combined into a final report.

Parallel execution reduces overall processing time and allows specialised prompts or agents to focus on different dimensions of a problem.

However, it can also increase token usage and operational complexity.

Evaluator–optimizer workflows​

An evaluator–optimizer workflow uses one model call to generate an output and another to evaluate or improve it.

For example:

1. Claude generates a proposal.
2. A second Claude call evaluates the proposal against a rubric.
3. The system identifies missing evidence or unclear sections.
4. Claude revises the proposal.
5. The process stops when the required quality level is reached.

This pattern can improve output quality when success criteria are clearly defined.

However, architects must set limits. Without a stopping condition, the workflow may continue unnecessarily and increase cost.

Possible stopping conditions include:

• Maximum number of revisions
• Minimum evaluation score
• Maximum token budget
• Maximum execution time
• Human approval

Single-agent architectures​

A single-agent architecture gives one Claude instance responsibility for planning and completing a task.

The agent may:

• Interpret the objective
• Select tools
• Retrieve information
• Analyse results
• Correct errors
• Produce the final response

A single agent is often easier to build, monitor and evaluate than a multi-agent system.

It may be appropriate when:

• One agent can access all required tools
• The task is not easily divided
• The context can fit within the model’s working window
• Coordination between specialists would add unnecessary complexity

Multi-agent architectures​

A multi-agent system uses several agents with different responsibilities.

For example, a commercial proposal system could include:

• A research agent
• A pricing agent
• A technical architecture agent
• A risk and compliance agent
• A coordinating agent

The coordinating agent delegates tasks, receives outputs and produces the final result.

Multi-agent systems can be valuable when the task contains clearly separable areas of expertise.

However, they introduce several challenges:

• Higher cost
• Longer execution time
• Coordination failures
• Duplicate work
• Conflicting conclusions
• More complex debugging
• Larger context requirements
• Increased security exposure

An architect should not select a multi-agent design simply because it appears more advanced. The architecture must provide measurable benefits over a simpler alternative.

Human-in-the-loop controls​

Human oversight is essential when agents can perform consequential actions.

Human approval may be required before the system:

• Sends an external communication
• Deletes information
• Modifies a production system
• Approves a financial transaction
• Changes a customer account
• Publishes content
• Makes an employment decision
• Accesses highly sensitive information

A well-designed system should clearly define which actions Claude may perform independently and which actions require review.

2. Tool Design and Model Context Protocol Integration​

Claude becomes more useful when it can interact with external systems.

A tool gives Claude access to a specific capability, such as:

• Searching a database
• Retrieving an order
• Looking up a customer record
• Creating a support ticket
• Running a calculation
• Querying an internal knowledge base
• Updating a project-management system
• Executing approved code

The quality of the agent depends heavily on the quality of its tools.

How tool use works​

A typical tool-use process follows these steps:

1. The user asks Claude to complete a task.
2. Claude determines that external information or an action is required.
3. Claude selects an appropriate tool.
4. Claude produces structured tool parameters.
5. The application validates the request.
6. The application executes the tool.
7. The tool result is returned to Claude.
8. Claude interprets the result and continues the task.

Claude does not automatically receive unrestricted access to external systems. The application controls which tools are available and how they are executed.

Designing effective tools​

A well-designed tool should have a narrow and clearly defined purpose.

For example, a tool called:

manage_customer

is too broad because it does not clearly explain what actions it can perform.

More specific tools would be:

• get_customer_profile
• update_customer_address
• create_support_case
• close_customer_account

Specific tools improve clarity and make permission control easier.

A strong tool definition should include:

• A clear name
• A precise description
• A well-defined input schema
• Required and optional parameters
• Expected data types
• Validation rules
• A predictable output structure
• Clear error messages

The tool description should explain not only what the tool does, but also when Claude should use it.

Read tools and write tools​

Tools can be divided into two broad categories.

Read tools retrieve information without changing the external system.

Examples include:

• Searching documents
• Retrieving customer details
• Checking order status
• Reading system logs

Write tools modify external state.

Examples include:

• Updating a database
• Sending an email
• Cancelling an order
• Creating a payment
• Deleting a record

Write tools usually require stronger security controls because their actions may be difficult or impossible to reverse.

Tool permissions​

Claude should receive only the minimum access needed to complete the task.

This is known as the principle of least privilege.

For example, a customer-support agent that only needs to check delivery status should not receive permission to cancel orders or issue refunds.

Permissions may be controlled through:

• Tool availability
• User roles
• Application policies
• Authentication tokens
• Approval workflows
• Environment restrictions
• Read-only credentials
• Transaction limits

Error handling​

Tools can fail for many reasons:

• Invalid input
• Missing data
• Authentication failure
• Network timeout
• Rate limits
• Service outage
• Permission denial
• Unexpected response format

A production system should provide useful error information to Claude without exposing sensitive internal details.

The system should also decide whether Claude should:

• Retry the tool
• Change the parameters
• Use an alternative tool
• Ask the user for more information
• Escalate to a human
• Stop the process

Retries should be limited to prevent infinite loops.

Model Context Protocol​

The Model Context Protocol, commonly known as MCP, provides a standard way for AI applications to connect with tools, data sources and external services.

Without a standard protocol, every integration may require a custom implementation. MCP creates a shared structure that allows compatible AI clients to discover and use external capabilities more consistently.

MCP servers and clients​

An MCP server exposes capabilities.

These capabilities may include:

• Tools
• Resources
• Prompt templates

An MCP client connects to the server and makes those capabilities available to an AI application such as Claude Code or another Claude-based system.

For example, an organisation could create an MCP server that connects to:

• Google Drive
• GitHub
• Jira
• Slack
• A customer database
• An internal document repository
• A cloud-management platform

Claude could then use the permitted capabilities through a standard interface.

MCP tools​

MCP tools allow Claude to perform actions or request computations.

Examples include:

• Creating a Jira issue
• Searching a source-code repository
• Querying a CRM system
• Running a database query
• Retrieving a cloud resource status

MCP resources​

Resources provide information that Claude can read.

Examples include:

• Documentation
• Configuration files
• Database records
• Project files
• System logs
• Knowledge-base articles

MCP prompts​

MCP prompts are reusable prompt templates or workflows exposed by an MCP server.

They can help standardise common organisational tasks, such as:

• Performing a security review
• Creating a project update
• Analysing an incident
• Reviewing a pull request
• Producing a compliance summary

MCP security​

MCP creates powerful integration opportunities, but it also creates security risks.

Architects must consider:

• Who controls the MCP server
• Which tools the server exposes
• How users authenticate
• What data the server can access
• Whether external content can contain malicious instructions
• How tool calls are logged
• Whether write actions require approval
• How tenants are isolated
• How secrets are protected

An MCP server should not be trusted simply because it is technically compatible.

3. Claude Code Configuration and Development Workflows​

Claude Code is Anthropic’s coding environment for working with software repositories and development tasks.

It can inspect files, understand a codebase, suggest modifications, run commands, write code and support larger software-engineering workflows.

The certification content focuses on configuring Claude Code so that it operates reliably within the rules of a project.

Repository instructions​

Claude Code performs better when it receives clear information about the repository.

Useful instructions may include:

• Project architecture
• Folder structure
• Coding conventions
• Supported frameworks
• Testing commands
• Build commands
• Security requirements
• Naming standards
• Deployment procedures
• Files that should not be modified

Without this information, Claude may generate code that is technically valid but inconsistent with the project.

Context management in coding​

Large repositories contain more information than Claude can use at once.

Claude Code must identify which files are relevant to the current task.

Good context management may involve:

• Searching for related classes and functions
• Reading project documentation
• Inspecting tests
• Reviewing configuration files
• Tracing dependencies
• Understanding recent changes
• Avoiding irrelevant files

The architect should provide enough context for Claude to understand the task without overwhelming it with unnecessary information.

Permissions and command execution​

Claude Code may need to run commands such as:

• Installing dependencies
• Running tests
• Formatting code
• Building the application
• Checking types
• Running static analysis
• Executing migration scripts

However, unrestricted command execution creates risks.

Claude should not be allowed to perform destructive or sensitive commands without appropriate controls.

Examples include:

• Deleting large directories
• Modifying production infrastructure
• Publishing packages
• Exposing secrets
• Force-pushing code
• Deploying directly to production

Permissions should reflect the development environment and the risk of the action.

Hooks​

Hooks allow organisations to trigger actions at specific points in a Claude Code workflow.

They can be used to:

• Run tests after code changes
• Apply formatting
• Perform security scanning
• Validate file modifications
• Block prohibited commands
• Record audit information
• Check policy compliance

Hooks help convert organisational rules into enforceable workflow controls.

Reusable commands​

Teams can create reusable commands for frequently performed tasks.

Examples include:

• Review this pull request
• Generate unit tests
• Analyse security risks
• Update the API documentation
• Prepare a release summary
• Investigate a failing test
• Refactor this module

Reusable commands improve consistency and reduce the need to repeatedly write detailed instructions.

Claude Code in CI/CD​

Claude Code can be integrated into automated engineering workflows.

Possible uses include:

• Pull-request review
• Test generation
• Documentation updates
• Code migration
• Dependency analysis
• Security review
• Issue investigation

Automation should include clear limits.

For example, Claude may be permitted to suggest code changes but not merge them automatically.

Enterprise development controls​

Organisations using Claude Code should consider:

• Centralised authentication
• Access management
• Secret handling
• Repository permissions
• Audit logs
• Data-retention requirements
• Network restrictions
• Approved models
• Cost monitoring
• Human review

The goal is to gain productivity benefits without losing control over the software-development lifecycle.

4. Prompt Engineering and Structured Outputs​

Prompt engineering is the process of designing instructions and context that help Claude complete a task accurately.

A production prompt is not simply a question. It is part of the system architecture.

Components of a strong prompt​

A strong prompt may include:

• The role Claude should perform
• The objective of the task
• Relevant background information
• Input data
• Business rules
• Limitations
• Examples
• Expected output format
• Evaluation criteria
• Actions Claude must not perform

The structure should make it easy for Claude to distinguish instructions from source material.

Clear instructions​

Instructions should be specific and measurable.

A vague instruction such as:

“Analyse this contract.”

does not explain what kind of analysis is required.

A better instruction would be:

“Identify clauses relating to termination, payment, data protection and liability. For each clause, provide the section reference, a short summary and the potential business risk.”

The second prompt provides a clear scope and output expectation.

Examples​

Examples help Claude understand the desired format and decision criteria.

They are especially valuable when:

• Categories are difficult to distinguish
• The required writing style is specific
• The output must follow a precise structure
• Business rules contain exceptions
• The task involves subjective judgment

However, examples should represent the real range of expected inputs. Poor examples can teach the wrong behaviour.

System instructions​

System instructions define the overall behaviour of the Claude application.

They may include:

• The purpose of the assistant
• The permitted subject area
• Tone and communication style
• Security restrictions
• Tool-use rules
• Escalation requirements
• Data-handling requirements
• Output standards

System instructions should be clear, consistent and free from unnecessary duplication.

Structured outputs​

Many applications need Claude’s response in a machine-readable format.

For example, a support-ticket classifier may return:

{
  "category": "billing",
  "priority": "high",
  "requires_human_review": true,
  "reason": "The customer reports an unauthorised charge."
}

The application can then use these fields to route the ticket.

Structured outputs are important because natural-language responses can vary in wording and format.

Schema design​

A structured-output schema should define:

• Required fields
• Optional fields
• Allowed values
• Data types
• Nested objects
• Arrays
• Field descriptions
• Validation rules

For example, priority should use defined values such as:

• low
• medium
• high
• critical

Allowing Claude to invent arbitrary priority labels would make downstream processing less reliable.

Validation​

Model outputs should be validated before being used.

Validation can check:

• Whether the output is valid JSON
• Whether all required fields are present
• Whether data types are correct
• Whether values belong to approved categories
• Whether numerical values are within permitted ranges
• Whether prohibited content is present

If validation fails, the application may retry the request, repair the output or escalate the task.

Evaluation​

Prompt quality should be measured using a representative test dataset.

Evaluation should cover:

• Accuracy
• Completeness
• Format compliance
• Hallucination rate
• Safety
• Tool-selection quality
• Cost
• Latency

A prompt should be tested on more than ideal examples.

The test set should include:

• Common cases
• Rare cases
• Ambiguous inputs
• Missing information
• Conflicting instructions
• Long documents
• Invalid data
• Adversarial requests

Prompt engineering should therefore be treated as an iterative engineering process rather than a one-time writing exercise.

5. Context Management and Reliability​

Claude can only reason over the information available within its current context.

Context may include:

• System instructions
• User messages
• Conversation history
• Tool definitions
• Tool results
• Retrieved documents
• Examples
• Intermediate agent outputs

Poor context management can increase cost and reduce quality.

Context-window management​

Long conversations and agent workflows can gradually consume the available context.

Possible strategies include:

• Removing irrelevant history
• Summarising earlier messages
• Storing state outside the model
• Retrieving information only when needed
• Keeping tool results concise
• Separating independent tasks
• Starting new sessions when appropriate

The goal is to preserve the most important information while avoiding unnecessary content.

Retrieval-augmented generation​

Retrieval-augmented generation, or RAG, allows Claude to answer questions using documents retrieved from an external knowledge source.

A RAG pipeline normally includes:

1. Document ingestion
2. Text extraction
3. Chunking
4. Embedding generation
5. Indexing
6. Query processing
7. Retrieval
8. Optional reranking
9. Prompt construction
10. Response generation

Chunking​

Documents are divided into smaller pieces known as chunks.

Chunks should be large enough to preserve meaning but small enough to retrieve precisely.

Poor chunking may separate related information or retrieve large amounts of irrelevant text.

Different document types may require different strategies.

For example:

• Contracts may be chunked by clauses
• Policies may be chunked by sections
• Technical documentation may be chunked by headings
• Meeting transcripts may be chunked by topic or speaker

Semantic and lexical retrieval​

Semantic search retrieves content based on meaning.

Lexical search retrieves content based on exact words or phrases.

Semantic search is useful when the user’s wording differs from the source document.

Lexical search is useful for:

• Product codes
• Legal terms
• Error messages
• Names
• Exact technical phrases

Hybrid search combines both approaches.

Reranking​

Initial retrieval may return several potentially relevant chunks.

A reranking stage evaluates those results and places the most useful evidence first.

Reranking can improve answer quality by reducing irrelevant context.

Grounding​

A grounded Claude response should be based on the retrieved source material.

The system may require Claude to:

• Use only the supplied sources
• State when information is unavailable
• Cite relevant document sections
• Avoid unsupported assumptions
• Distinguish evidence from interpretation

Grounding reduces hallucination risk but does not eliminate it. The application must still evaluate output quality.

Production Reliability​

A successful demonstration is not the same as a reliable production system.

Production reliability requires the system to handle failures, unusual inputs and changing conditions.

Timeouts​

External tools and services may not respond.

The application should define how long it will wait before stopping or using an alternative path.

Retry policies​

Temporary failures may justify retries.

However, retries should use limits and delays.

Unlimited retries can create:

• High costs
• Duplicate actions
• Service overload
• Infinite agent loops

Idempotency​

An idempotent operation can be repeated without creating unintended duplicate effects.

For example, a payment operation should not charge the customer twice because an agent retried the request.

Rate limits​

Applications should handle limits imposed by APIs and external systems.

Possible responses include:

• Waiting before retrying
• Reducing request volume
• Queueing tasks
• Using a fallback service
• Informing the user

Fallbacks​

A system may need alternative behaviour when the preferred model, tool or data source is unavailable.

Fallback options may include:

• A different model
• A cached response
• A simplified workflow
• Human escalation
• Temporary read-only functionality

Fallbacks should not silently reduce safety or quality.

Observability​

Observability helps teams understand what the AI system is doing.

Useful information may include:

• Model requests
• Token usage
• Latency
• Tool calls
• Tool errors
• Agent steps
• Evaluation results
• Human approvals
• Final outcomes
• User feedback

Sensitive information should be protected when logging interactions.

Cost management​

AI architecture should consider the total cost of the complete workflow.

Costs may come from:

• Input tokens
• Output tokens
• Repeated model calls
• Large prompts
• Tool definitions
• Retrieved documents
• Multi-agent execution
• Evaluation calls
• External APIs
• Storage and observability

Cost can be reduced by:

• Choosing an appropriate model
• Reducing unnecessary context
• Using caching
• Limiting agent steps
• Running tasks in parallel where useful
• Using deterministic code for simple operations
• Avoiding repeated retrieval
• Setting token and execution budgets

Responsible deployment​

Responsible Claude architecture should include controls for:

• Privacy
• Security
• Fairness
• Transparency
• Human oversight
• User control
• Data retention
• Regulatory compliance
• Harm prevention
• Auditability

Responsible deployment is not a final review performed after the system has been built. It should influence the architecture from the beginning.

Bringing the Domains Together​

The strongest Claude architectures combine all five knowledge areas.

Consider an enterprise customer-support system.

The architecture may use:

• A router to classify customer requests
• RAG to retrieve policy information
• Tools to check account and order details
• An agent for complex troubleshooting
• Deterministic workflows for refunds
• Structured outputs for ticket routing
• Human approval for financial actions
• MCP to connect Claude to enterprise systems
• Evaluation datasets to measure performance
• Observability to track cost, errors and outcomes

Each component solves a specific problem.

The system does not use agents everywhere. It uses autonomy only where the task requires flexible decision-making.

Sensitive actions remain controlled by application rules and human approval.

This is the central architectural mindset behind Claude Certified Architect – Foundations: select the simplest architecture that can complete the business task while maintaining reliability, security, cost control and human oversight.

Conclusion​

Claude Certified Architect – Foundations covers much more than prompt engineering.

It brings together the technical and architectural knowledge required to build production Claude applications, including:

• Agent and workflow design
• Tool calling
• MCP integrations
• Claude Code configuration
• Structured outputs
• Prompt evaluation
• Retrieval-augmented generation
• Context management
• Reliability engineering
• Security and responsible deployment
• Cost and performance management

The most important lesson is that successful AI architecture is not about maximising autonomy or using the most complex design.

A strong Claude architect understands the business objective, evaluates the risks and selects the simplest solution that can deliver the required outcome.

Sometimes that solution is a single prompt.

Sometimes it is a controlled workflow.

Sometimes it is a tool-using agent.

And occasionally, it may require multiple specialised agents working together.

The architect’s responsibility is to understand the difference and design a system that can move safely from experimentation into production.

Related reading​

• Building Production-Grade AI Agents
• AI Agents roadmap
• Agentic AI Systems
• Prompt & context engineering
• Security & privacy