ต้องใช้ประวัติทั้งหมด

The most important fact about the Claude API: the model is stateless. It remembers nothing between requests. There is no hidden session on Anthropic's side holding your earlier turns.

Every time you call the API, you send the entire conversation history in the messages array. If a fact isn't in that array, the model simply doesn't know it — even if it told you the same fact thirty seconds ago.

For a Claude Certified Architect, internalizing this changes how you design every multi-turn system, agentic loop, and multi-agent handoff.

A Claude API request carries a fixed set of fields. The ones you'll touch on every turn:

• model — which Claude model to call
• max_tokens — output budget
• system — the system prompt (instructions, persona, rules)
• messages — the full conversation history as an array of role/content objects
• tools and tool_choice — optional tool definitions and selection control

Notice what is NOT here: any kind of conversation ID or session token. State lives entirely in what you resend.

To continue a conversation, you don't 'reply' to a session — you append the model's previous answer and the new user turn to the same messages list, then resend the whole thing.

The pattern: take last turn's messages, push the assistant's response, push the new user message, and call again. The array grows with every exchange.

Suppose you send only the latest user message — "What about the weather then?" — and drop the earlier turns. The model has no idea what 'then' refers to or that Japan was ever mentioned.

It will either ask for clarification or hallucinate a context. This is the single most common cause of 'the bot forgot what we were talking about' bugs. The fix is never a prompt trick — it's resending the full history.

History isn't just user and assistant text. When the model calls a tool, the conversation continues with structured turns:

• an assistant turn containing a tool_use block
• a user turn containing the matching tool_result

You must append the tool result back into messages and resend everything. The model only 'sees' the tool's output because it's now part of the history you carry forward.

This is why the agentic loop works the way it does. Each iteration: send the request, inspect stop_reason, and if it's tool_use, run the tools, append the results to history, and loop again — until stop_reason is end_turn.

The loop is fundamentally a history-accumulation loop. Terminate on the stop_reason, NEVER by scanning the text for words like 'done'. An iteration cap is a safety net, not the primary stop mechanism.

Here's the multi-agent trap. In a hub-and-spoke system, a coordinator delegates work to subagents via Task calls. But a subagent gets a fresh conversation — it does NOT inherit the coordinator's message history.

If the subagent needs the customer's ID, the order number, or any earlier finding, the coordinator must pass it explicitly inside the subagent's prompt. Assuming inheritance is a guaranteed failure: the subagent runs blind.

Because state isn't shared, the coordinator's job includes packaging the right context into each delegation. Give the subagent exactly what it needs to act — no more (least privilege also applies to context).

Multiple Task calls in one response run in parallel, and each one is a self-contained brief. Treat every subagent prompt as a complete, standalone request.

Resending everything has a consequence: each turn re-tokenizes the entire history. Long conversations mean larger, slower, costlier requests, and eventually the context window fills up.

Architect-level reliability work is about managing that growth without losing fidelity:

• Trim verbose tool output to only the relevant fields before appending.
• Progressive summarization compresses old turns — but beware: it makes numbers, percentages, and dates vague.

The fix for vague summaries: pull hard facts — order IDs, amounts, dates, verified identities — into a separate 'case facts' block kept verbatim, outside the summary. Summarize the chatter, never the numbers.

Also mind lost-in-the-middle: models attend most to the start and end of the context. Put the most critical facts and the current instruction where they'll be seen, not buried in the middle of a long history.

Claude Code persists history across sessions: --resume <name> continues a named session, and fork_session branches from a shared point. Convenient — but a caution worth remembering for the exam.

Resumed tool results can be stale if the codebase changed since they were captured. Carrying forward old history isn't always right; sometimes a fresh session seeded with a clean, structured summary beats replaying outdated context.

A scenario testing the core decision of this lesson.

Lock these in for the exam and for real systems:

• The model is stateless; every request must carry the entire messages history.
• Tool calls extend history — append each tool_result and resend everything.
• The agentic loop is a history-accumulation loop; stop on stop_reason, not on parsed text.
• Subagents do not inherit the coordinator's history — pass all context explicitly in each prompt.
• History grows: trim verbose tool output, summarize old turns, but keep transactional facts verbatim and mind lost-in-the-middle.
• Resumed sessions can carry stale tool results — sometimes a fresh session with a clean summary is better.