Lesson 4 – Claude Certified Architect – Full Course

The Blank Slate Problem in Multi-Agent Systems

When an orchestrator spawns a subagent, that subagent begins with an empty context window. It has no memory of prior conversations, no awareness of the overarching task, and no access to data the orchestrator has already gathered. This design is deliberate rather than a flaw. Keeping subagents stateless ensures they remain isolated, predictable, and inexpensive to invoke. The alternative—persisting full conversation histories across every worker—would balloon token usage and introduce confusing state dependencies that are hard to debug. Understanding this intentional blank slate is the first step toward building reliable multi-agent architectures.

The blank slate property forces the architect to think explicitly about what information each subagent needs. Instead of assuming the subagent can look back at what came before, the developer must craft a precise context payload. This constraint actually improves system design because it eliminates hidden dependencies. Every piece of information the subagent receives is consciously chosen, making the system easier to audit and test. The blank slate is not an obstacle to overcome but a design principle that enforces clean separation of concerns across agent boundaries.

Structured Versus Unstructured Context

Passing context between agents can be done in two broad ways: unstructured and structured. Unstructured context typically means concatenating raw text, previous outputs, or conversation logs into the prompt. This approach works for simple, linear tasks but breaks down quickly when multiple pieces of information need to be tracked, attributed, or verified. Unstructured context makes it difficult to distinguish between instructions, content to analyze, and metadata about that content. As the complexity of the agent workflow increases, the lack of separation leads to confusion, attribution errors, and hallucinations.

Structured context solves these problems by separating content from metadata. The core idea is to formalize what each subagent receives so that the payload has clear, predictable fields. Content represents the actual text or data the subagent must process. Metadata provides information about that content: where it came from, when it was retrieved, what its confidence level is, and any constraints that apply. By maintaining this separation, the subagent can reliably distinguish between the data it is analyzing and the contextual wrapper that describes that data. This pattern also makes it much easier to audit exactly what information influenced a particular decision downstream.

The Finding Object Pattern

One practical method for passing structured context is the Finding Object pattern. Each piece of information gathered by the orchestrator is wrapped in a finding object that bundles the content itself with essential metadata fields. A typical finding object includes the source identifier, a retrieval timestamp, a confidence score, and the raw content. When the orchestrator compiles findings from multiple sources and sends them to a subagent, the subagent receives a clean, consistent data structure. This uniformity allows the subagent to reason about the evidence without confusing instructions with evidence.

The Finding Object pattern also simplifies the orchestrator's logic. Instead of building custom prompts for every subagent call, the orchestrator can apply a standard transformation to its collected data. It aggregates findings, filters out low-confidence items, and passes the resulting list directly to the subagent in a structured format. The subagent, in turn, can reference each finding by its unique identifier, trace every claim back to its source, and flag any inconsistencies it detects across findings. This level of traceability is nearly impossible to achieve with raw, unstructured text dumps.

How Attribution Gets Lost in Transit

Attribution is one of the first casualties in poorly designed agent pipelines. When a subagent synthesizes information from multiple sources, it may generate outputs that combine facts from several origins without preserving where each fact came from. If a downstream agent then uses that synthesis as input, the original provenance is permanently lost. This cascading loss of attribution makes it impossible to verify which sources support which claims, eroding trust in the entire system's output.

The root cause is often that subagents output only the synthesized result, not the intermediate reasoning or source mappings. Without explicit instructions to preserve attribution, the subagent will naturally summarize, merge, and rephrase in ways that obscure origin information. The solution is to require subagents to output structured responses that include claim-source mappings alongside the synthesis. This way, the orchestrator can maintain a chain of attribution that survives multiple synthesis steps, allowing end users or downstream processes to trace every assertion back to its supporting evidence.

Claim-Source Mappings and Conflicting Sources

Claim-source mapping is a technique where each factual claim produced by a subagent is explicitly linked to one or more source identifiers. When a subagent extracts a finding from a document, it records that the claim derives from a specific source. If multiple sources support the same claim, all relevant identifiers are included. This mapping travels alongside the claim through subsequent processing steps, preserving a verifiable lineage that auditors and downstream agents can rely on.

Conflicting sources present a special challenge. When two findings disagree on a factual point, the subagent must not silently pick one without justification. A robust architecture includes a conflict resolution strategy that may involve deferring to a higher-confidence source, flagging the conflict for human review, or invoking an additional verification step. The structured context payload should expose these conflicts explicitly so that the orchestrator can make informed decisions. Ignoring conflicts or resolving them opaquely inside a subagent simply pushes the problem out of sight without actually solving it.

Session Management Patterns

Managing sessions in agentic systems involves three distinct patterns: named session resumption with --resume, forking sessions for parallel exploration, and intentionally starting fresh to avoid stale context. Named session resumption allows an orchestrator to pick up exactly where a previous interaction left off, preserving all context, tool results, and intermediate state. This is useful when a workflow is interrupted or when building progressive, long-running analysis tasks.

Forking sessions enables parallel exploration where multiple subagents branch off from a common point to investigate different hypotheses simultaneously. The fork creates an isolated copy of the session state so that each branch can mutate independently without interfering with others. Finally, there are situations where resuming is actively harmful. When tool results have become stale or the environment has changed, carrying forward old context leads to decisions based on outdated information. Recognizing when to start fresh—discarding accumulated context in favor of a clean retrieval—is a critical judgment that architects must exercise regularly.

Exam-Ready Reasoning on Context and Sessions

The Claude Certified Architect Foundations exam tests these concepts through scenario-based questions that require deeper reasoning than simple recall. A typical question might describe a multi-agent system where a subagent generates contradictory outputs and ask which context-passing pattern would prevent the issue. The correct answer usually involves structured context with explicit claim-source mappings rather than a technical adjustment to the model or a prompt tweak.

Distractors often sound plausible: adding more instructions to the prompt, increasing the model's temperature, or switching to a larger model. But these approaches do not address the structural problem of lost attribution. The exam rewards understanding that architecture decisions—how context is structured and passed between agents—are the foundation of reliable multi-agent systems. Effective preparation involves practicing with questions that present realistic failure modes and analyzing why each distractor fails to solve the underlying design problem.