In CrewAI, what does allow_delegation=True add to an Agent, and what does it cost?
answer
- Two extra tools appear on the agent
- Coworkers are addressed by role text
- Only a string crosses the handoff
- The model decides, not your code
- Watch for two agents ping-ponging
basics
~20 sIt appends coworker tools — delegate work and ask a question — to that agent's toolset, built from the crew's other agents and addressed by role string. The cost is extra LLM turns, longer prompts, and lossy handoffs, since only text crosses between agents.
solid answer
~50 sSetting `allow_delegation=True` gives that agent two extra tools, generated from the other agents in the same crew: one to hand a coworker a piece of work, one to ask a coworker a question. Both take the coworker's **role string** plus a task description and some context, so the handoff is text — the peer does not see your agent's message history or tool results, only what was written into the call. The peer then runs its own full agent loop with its own tools and returns a string. The cost is real: every delegation is at least one extra model call on each side, the delegating agent's prompt now carries descriptions listing every coworker, and agents can ping-pong work back and forth until the iteration cap stops them. Default is `False`, and leaving it off with explicit task wiring is usually cheaper and far easier to trace.
code
python · 16 linesfrom crewai import Agent
analyst = Agent(
role="Lead Analyst",
goal="Answer the question, checking facts with a coworker when unsure",
backstory="You delegate only when you cannot verify a claim yourself.",
allow_delegation=True,
max_iter=12,
)
fact_checker = Agent(
role="Fact Checker",
goal="Confirm or refute a single claim and cite the source",
backstory="You answer the claim you were given and nothing else.",
allow_delegation=False,
)go deeper
Know that allow_delegation is a boolean on the Agent, defaults to False, and lets that agent hand work to another agent in the same crew rather than doing it itself.
Explain the mechanism: two generated coworker tools, the coworker chosen by role string, a text-only payload, and a full agent loop on the receiving side that returns a string.
Show that you treat delegation as non-deterministic and expensive — you enable it on one agent, bound iterations and timeouts, read verbose traces for ping-pong, and prefer explicit wiring for dependencies known at design time.
Own the architectural call: when the flexibility of model-chosen delegation is worth losing a predictable execution order and cost ceiling, and what you require in traces and budgets before allowing it in production.
## What the flag actually does `allow_delegation` is a boolean on `Agent`, default `False`. When it is `True` and the agent is part of a crew with other agents, CrewAI appends generated coworker tools to that agent's toolset before it runs. There are two: one for delegating a unit of work, one for asking a coworker a question. They appear to the model like any other tool, with descriptions that enumerate the available coworkers by role. The important consequence is that delegation is a *model decision*, not a control-flow construct. Nothing in your code says "now hand this to the writer". The delegating agent reads its own goal, sees a tool whose description says a coworker exists, and decides — probabilistically — whether to use it. ## The shape of a handoff A delegation call carries three things: the coworker (by role string), the work to do, and some context. That is the entire payload. The recipient does **not** inherit the caller's conversation, its retrieved documents, or its tool outputs — only the text the caller chose to write. This is why delegated work so often comes back subtly wrong: the caller under-specifies, the coworker fills the gap with plausible invention, and the caller accepts the string. The recipient runs a complete agent loop of its own: its own system prompt from its role/goal/backstory, its own tool list, its own iteration budget. It returns a string, which lands in the caller's message history as a tool result, and the caller continues. ## What it costs **Model calls.** A single delegation is at minimum one call for the caller to decide and write the request, one or more for the coworker to do the work, and one for the caller to integrate the reply. Delegation between agents on expensive models multiplies quickly. **Prompt size.** The coworker tools' descriptions list the crew's other agents, so every agent with delegation enabled carries a larger system prompt on every turn — including turns where it never delegates. **Loops.** Two agents that can each delegate to the other can pass the same task back and forth. There is no framework-level cycle detector; what stops it is the iteration cap and the execution timeout. In a verbose log this looks unmistakable, which is the main reason to run with `verbose=True` while developing a delegating crew. **Addressing by role.** Because the coworker is identified by role string, similar or long role names make the choice noisy. If the model writes a role that does not match a coworker, CrewAI attempts to reconcile it and can surface an error or pick the wrong agent — a class of bug that does not exist when work is wired explicitly. **Traceability.** With delegation off, the execution order is what you declared. With it on, the order is whatever the models decided this run, and it can differ between two runs of the same input. ## When it earns its keep Delegation is worth enabling when the caller genuinely cannot know in advance whether the peer is needed — an analyst who only sometimes needs a fact-check, a writer who occasionally needs one more search. It is not worth enabling when the dependency is known at design time: in that case express it as an explicit ordering of work, which is deterministic, cheaper and readable in a trace. A useful default is to enable delegation on at most one agent in a crew — the one doing the open-ended reasoning — and leave every specialist with `allow_delegation=False` so it does the job it was given and returns. That single change removes almost all ping-pong. ## Debugging a delegating crew Run with `verbose=True` and read who called whom. Look for three signatures: the same pair of agents exchanging near-identical requests (a loop), a coworker being asked for something it has no tool to do (a role/tool mismatch), and a delegation whose request text is thinner than the caller's own context (the lossy handoff). Bound the blast radius with the agent's iteration cap and execution timeout while you fix the cause. If the pattern is stable and known, the honest fix is usually to stop delegating and wire the step explicitly. ## Interview framing The strong answer names the mechanism (two generated coworker tools, role-string addressing, text-only payload, full peer loop), then goes straight to cost and non-determinism. The weak answer describes delegation as if it were a call graph you control.
- Why does a delegated sub-task often come back with invented details?Because the handoff carries only the text the caller wrote — a coworker role, a task description and some context. The coworker does not see the caller's history, retrieved documents or tool outputs, so anything the caller left implicit is a gap the coworker fills with plausible generation. The mitigations are a backstory that tells the coworker to say when information is missing, and giving it the tool it needs to look the answer up.
- Two agents in your crew keep delegating to each other. What stops it, and what fixes it?Nothing detects the cycle; what stops it is the agent's iteration cap and, if set, its execution timeout — so the run ends expensively rather than correctly. The fix is structural: turn delegation off on all but one agent so specialists must answer rather than forward, and express any dependency you already know about as explicit ordering of work instead.
- How does enabling delegation change what you can promise about a run's cost?It removes the upper bound you had. With delegation off, the number of agent loops is what you declared. With it on, each delegating agent may spawn peer loops at its own discretion, and each peer may take its full iteration budget. If cost predictability matters, keep delegation off and bound the crew structurally, or cap `max_iter` and `max_execution_time` on every participating agent.
saying these in an interview costs you the question
- Thinks delegation is deterministic control flow you specify
- Believes the coworker inherits the caller's full context
- Assumes CrewAI detects and breaks delegation cycles
- Thinks allow_delegation defaults to True
- Enables delegation on every agent by habit