Why CrewAI's per task context parameter beats relying on shared memory

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

Attempt it

Shared memory adds every prior output to every subsequent agent's context. That bloats the token bill linearly with crew depth, makes role bleed easy (every agent sees the others' voice and starts mimicking it), and makes traces hard to read because you cannot tell what each agent actually 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, and 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. Shared memory keeps a growing log that every agent can read on every turn. The context parameter lets a task declare which specific 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 is the difference between a workflow that scales and one that becomes a mess. Shared memory adds every prior output to every subsequent agent's context. That means 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 actually used to do its job. The context parameter forces you to be explicit. The drafting task lists the research task and the outline task 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, which is exactly 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 actual 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. Shared memory, by contrast, broadcasts every output to every subsequent agent. Three problems with shared memory by default. 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 exactly the shape you want for cost attribution and debugging. The heuristic teams converge on: shared memory for human-readable conversation history when that matters; 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, kills role bleed, and turns the workflow into a debuggable DAG; shared memory feeds everything to everyone 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, the inbox is enormous, and 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. Smaller inboxes, clearer roles, 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 bites teams as their crews grow. By default, shared memory connects every agent to every other agent's output. 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 the default narrative thread. Every task's output is appended to a memory store that every subsequent agent can read. The agent prompt is augmented with the relevant memory entries 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], which tells CrewAI to thread the outputs of those specific tasks into this task's prompt and to ignore the rest. 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 shared memory by default scales badly

What explicit context fixes, and the DAG mental model

When shared memory still earns its keep

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, context=[research])
draft = Task(description="Write the article", agent=writer, context=[outline, research])
edit = Task(description="Edit for clarity", agent=editor, 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

Enabling shared memory because it is the default and assuming explicit context can be added later. By then the agents have learned to lean on the shared view and the role-bleed is baked in.

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

What are the two CrewAI mechanisms for moving information between tasks?
How does shared memory by default inflate token cost as crew depth grows?

Primary sources. Browse if you want the original framing.