The Claude Certified Architect certifications cover two sets of content, Foundations and Professional, and the easiest way to tell them apart is to follow one small idea as it becomes a real service. Foundations asks whether you can make the parts work properly. Professional asks whether those parts belong in this organisation, and what it will take to keep the whole thing useful after launch. They are different views of the same work, rather than two unrelated subjects. Let's use a fictional workplace called Harbour Resolution, where a team handles customer complaints. Maya, an equally fictional case officer, spends a lot of her day opening messages, finding the relevant policy and drafting replies.

Someone suggests bringing in Claude to help. That sounds straightforward until you watch what Maya actually does. She distinguishes a duplicate charge from two legitimate purchases, notices when a policy has changed, and knows when she needs a manager's decision. She also knows that writing a convincing explanation and being allowed to issue a refund are very different things. The Foundations content starts close to that machinery. Here, the model is Claude's system for generating a response from the instructions and information it receives. An agent puts that model inside a software loop where it can choose a next step, request information or an action, and use the result to continue.

It isn't a new employee with its own authority. For Maya's assistant, that loop might begin with reading the complaint, move to looking up the transactions and finish with a proposed reply. The surrounding application has to keep track of which requests succeeded, what information came back and whether the task should stop. Suppose the transaction lookup fails, but Claude still produces a smooth explanation. A well-designed application treats retrieved facts as evidence and a conclusion drawn from those facts as an inference; if the lookup failed, it preserves that missing evidence instead of treating smooth prose as proof that the investigation is complete. Foundations is interested in those small but consequential decisions: continue, retry, stop or ask a person for help.

Retrying means attempting an operation again after a failure, with a limit so the assistant cannot get stuck repeating itself. Tool design is the next part of the picture. A tool is a capability the application makes available to the model, such as looking up a transaction or proposing a case update. Those capabilities should have clear descriptions and limits. Each tool should accept a defined set of input fields and return a defined set of output fields, so the surrounding application knows what a valid exchange looks like. For example, a refund proposal tool might require a case identifier, an amount and a reason, then return a proposal identifier and its approval status.

If a request is missing a required field, uses the wrong kind of value or produces an unexpected result, ordinary software should reject it or route it for review rather than letting the workflow continue. The description guides the model toward using the tool correctly, while input and output checks enforce the tool's contract. Think of the difference between giving someone a form for requesting a refund and giving them unrestricted access to the payment system. Both can support the same business process, but they hand over very different amounts of control. MCP, which stands for Model Context Protocol, gives compatible applications a consistent way to discover tools and information sources and learn what inputs they require.

For Maya's assistant, that could mean discovering the transaction lookup and learning which case details it needs. The service behind the tool still has to check permission; a common interface does not make every caller entitled to everything behind it. That distinction runs through the entire series: instructions guide the model, while controls in ordinary software enforce the boundary. Foundations also looks at Claude Code, the Claude environment used to help with software work. The team building Maya's assistant needs a repeatable way to explain its codebase, meaning the project's source code and configuration, reuse common workflows and check proposed changes. A reusable skill packages instructions and supporting material for a recurring task, rather than making each developer explain the whole procedure again.

But a note that says to run the tests is not evidence that the tests passed. The actual test results, and the rule that prevents an unchecked change being released, live outside that note. Prompt design and structured output cover another practical problem: making a model's response usable. A prompt tells the model what to do and supplies the context and constraints needed for that task. Maya's team could give it a made-up complaint, such as being charged twice, alongside an example that labels the issue as a possible duplicate charge and drafts a reply rather than promising a refund. That example demonstrates the kind of answer the team wants, but it does not make the answer correct or replace the application's permission checks.

Structured output gives the answer a predictable shape, such as named fields for a complaint type and a proposed next step. It's rather like agreeing on a form before asking people to submit information. The form makes responses easier to process, but someone can still put the wrong information in the right box. Maya's assistant might produce a beautifully formatted reply based on the wrong transaction, so checking the shape and checking the meaning are separate jobs. The remaining Foundations theme is keeping the right information available and handling uncertainty honestly. Imagine the assistant finds two versions of a policy that seem to give different answers.

It should preserve that conflict, establish which version applies or ask for help, rather than quietly picking whichever version makes the reply easier to finish. Important state, such as which transaction was checked and whether approval is pending, belongs in a durable application record, not just in the conversation. That's the Foundations view: connect the loop, tools, development workflow, prompts and information handling so the assistant behaves coherently. Now step back from Maya's screen. The Professional content asks what happens when the organisation wants this to become a service that people depend on. The first question is whether the proposed system solves the right problem.

Perhaps Maya doesn't need an assistant that can manage a whole case. Perhaps finding the relevant policy and preparing a draft would remove most of the tedious work while keeping the consequential decisions with the case officer. Professional solution design compares a simple model-assisted step, an agent that can choose among several steps and a coordinated system of multiple components, then selects according to how variable the work is and how much harm an error could cause. Autonomy is the freedom a system has to select and carry out steps without a person directing each one. More freedom can help with varied work, but it also makes clear limits, monitoring and required checkpoints where an authorized person must approve before the system acts more important.

Professional design also compares candidate models on representative complaint work instead of assuming that the most capable option is automatically the right one. A team might find that one model handles difficult policy conflicts better but responds more slowly or costs more to operate, while another is adequate for routine drafting with lower delay and cost. The choice should reflect the quality the service needs, the consequences of errors, the acceptable delay and the available budget, with human review or narrower responsibilities where the risk demands them. Deployment means deciding where and under whose control the system runs, while a system boundary defines what is inside the solution and where responsibility, control or trust changes as it connects to external services.

If the transaction service is unavailable, does Maya get a clear explanation and a manual route, or does the entire complaints process grind to a halt? Keeping a service available, recovering after failures and responding quickly all require deliberate choices, and stronger service expectations can mean more complexity and expense. Integration means connecting the assistant to the organisation's existing data and services without losing the rules attached to them. Retrieval means finding the relevant records when they are needed, and the design must also assess source quality and record each handoff so a failure can be traced across the full path. Source quality means checking whether that information is authoritative, current, complete enough and relevant to this case.

Even a perfectly traceable workflow can give Maya a wrong answer if it relies on an obsolete policy. Maya being signed in doesn't mean she is allowed to read every customer's records. The service needs to verify her identity and separately check what that identity may access. Those are authentication and authorization: checking who is requesting access, then checking what they are permitted to do. Evaluation is how the team finds out whether the system is actually helping on representative work, rather than just performing well in a demonstration. Suppose the assistant makes drafting faster but gives Maya more incorrect details to investigate. The team has saved time in one step and created work in another.

Professional evaluation defines success measures for representative cases, separates failures caused by source data, retrieval, model reasoning or connected services used later in the workflow, and weighs answer quality against delay, operating cost, review effort and operational impact. Governance is about who makes decisions, who is accountable and which controls match the possible harm. For a refund recommendation, that includes deciding who may approve it, what evidence they need and what must be recorded. A customer confirming that they want a refund is not the same as an authorized manager approving the payment. At fictional Harbour Resolution, safety, security, privacy and risk describe related but distinct responsibilities.

Safety limits actions that could cause harm, such as preventing the assistant from issuing a refund merely because its draft sounds confident. Security uses controls to reduce and detect unauthorized access or changes, such as attempts to read restricted records or alter approval data. Privacy governs how customer information is collected, used, shared and retained, so information supplied for resolving a complaint is not automatically suitable for every other purpose. Risk considers who could be harmed, how that harm could occur and how serious it could be, helping the organisation choose controls and decide whether the risk that remains after those controls is acceptable. Logs, which are records of system events, can preserve evidence about the information used, the action proposed and the person who approved it.

Detailed logs can make an incident easier to investigate, but retaining more customer information also increases the amount of sensitive data that could be exposed or misused, so the service should keep what it genuinely needs and protect it for an appropriate period. Finally, Professional covers the continuing work of delivery and ownership. Who helps Maya when the assistant gives a confusing answer, who checks a changed policy, and who can disable an unsafe feature? Introducing the system gradually, watching its behaviour and agreeing on support responsibilities are part of the design, not chores to discover after the launch announcement. The people who use, build and oversee the service need to agree on its goals, the compromises they will accept and who owns each decision.

Change management means reviewing updates, introducing them carefully and watching what happens afterwards, rather than treating every new prompt as a harmless wording change. Developer enablement is the practical support that helps builders do this consistently: clear guidance, repeatable ways of working and someone to turn to when a change goes wrong. So Foundations stays close to building and connecting the components well, while Professional widens the view to choosing, operating and improving the whole solution responsibly. Understanding the machinery first makes it easier to judge how the complete service should deliver value, manage risk and improve over time.