How it works
Shared context is information that more than one component or agent can consult during a workflow. It can include the goal, requirements, decisions already made, intermediate results, and data needed to complete the task. The term describes an architectural pattern, not a single protocol.
An application can share context via messages between agents, via a state object, via files, or via a database. Each step reads what it needs and, when allowed, adds results. In some frameworks this state is explicit: the LangGraph documentation describes nodes that read and write to a shared state.
Sharing does not mean exposing everything to everyone. The system must define which agents can read or change each piece of information, how to resolve conflicting updates, and how long data remains available. Without these rules, an agent may use an outdated decision, overwrite a result, or access data outside its scope.
It is also important to distinguish shared context from context window. The window limits what a model receives in a single call; shared context is the application layer that maintains and distributes information throughout the flow. The application can select only part of that state to send to each model.
Practical example
A team automates the implementation of a feature. A planning agent records the requirements and acceptance criteria. A coding agent reads those items to propose changes. Then a review agent consults the same criteria and the diff to look for issues.
The application can keep a record with fields such as goal, files changed, tasks completed and pending. Agents do not need to receive the entire conversation history, only the data relevant to their step. This reduces repetition and makes it clearer where each decision came from.
If the reviewer finds an issue, they add the observation to the state and send the task back for correction. The team defines who can change requirements, who can change code, and when a person needs to approve the next step. This way, a provisional output does not automatically become a final decision.
In a test, simulate contradictory information and state changes. Confirm that agents identify the latest version, respect permissions, and do not confuse external content with trusted instructions. Record the origin of important decisions so a person can audit the flow.
What it's for
Shared context coordinates components that work in steps or in parallel. It lets agents use previous results without rebuilding the entire conversation and helps keep goals and criteria consistent throughout a task.
The pattern is useful in multi-agent systems, multi-step automations, and applications that combine models, tools, and data. It should be used together with access limits, data validation, and rules for conflicts and updates.
When designing this feature, decide which information is global to the flow, which belongs to an agent, and which should remain private. Define a clear format, log important changes, and avoid storing data that does not contribute to the task.
A well bounded shared context improves coordination, but it does not guarantee that agents will interpret the data correctly. Each relevant output still needs validation, and high impact decisions must have an owner defined. The architecture should make visible the information used, who modified it, and which steps are still pending.