DEV Community: Kobester

L102 Claude: Multi-Agent

Kobester — Sun, 23 Aug 2026 05:39:00 +0000

L102 Claude: Multi-Agent

Why Multi-Agent?
Hub-and-Spoke Architecture
Isolated Context
Coordinator's 5 Responsibilities
Execution Patterns
Dynamic Routing & Work Partitioning
Iterative Refinement & Structured Handoffs
Goal-oriented prompt design

1. Why Multi-Agent?

The three "pro" reasons are actually three different problems:

Fixed context window is a capacity problem. Partitioning is about fitting the work, not making it smarter. This ties straight back to the max_tokens / context concerns from earlier images.
Specialization is a quality problem. A focused system prompt outperforms one bloated prompt trying to be researcher, writer, and coder at once. This is the same "tighter scope = better output" principle behind good subagent design.
Parallelism is a latency/throughput problem. It only helps when subtasks are genuinely independent — dependent tasks gain nothing and add coordination overhead.

2. Hub-and-Spoke Architecture
Coordinator is the only node with authority — communication, error handling, and context all route through the hub, while subagents stay isolated and just execute

3. Isolated Context
Subagent start fresh, coordinator must explicitly pass all needed context

4. Coordinator's 5 Responsibilities

Flow:
Decompose -> Delegate -> Aggregate -> Evaluate -> Respond

Task Tool - 4 step delegation

A Task is a special tool call. When a coordinator wants a subagent to do something, it emits a tool_use block with type: "task". The key insight: a Task is just a tool whose implementation is another Claude agent rather than a function like a calculator or a database query.

6. Execution Patterns

Parallel vs Sequential vs Fork Sessions
P: Multiple task calls in one response
S: One task call per loop turn (wait for result)
FS: Same baseline, different paths, spawn multiple subagents from the same baseline context; each explores different directions. (essentially parallel execution with shared origin and deliberate divergence)

5. Dynamic Routing & Work Partitioning
Both attack the same enemy from different angles: redundant work. Routing prevents invoking agents you don't need; partitioning prevents the agents you do invoke from duplicating each other.

7. Iterative Refinement & Structured Handoffs

8. Goal-oriented prompt design

*DO: *

Should do Goal + output format: what is expected from sub agent to produce in what format
Constraints: what subagent MUST NOT do or access

Don't:

Exact tool call sequence
Over-constraining execution

L101 Claude: Agentic Loops

Kobester — Sun, 23 Aug 2026 04:05:24 +0000

L100 Claude Agentic Loops:

Communication Stack 4 layers from your code to Claude's servers — what each one does
messages.create() 5 parameters of the core API call — required vs optional
Tools = Descriptions The most tested distinction — what Claude sees vs what runs
The 4-Step Agentic Loop
Model-Driven Agency: Claude decides what to call — vs scripted automation where you do

1. Communication Stack 4 layers from your code to Claude's servers

The 4 layers flow:
Code -> Anthropic SDK -> Claude API -> Claude Servers

*2. messages.create() with 5 params *
One function to call in every agentic loop

Required:

model : Specify which Claude Model to use
max_tokens : Hard cap on response length

Optional:

system: Persistent instructions that shape every response
tools: Declare what actions Claude is allowed to request
messages: Full conversation history

3. Tools, descriptions, not code

Tools vs code:
Tools: Description puls a separate function (dont put execution logic inside the tool definition)
Code: actual function, eg API call, DB query

*4. The response Object & Agentic Loop: *

Two Critical fields:

STOP_REASON : Why Claude Stopped (end_turn: exit loop, tool_use: Claude needs code to act, max_tokens: Response cut off)
CONTENT[] : Array of blocks

Tool use block fields:
id: unique ID. Must match when sending result back.
name: which tool claude to call
input: arguments Claude chose based on context

Agentic Loop:
Send (call messages.create(), including tool definitions, converesation history → check stop reason end_turn, tool_use (step 3) → execute tools find every tool_use block in content array → append & repeat, add Claude response as assistant message, tool results as user message, back to step 1

5. Model-Driven Agency

Scripted Automation vs Model-Driven Agency

Calling Claude in a rigid, predetermined sequence is automation. True agency is when Claude reads context, chooses tools dynamically, and controls when the loop ends — while your code just executes what it decides. Claude reads tool descriptions and conversation context to decide which API to call.

5.1 Deep dive on stop_reason :
stop_reason field — the signal that tells your agentic loop what to do after each API response

Level 100: Claude foundations

Kobester — Sun, 23 Aug 2026 02:37:52 +0000

There are four basic components:

Claude Code
Agent SDK
Claude API
MCP

Claude Code
Claude Code is Anthropic's agentic command-line tool for code generation, refactoring, and debugging. It runs where your code lives, and you configure its behavior through a CLAUDE.md file, custom skills, and MCP integrations.

The distinction that matters: this isn't a chat window you paste code into. It's an agent that reads your files, makes edits, runs commands, and checks its own work inside your project.

Where it shines:

Pair programming on a real codebase
CI/CD automation (think fixups, migrations, dependency bumps)
Code review bots that comment on diffs
Monorepo tooling where context spans many packages
If your task is "operate on this repository," Claude Code is the surface built for it.

Agent SDK
The Agent SDK is a framework for building multi-agent applications. It hands you the primitives you'd otherwise write yourself: agentic loops, subagent orchestration, tool calling, and full lifecycle hooks.

The value here is that the hard parts of agent plumbing are already solved. You describe the agents and tools; the SDK runs the loop, routes between subagents, and gives you hooks to observe or intercept each step.

Where it shines:

Customer support agents that route, look up, and resolve
Research pipelines that fan out across sources and synthesize
Autonomous workflows that chain multiple decisions
If you're writing your own while loop around a model call and manually dispatching tools, the SDK is probably what you actually wanted.

Claude API
The Claude API is the HTTP layer for programmatic access to the model. This is messages.create(), tool_use, structured JSON output, batch processing, and streaming. No agent framework, no CLI, just the model and your code.

This is the lowest-level, highest-control surface. You own the loop, the state, and the orchestration. In exchange, you get maximum flexibility and the ability to run at scale.

Where it shines:

Data extraction from unstructured text
Content generation pipelines
Classification at scale (batch processing is your friend here)
If you want a single well-defined transformation, run many times, with predictable structured output, the API is the direct path.

MCP: Model Context Protocol
MCP is a standard, not a client. It defines how Claude connects to your databases, APIs, and services through tool and resource interfaces. You write (or install) an MCP server that exposes capabilities, and any MCP-aware client, including Claude Code and the Agent SDK, can use them.

The point of MCP is that you build the connector once and reuse it everywhere. Instead of wiring a database into three different apps, you write one MCP server and every surface can talk to it.

Note: Common Claude Architecture Challenges and Solutions

Kobester — Sun, 23 Aug 2026 02:26:13 +0000

Claude Architecture Common Challenges and solutions:

Lossy Summarization vs. Immutable State Ledgers
Prompt Instructions vs. Code-Level Enforcement

Lossy Summarization vs. Immutable State Ledgers
The Scenario
As long-running agentic sessions accumulate chat history, developers often introduce context-window optimization techniques—such as rolling sliding windows or recursive LLM-based summarization—to compress old turns into concise paragraphs.

Why It Fails
Summarization is inherently lossy compression. When an LLM summarizes a conversation, it abstracts away specific details to save space. Precise, exact-match entities—such as transaction UUIDs, cryptocurrency hashes, invoice numbers, or strict timestamps—frequently get generalized or dropped entirely. If a user later references an order number mentioned 20 turns ago, a summarized memory store will return a miss or a hallucination.

The Architectural Solution
Implement a tiered memory architecture. While conversational history can be summarized for flow, critical transactional data must be preserved in a dedicated, immutable sidecar structure (often called a Case Facts store or State Ledger). Append-only logs ensure exact keys are preserved verbatim, entirely decoupled from the summarization engine.

Prompt Instructions vs. Code-Level Enforcement

The Scenario
An agent has access to a tool called execute_financial_transfer or modify_database_record. To prevent dangerous actions, a developer adds strict rules to the system prompt: "You must never execute a transfer exceeding $500 without explicit manager approval."

Why It Fails
Prompt-based guardrails are probabilistic suggestions, not hard security boundaries. Through indirect prompt injection, clever phrasing, or model drift, an LLM can easily be persuaded to bypass system instructions. Relying on prompts to enforce hard safety or monetary limits introduces a critical security vulnerability.

The Architectural Solution
Enforce Defense-in-Depth via Programmatic Interception. Before any tool payload is dispatched to an external API or database, it must pass through a code-level middleware or PreToolUse hook. The business logic check (e.g., if payload['amount'] > 500: raise ValidationError) must live in deterministic code that the model cannot override or negotiate with.