Skip to lesson

AnthropicClaude Certified Architect – Professional2026-100 Prerequisites

Connect evidence and actions through interfaces

Completed by the knowledge check

Learning objective

Describe tool use, retrieval, and memory as the mechanisms that connect a model to external data and actions.

Core idea

Tools expose operations, retrieval supplies selected evidence, and memory preserves information for later work. They connect generation to external state through interfaces you design; none makes generated text an authoritative database record.

The three mechanisms overlap. A retrieval function can be a tool, and a memory read can retrieve stored notes. Choose according to what the task needs: an observation or action, relevant source material, or continuity across sessions. The distinction determines the responsible storage and execution owner.

How it works

Tools expose operations

For a custom client tool, the Messages request’s tools entry contains name, description, and input_schema. Claude returns a tool_use block containing id, name, and input. Your application executes the operation and sends a tool_result whose tool_use_id matches the requested call’s id, inside a user message.

Claude requests a tool call and your application executes the operationYour application sends a Messages request with tools. Claude returns a tool_use block with id, name and input. Your application executes the operation, then sends a tool_result inside a user message whose tool_use_id matches the call's id. Claude only requests the operation, and the application executes it.ClaudeYour applicationExecutes the operationtool_use_id matches the call's idMessages request with toolstool_use block (id, name, input)tool_result inside a user message

That is a request for execution, not evidence that execution succeeded. Keep authorization and system-of-record writes in the executor; see 1.2.2. Anthropic also provides server tools that execute on its infrastructure, so execution ownership depends on the tool rather than the word “tool.” See 3.1.1 for reviewing capability scope.

Retrieval supplies task evidence

Retrieval-augmented generation (RAG) retrieves relevant external knowledge at runtime and supplies it in context alongside the query. Application code can retrieve before generation, or Claude can request a retrieval function through tool use. In either case, generation only benefits from the material actually returned.

Retrieval is useful for changing information, domain-specific evidence, and source citations. Its effectiveness depends on the knowledge base and retrieved material’s quality and relevance. See 3.5.1 for choosing retrieval versus long context or live queries, and 3.5.5 for evaluating retrieval separately from generation. A search result is evidence to assess, not a permission grant or a guaranteed correct answer.

Memory preserves continuity

Durable memory stores information outside the context window and loads relevant information for later work. The Messages API memory tool is available on all Claude 4 and later models; add {"type": "memory_20250818", "name": "memory"} to tools. Claude requests file operations under /memories; your client-side handler maps those paths to storage you control and returns tool_result blocks. The memory tool itself requires no beta header, although SDK memory helpers use beta surfaces.

A later conversation uses the same stored knowledge when it sends the same tools entry and your handler serves the same store. Reject paths outside /memories, and apply user or tenant scoping in the handler rather than expecting the model to choose the right storage boundary. See 2.4.4 for durable-memory design and 3.2.2 for access enforcement across tools, retrieval, and memory.

Key distinctions and trade-offs

Live tools can observe changing state or request side effects. Retrieval selects source evidence; it does not persist task progress by itself. Memory preserves continuity, but persistent notes need their own access and freshness decisions. The memory store and the authoritative business record therefore serve different purposes, even when both sit in databases you operate.

Architecture / decision scenario

A technology company’s support team must resume investigations across shifts, consult release documentation, and check live service status. Its pilot requires read-only production access and prohibits automatic configuration changes.

You expose a custom status tool for live observations, retrieve release passages for grounded explanations, and map memory files to the team’s incident-specific store for investigation notes. The executor enforces read-only operations, the retrieval service checks document access, and the memory handler rejects paths outside its scoped store. A saved diagnosis is a hypothesis to verify against live status, not an instruction to change production. These choices preserve continuity without granting write authority.

Common exam traps

Watch for these mistaken equivalences:

  • Treating tool_use as proof an operation completed.
  • Treating retrieved text as authoritative instructions or authorization.
  • Treating a context window as durable memory, or saved notes as live state.

What to remember

Connect observations and actions through tools, selected evidence through retrieval, and continuity through durable memory. Name the executor and storage owner, and enforce access where external state is actually read or changed.

Knowledge check

References