In this article
Before you start
This page sits in the interview loops guide, where take-homes are one round type among several.
Why interviewers ask this
Candidates report take-homes of this kind from several companies: a game master agent with player agents, a memory service for an agent, a 20-turn conversation compressed under a token limit, a story pipeline with a judge, and a five-agent therapy-exercise system with human approval. These are reported by candidates, not confirmed company practice, and some prompts are unattributed.
The common thread is context. A reviewer reads your code and your write-up to see whether you decided what each agent knows, rather than wiring agents together and hoping. A weak submission has many agents, one shared message list and no evaluation. A strong one says why each agent exists, what it can see, what is dropped and how you checked that nothing important was lost. Roles that mix this with customer work appear in the forward deployed and applied AI engineer rounds. Neighboring take-homes are covered in the agent take-home and the retrieval-augmented generation (RAG) take-home, and the structure of AI-lab loops is in the Anthropic interview process and OpenAI interview questions.
Multi-agent and context engineering from first principles
- Structured note-taking
- Structured note-taking is the practice of having an agent write notes, such as a to-do list or a plain notes file, outside its context window and reload them later, so facts survive a context reset, a technique Anthropic describes as agentic memory.
In plain words
Picture a kitchen. One cook sees every order and every pan. That cook never contradicts themselves, but the kitchen is slow. Hiring more cooks speeds things up. That works only if each cook knows which dish is theirs and nobody changes the recipe without telling the others. The analogy breaks in one place: a cook remembers a whole shift, while a model forgets everything that is not in its window.
In one precise sentence, the build is a set of agents, each with a deliberately limited context, plus rules for what moves between them and what is stored outside any window. Anthropic names compaction, structured note-taking and multi-agent architectures as its techniques for long tasks. It says windows of all sizes will suffer context pollution, so a bigger window does not remove the work.
Step-by-step description
- Each agent reads and remembers its own.
- Multi-agent costs far more tokens.
- One agent applies decisions.
- Overflow is compacted and stored.
- Each agent gets its own context and memory namespace.
- A multi-agent run costs about fifteen times the tokens of a chat.
- One agent writes the final state.
- Overflow goes through compaction, notes and a long-term store.
Step 1: Give each agent its own context and its own memory
Start by writing, for every agent, what it reads, what it writes and how long that lives. The input is your task list; the output is a small table of agents and contexts.
The LangChain documentation separates two kinds of memory. Short-term memory is scoped to one thread. Long-term memory persists across threads and is built on stores that save JavaScript Object Notation (JSON) documents under a namespace and a key. The namespace works like a folder and the key like a file name. The same docs say to use a database-backed store in production, because the in-memory store is for development.
For a game simulation, give each player agent its own namespace and the game master a private one. Privacy comes from what your code lets each agent read: each agent's tools and prompt builder read only its own namespace, because a namespace is an organizing prefix and hides nothing from code that holds the store. You now know where every fact lives; the next step asks whether you need several agents at all.
Step 2: Check whether several agents pay for themselves
More agents cost more tokens. Anthropic reports that agents use about 4× the tokens of chat, and multi-agent systems about 15×, and says they suit valuable tasks with heavy parallelization, information beyond one window and many tools. These are Anthropic's observed averages for its research system, not a general constant. Take an illustrative 10,000-token chat. At those multiples it becomes 40,000 tokens for one agent and 150,000 for a multi-agent run.1
A subagent is an agent started by a lead agent to do one sub-task in its own clean window. It returns a short summary. Anthropic reports that a subagent often returns a distilled summary of 1,000 to 2,000 tokens, after exploring with tens of thousands of tokens or more. Five subagents then add 5,000 to 10,000 tokens to the lead's context, however much they read themselves.1
| Quantity | Value |
|---|---|
| Illustrative chat | 10,000 tokens |
| Single agent at 4× | 40,000 tokens |
| Multi-agent at 15× | 150,000 tokens |
| Lead context added by five subagents (five is illustrative), at 1,000 to 2,000 tokens each | 5,000 to 10,000 tokens |
Text description of the diagram
- An illustrative chat uses 10,000 tokens.
- One agent at about four times uses 40,000 tokens.
- A multi-agent run at about fifteen times uses 150,000 tokens.
Step 3: Keep every decision with one writer and share its context
Cognition's Don't Build Multi-Agents argues for two principles: share context and full agent traces, not just messages, and remember that actions carry implicit decisions, so conflicting decisions carry bad results. Its example has two subagents building parts of one game without seeing each other, so the parts do not fit. A later Cognition post says parallel agents make implicit choices about style, edge cases and code patterns.
The two positions fit together. Anthropic says domains where agents share context, or depend on each other heavily, are not a good fit for multi-agent systems today. So let subagents read, search and report in parallel, and let one agent write the final state. In the game, player agents propose actions; the game master alone applies rulings.
There is a tension to name: full traces help consistency but would show a player the game master's hidden information. The design here is our own reasoning: give each agent a filtered view, enforced in code so that its tools read only its own namespace, and keep the full trace only for the game master. The last step handles what no longer fits.
Step 4: Compress, store and measure what falls out of the window
Long runs overflow. Use compaction first; Anthropic calls it typically the first lever for long-term coherence. Add structured notes for facts that must outlive a reset, and long-term store entries for facts that must outlive a thread.
A reported take-home asks you to compress a 20-turn conversation under a token limit and describe an evaluation. With illustrative figures of 150 tokens a turn, 20 turns are 3,000 tokens; a 500-token budget is a compression ratio of 6 to 1.1 Evaluate by listing the key facts first. If 10 of 12 are still recoverable from the summary, retention is 83.3%.1 Anthropic's advice for a compaction prompt is to maximize recall first, then improve precision.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
How would you design the agents and manage their context for this take-home?
I would start with one agent and add more only where work is parallel and read-heavy, because multi-agent runs cost many times the tokens of a chat. Subagents explore and return short summaries. One agent owns decisions and writes state, since parallel writers make conflicting implicit choices. Each agent's tools read only its own namespace, so hidden information stays private. Overflow goes through compaction, notes and a long-term store. I would score compression by how many key facts survive, and report that number in the write-up.
What makes it Staff-level is that it states a cost, names a failure mode, and ends with a measurement rather than a diagram of boxes.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Agent design | Many agents, no reason given | Each agent has a role and a context | Starts single-agent, justifies each split by cost and parallelism |
| State and decisions | All agents write one shared list | Per-agent memory | One writer, filtered views enforced in code, hidden data isolated |
| Context management | Hope the window is enough | Summarizes old turns | Compaction, notes and a store, each with a stated trigger |
| Evaluation | None | A few manual checks | Key-fact recall measured, failure cases logged |
| Communication | Code only | README with a diagram | Names trade-offs, costs and what you would do with more time |
Three variants of this question
How do you build a multi-agent Dungeons & Dragons simulation with a game master agent and player agents?
The reported prompt asks you to address at least three of six challenges: long campaigns, hidden information (secrets), rulings, a self-aware dungeon, a living world and ambiguity, using LangGraph. The prompt is unattributed and the design here is our own: the game master writes state, players get filtered views from per-agent namespaces, and hidden facts sit in a game-master-only namespace, with code enforcing that each agent reads only its own, since a namespace alone hides nothing. LangGraph's swarm reference shows agents handing off context, with a checkpointer for short-term and a store for long-term memory.
How do you compress a 20-turn conversation and prove it kept the important facts?
Extract the key facts from the full conversation, compress to the budget, then ask questions that need those facts and check whether the compressed text answers them. Report the ratio and the share of facts retained, as in Step 4.
How do you detect that agents are stuck in a loop using semantic similarity?
Embed each new message and compare it with recent ones using cosine similarity, which is a score between minus one and one for how closely two embeddings point the same way. A reported prompt uses a 0.85 threshold. With illustrative vectors, a near-repeat scores 0.98 and an unrelated message 0.28, so only the repeat trips a 0.85 line.1 State that the threshold needs tuning on real data.
Common mistakes
- "Every sub-task gets its own agent." (wrong) Each added agent multiplies token cost and coordination. (right) "I split only where work is parallel and the cost is justified."
- "Agents share one message list, so context is solved." (wrong) Everyone sees hidden information and conflicting decisions pile up. (right) "Each agent's tools read only its own namespace, enforced in code; one agent writes the final state."
- "A summary keeps everything important." (wrong) Compaction loses detail. (right) "I measure which key facts survive."
- "Short-term and long-term memory are the same store." (wrong) One is thread-scoped, the other persists across threads. (right) "A checkpointer holds the thread; a store holds durable facts."
- "A larger window makes this unnecessary." (wrong) Anthropic expects context pollution at every window size. (right) "I still choose what goes in."
Follow-up questions
How do you evaluate the whole multi-agent output?
Judge the final result against a rubric built from the task spec, for example with a language model as judge, instead of auditing every step. Anthropic's multi-agent post discusses large language model (LLM)-as-judge evaluation and end-state evaluation. A reported story-pipeline prompt pairs a judge with up to two revision cycles, which is a sensible cap.
Where does human approval sit in a multi-agent system?
At the point where output becomes final. This is our own design: the agents draft, critique and refine, then the run pauses, a person approves or rejects, and only an approval lets the finalizing step write the result.
What should trigger compaction?
A token threshold relative to the context window, since compaction is for a conversation nearing the limit. A turn count is a cruder proxy because turns vary in size. This is our own design choice; log which trigger fired.
How do you cap cost and turns per run?
Set a token budget, a maximum number of turns and a maximum number of subagents per run, and stop with the best result so far when any limit is hit. This is our own design; the limits matter because multi-agent runs use many times the tokens of a chat.
What if the round is a live coding session instead?
Then the same context thinking applies, but under time pressure; see the AI-assisted coding interview and the broader AI engineer questions.
- Write down what each agent reads, writes and remembers before you write code.
- Use several agents only for parallel, read-heavy, high-value work; the cited cost is about 15× a chat.
- Keep decisions with one writer and give other agents filtered views.
- Compact, take notes and use a store, then measure which key facts survive.
Sources
- Effective context engineering for AI agents — Anthropic Engineering, 29 Sep 2025
- How we built our multi-agent research system — Anthropic Engineering, 13 Jun 2025
- Don't Build Multi-Agents — Cognition (Walden Yan), 12 Jun 2025
- Multi-Agents: What's Actually Working — Cognition (undated; accessed 2026-10-26), 26 Oct 2026
- Long-term memory — LangChain documentation (accessed 2026-10-26), 26 Oct 2026
- LangGraph swarm reference — LangChain reference documentation (accessed 2026-10-26), 26 Oct 2026
