Why CrewAI's per task context parameter beats passing every prior output

Flashcard·Medium·4.0 · 0·~30s·Asked atElastic Robinhood Truera

Attempt it

Without it, CrewAI passes every prior task output into each later task's context. That bloats the token bill linearly with crew depth. It makes role bleed easy (every agent sees the others' voice and starts mimicking it). It also makes traces hard to read, because you cannot tell what each agent needed.

The context parameter forces you to declare per task which prior outputs matter. The drafting agent gets the research and the outline. It does not get the manager's internal scratch notes. Tokens stay bounded. Role bleed drops because agents see only the data they need. The workflow becomes a DAG of explicit dependencies you can debug. The general rule is: shared memory for human-readable conversation, explicit context for the actual data-passing between tasks.

Your answer

CrewAI gives you two ways for one agent's output to reach another. By default, each task receives the outputs of every earlier task. The context parameter lets a task declare which prior task outputs it wants threaded into its input. The difference looks small on a two-agent crew. On a five-agent crew with several tasks each, it decides whether the workflow scales or becomes a mess. That default lets three failure modes compound. **Cost goes up linearly with crew depth.** Every new task carries the weight of everything before it. **Role bleed creeps in.** The writer sees the researcher's prose and starts to sound like them. The editor sees the writer's self-corrections and starts grading the wrong things. **Traces become unreadable.** You cannot tell what data each agent used. The context parameter forces you to be explicit. The drafting task lists the research and outline tasks as its context. Nothing else gets in. The editing task lists the drafting task and the brief. The workflow becomes a directed graph of declared dependencies, the shape you want for debugging and cost control. The rule of thumb most teams settle on: shared memory for human-readable conversation history, explicit context for the data-passing.

**CrewAI's `context` parameter on a `Task` is the per-task input-scoping mechanism.** It lists exactly which previous tasks' outputs should be threaded into this task's prompt. Without it, CrewAI passes every earlier task's output into each later task. That default has three problems. First, **token bloat**. Every additional task carries the cumulative weight of everything before it. A six-task crew can pay 3 to 5 times the tokens of an equivalent explicit-context version. Second, **role bleed**. Agents that read each other's intermediate work mimic each other's voice and start grading the wrong things. The editor that reads the writer's self-corrections sometimes ends up editing the corrections instead of the draft. Third, **trace illegibility**. When every agent reads everything, you cannot tell from a trace what each agent actually needed. The context parameter fixes all three. The drafting task declares the research and outline tasks as its context. Nothing else gets in. Token cost stays bounded by the actual data dependency. Role bleed drops because agents only see the data their job requires. The workflow becomes a directed acyclic graph of declared dependencies, which is the shape you want for cost attribution and debugging. The heuristic teams converge on: shared memory for human-readable conversation history when that matters, and explicit `context` for the actual data-passing between tasks. The two coexist, but the data-flow should be explicit.

TL;DR

CrewAI's per-task context parameter caps tokens, cuts role bleed, and turns the workflow into a debuggable DAG. The default feeds every earlier output to every later task and lets all three problems compound.

Memory aid

Easy to grasp

Imagine a writing team where every email about the project is automatically forwarded to everyone. The researcher gets the editor's feedback notes. The editor gets the researcher's scratch links. The manager gets the writer's grammar self-corrections. Nobody can find the email they actually need, and the inbox is enormous. People slowly start sounding like each other because they keep reading each other's drafts. Now imagine instead that each person gets only the documents they need. The writer gets the research and the outline. The editor gets the writer's final draft. Inboxes are smaller, roles are clearer, and it is easier to figure out what went wrong when something does. CrewAI's context parameter is the second option.

Key concepts

Multi-agent systems LLM frameworks Context engineering

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

CrewAI's mental model is borrowed from a real team: agents have roles, goals, and backstories; they take on tasks; the crew runs them in order. The metaphor is friendly and the API reflects it, which is why CrewAI is the easiest framework to start with.

The metaphor also hides a design choice that causes problems for teams as their crews grow. By default, every task receives the outputs of all earlier tasks. That works for two agents and breaks at five. The fix is in the API, but it is opt-in: the context parameter on a Task. Most teams discover it the hard way, after a cost incident or a quality regression that traces back to role bleed.

The two mechanisms CrewAI gives you

CrewAI exposes two ways for information to flow between agents on a crew.

Shared memory is an opt-in narrative thread (memory=True on the crew). CrewAI saves task outputs to a memory store and adds the relevant memory entries to the agent prompt at run time. The metaphor is the office chat channel: anyone can scroll back and see what everyone has been doing.

The context parameter on a Task is the explicit data-flow mechanism. When you define a task, you can pass context=[task_a, task_b]. This tells CrewAI to thread the outputs of those specific tasks into this task's prompt and to ignore the rest. Without context, a task receives the outputs of every earlier task. The metaphor is the meeting brief: each task gets exactly the documents it needs to do the work.

The two mechanisms coexist. You can have shared memory on for narrative continuity and context declared on individual tasks for data-flow discipline. The choice between them is the choice between implicit and explicit data dependencies, and that choice has real consequences as the crew grows.

Why passing every output by default scales badly

What explicit context fixes, and the DAG mental model

When shared memory is still worth it

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

from crewai import Agent, Task, Crew, Process

researcher = Agent(role="Researcher", goal="Find sources", backstory="...")
writer = Agent(role="Writer", goal="Draft article", backstory="...")
editor = Agent(role="Editor", goal="Polish prose", backstory="...")

research = Task(description="Gather 5 primary sources on X", agent=researcher, expected_output="bullet list")
outline = Task(description="Outline a 1000-word piece", agent=writer, expected_output="outline", context=[research])
draft = Task(description="Write the article", agent=writer, expected_output="article draft", context=[outline, research])
edit = Task(description="Edit for clarity", agent=editor, expected_output="edited article", context=[draft])

crew = Crew(agents=[researcher, writer, editor], tasks=[research, outline, draft, edit], process=Process.sequential)

Real products, models, and research that use this idea.

Content-generation crews where a researcher feeds an outliner, the outliner feeds a writer, and the writer feeds an editor. Each task declares only its direct upstream dependencies, which keeps the writer's context to the outline plus brief instead of the full research dump.
Sales-enablement workflows on CrewAI where a lead-research task feeds an email-drafting task and a CRM-update task. Explicit context ensures the drafting task does not see the CRM payload schema and vice versa.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you decide whether a task should consume an upstream task's full output or a summary of it?

Look at what fields the downstream task actually quotes or transforms. If it only needs a structured subset, add an intermediate summarisation task or pre-process the output before threading it in.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Keeping the default, where every task gets all earlier outputs, and assuming explicit context can be added later. By then the agents depend on the shared view, and the role bleed is built into the crew.

60 second bullets to scan on the way to the call.

What are the two CrewAI mechanisms for moving information between tasks?
How does passing every earlier output by default inflate token cost as crew depth grows?

Primary sources. Browse if you want the original framing.