← Domain 2: Applications and Integration

2.5 · 8.6% of the exam · Topic 5 of 6

Claude Application Design

Claude Code, Desktop, claude.ai, the API, and the SDKs do not interpret a product the same way. The application draws a boundary between instructions and untrusted content, declares the schema it will parse, keeps sessions from going stale, and treats plugins as dependencies.

Learning objectives

Pick a surface from where the user works and from what the application must control.
Keep untrusted document and user text out of the instruction channel.
Design the schema as the contract the application parses, not as a hope about prose.
Discard or replace a session whose tool results no longer match the files or the account.
Manage plugins as shared, versioned dependencies rather than one person's local install.

Detailed theory

The surface is part of the design

Claude application design is 8.6% of the exam, the largest skill in this domain. The published scope is how Claude interprets instructions on Claude Code, Desktop, claude.ai, the API, and the SDKs, plus content boundaries, schema design, session hygiene, and plugin management.

Claude Code is a repository agent with tools, files, and project configuration. Desktop and claude.ai are products with their own tools and memory. The API and SDKs are libraries inside an application you own: you send messages, you run tools, you store history. An instruction that lives only in a Code CLAUDE.md does not exist on a raw Messages call. A schema you enforce in your service does not enforce itself in a chat window.

Content boundaries and schemas

Public notes for this exam treat retrieved and user-supplied text as untrusted data. It stays separate from the instructions that tell the model what to do. A document pasted into the system prompt is in the instruction channel. A document placed in a user turn, labeled as source material, is data the instructions can talk about.

Schema design is the contract between the model and the code that consumes the result. The application declares the fields it will parse and rejects a body that does not match. Prose that "usually looks like JSON" is not a contract. The schema belongs with the caller, in version control, which is the foundation in 2.4.

Session hygiene and plugins

A session is the history you choose to send again. Tool results inside it can name files, orders, or policies that have since changed. This repository's session teaching is that resuming after the world has changed makes the model reason from old tool output. Asking it to re-read does not remove those stale results from the history. The hygiene move is a new session plus a short summary of what is still true.

Plugins add tools and instructions to a Claude product surface. They are dependencies. A design that works only because one developer installed a plugin will fail for everyone else. Record the plugin and the version the application expects, the same way you record a library. Configuration in 2.6 is where shared project files carry team dependencies and personal files stay personal.

Core concepts

Surface

What: Claude Code, Desktop, claude.ai, or the API and SDKs.
Why: Each one loads different tools and different configuration.
When: The user already lives in that product, or you must own the loop.
When not: You assume a CLAUDE.md rule applies to an API service.

Content boundary

What: Instructions in one place, untrusted text in another.
Why: Text in the instruction channel is treated as instructions.
When: The input is a user, a document, a web page, or a tool result you did not author.
When not: The text is a policy your team wrote and you intend as an instruction.

Schema

What: The shape the application parses and rejects on mismatch.
Why: Downstream code needs fields, not a paragraph that happens to contain them.
When: A later step reads an amount, an id, or a list.
When not: The user only wanted prose and nothing in your system branches on it.

Session hygiene

What: The history you resend still matches the world.
Why: The API will treat stale tool results as facts.
When: Files, records, or policy changed after the tool ran.
When not: The same task is continuing and the tool results are still the ones you would fetch now.

Plugin

What: An installable extension of a Claude surface, versioned like a dependency.
Why: Behavior that depends on an undeclared plugin is not reproducible.
When: The surface is Code or Desktop and the capability comes from a plugin.
When not: You are on the raw API. There, the equivalent is a tool you implemented and shipped in your service.

Practical examples

A policy pasted into the system prompt

A support bot puts the customer's pasted email into the system prompt so the model "sees it first." The email says to ignore the refund rules. It is now in the instruction channel. The design move is to keep the refund rules in the system prompt and pass the email as labeled user content.

A session that cites a deleted file

Yesterday's tool result says the bug is in parser.ts. The file was renamed this morning. Resuming the session and asking for a fix produces advice about a path that is gone. A new session with a summary that names the new path does not keep the old tool result in the history.

Claude-specific considerations

On the API you choose the boundary by which field you use. System is for instructions you wrote. The user message carries the untrusted payload.
SDKs do not add a server-side session. Hygiene is which array you send on the next call.
Claude Code loads project instructions from the repository. That does not configure an API application deployed elsewhere.
A plugin required for a team workflow belongs in the shared project setup. A plugin only one person uses stays on that machine and is not part of the team's design.

Architecture decisions

SituationChooseBecause

You must own tools, storage, and the request.The API or an SDK.The product surfaces own those for you, and you cannot swap them out.

The work is inside a repository the developer already has open.Claude Code, with project configuration.That surface already has the files and the project instructions.

A customer document must be read but not obeyed.User content, with instructions kept separate.The document is data.

The next service needs a numeric amount.A schema the client parses.Prose is not a field.

Tool results in the history describe files that changed.A new session and a summary of what is still true.Re-reading does not delete the old tool result.

The workflow needs a plugin the whole team must have.A declared, versioned project dependency.A personal install does not travel with the design.

Tradeoffs

A product surface gives you tools and a window quickly, and you do not own the loop. The API gives you the loop and makes you build storage, schema checks, and session handling. The left column is a product surface. The right column is your service.

AxisProduct surfaceAPI application

ControlThe product runs tools and stores the chat.You run tools and store messages.

InstructionsProject files such as CLAUDE.md, where that surface loads them.The system field on the request you send.

SchemaYou get prose unless the product offers a structured mode.You declare the schema and you reject a mismatch.

PluginsInstalls on that product, shared only if the project says so.Tools you ship in the service. A Code plugin is not on this path.

Quick reference

Code, Desktop, claude.ai, and the API do not share instructions or tools automatically.
Untrusted text stays out of the system prompt.
A schema is the shape your code parses. Prose is not a schema.
Stale tool results stay in a resumed session. Start a new one with a summary.
A team plugin is a declared dependency. A personal plugin is not the design.
Owning the loop means the API or an SDK, and it means you store history.

Decision rules for the exam

If the question says…The answer is likely…

"the email says to ignore the rules"Keep it out of the instruction channel

"the next step needs a field"A schema the client checks

"the file moved since the last tool result"New session, plus a summary

"it works on my Claude Code install"The plugin or the CLAUDE.md may be local

"port this chat prompt to the API"Re-home instructions, tools, and history. It is not a copy

Common exam traps

TrapCorrect answer

Putting a customer document in the system prompt so it is seen first.That makes it an instruction. Pass it as user content.

Resuming after the files change and asking for a re-read.The old tool result is still in the history.

Assuming a Code plugin exists on the API.On the API the tool is code you ship.

Open the Domain 2 sheet

Exam tips

No practice questions for this skill are stored in the repository. The architect tool-design bank is a different domain.
A question about where an instruction is loaded is a surface question. CLAUDE.md does not configure a raw API call.
A question about a stale transcript is session hygiene, not a larger context window as the first move.

Common mistakes

One prompt file hoped to drive every surface.
Name the surface, then name which channel it reads.
Branching production code on a paragraph.
Parse a schema and fail closed.
Calling a plugin "installed" because one laptop has it.
Declare it where the rest of the team gets it, and pin the version.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

Scenario questions

Build exercise

Draw one feature on two surfaces

Intermediate · 40 minutes

What you will learn

What changes between Claude Code and the API.
Where untrusted text goes.
What the schema must contain.
When a session is thrown away.

Step 1
Pick a feature that reads a customer document and writes a structured result
Describe it in one paragraph with one side effect, such as creating a ticket.
Why: The boundary and the schema both show up.
You should see: The outcome, the untrusted input, and the side effect.
Step 2
Place it on Claude Code and on the API
For each surface, write where instructions live, who executes tools, and who stores history.
Why: The design is not portable until those three are answered.
You should see: Two short columns that do not say "the same prompt."
Step 3
Write the schema and the boundary
List the fields the ticket step needs. State that the document is user content.
Why: Those are the two design artifacts the next engineer needs.
You should see: A field list and a sentence that names the instruction channel and the data channel.
Step 4
Define a stale session
Name one fact a tool result might hold that can go stale, and write the replacement: new session plus the facts you keep.
Why: Hygiene is a design decision, not a longer window.
You should see: The stale fact, and the summary fields that survive.

Review checklist

Checks are saved in this browser.

I can name what Code, Desktop, claude.ai, and the API each own.
I keep untrusted text out of the system prompt.
I can point at the schema the client parses.
I replace a session when tool results are stale.
I treat a required plugin as a versioned dependency.

Key takeaways

The surface decides who stores history and who runs tools.
Instructions and untrusted content stay apart.
Schemas are contracts. Sessions must still match the world.
Plugins the team needs are declared. Personal installs are not the design.

Sources

CCDV-F exam guide, Domain 2 skill weights — Public blueprint summary: surfaces, content boundaries, schema design, session hygiene, plugin management.

Domain 2 overview · Quick reference

View progress