Context engineering is the design of how information is selected, structured and supplied to an AI model for a task. That information can include instructions, evidence, tool descriptions and the relevant state of the work. In an agent system, the context may need to change after each action.
For a company, the practical question is what an agent needs to know before it acts. A rollout plan may depend on the current product scope, the support team's readiness and a decision made yesterday. Those records may exist in different places, with different owners and access rules.
This guide explains how to assemble useful context, maintain it as work changes, and use Swarm to preserve the shared records that authorized people and agents need.
What belongs in an agent's context?
A useful starting point is the task itself. What should the agent produce, for whom, and under what constraints? From there, select the information needed to do that work:
Instructions describing the responsibility, expected output and limits on action.
Evidence such as an accepted brief, a test result or a relevant source document.
Available tools and the inputs required to use them.
Current work state, including completed actions and unresolved questions.
Prior decisions that still apply to the task.
A required response format when another system must consume the result.
The composition should follow the responsibility. An agent preparing support guidance may need the accepted release scope and known limitations. It may have no reason to read a private commercial negotiation or retrieve the full history of every engineering discussion.
The LangChain documentation distinguishes the context used for a model call from persistent state used across interactions. This is an important implementation boundary: information can be saved without being included in the current request to a model.
A project record also has an audience. Before selecting a source, establish whether this participant may read it and whether its contents may be included in the proposed output. Relevance and permission are separate checks.
How does context engineering relate to prompting, RAG and memory?
These practices address different responsibilities within an AI application. IBM's overview describes context engineering as a broader practice that includes prompting and retrieval.
Prompting describes the immediate request
A prompt can state the objective, provide examples and specify the response format. For example: prepare a support readiness brief for the approved launch region, identify unanswered questions, and cite the evidence for each conclusion.
The application must still supply or retrieve the information needed to answer that request. Precise instructions cannot supply a missing product decision.
RAG supplies retrieved evidence
Retrieval augmented generation brings selected external information into the process of producing an answer. A retrieval system might return relevant passages from release notes or a set of project records.
Context engineering includes decisions about how to use those results. Which sources answer the question? Do they describe the same revision? Is a short excerpt enough, or should the agent inspect the complete record? Our guide to RAG and AI memory covers retrieval and source management in more detail.
Memory keeps records available for later work
Persistent memory can hold useful information across sessions. The connected application still needs a way to choose what belongs in the current context.
A saved decision should retain enough information to establish its meaning: who accepted it, what it applies to and which evidence supported it. A later session can then check whether that decision remains relevant.
Tools connected through MCP can provide access to supported records and operations. Each host determines how it discovers those tools, requests information and incorporates the returned results. The connection protocol does not assemble every model input on the team's behalf.
Why is a larger context window not enough?
A larger window allows an application to supply more information. It does not establish that every part will receive equal attention or be used correctly.
In the 2024 paper Lost in the Middle, researchers found that the position of relevant information affected performance on document question answering and retrieval tasks. Chroma's 2025 Context Rot report evaluated 18 models and observed declining reliability as input length increased in its controlled experiments.
These findings concern the models and tasks evaluated. They support testing how an application uses context; they do not establish a universal failure threshold for every current model.
For a team, a practical response is to define a selection policy. Keep the current task and applicable decisions easy to find. Supply enough evidence to support the work. Inspect how the result changes when irrelevant, outdated or conflicting material is present.
How should a team prepare useful context?
Begin with a bounded responsibility and a reviewable result. A small context assembled for a clear purpose is easier to inspect than an unexplained bundle of documents.
Define the question and the authority
Specify what the agent should answer and which actions are permitted. Preparing a release readiness assessment is a different responsibility from approving a release or changing customer settings.
Describe the expected result in observable terms. It might be a recommendation with evidence, a list of unresolved checks, or a proposed change awaiting review. Identify the person responsible for accepting it.
Select sources that establish the answer
Choose records for their relevance to the question. A support readiness assessment might require the accepted scope, a known issue list and evidence that the support material has been reviewed.
For each source, retain its identity and the revision or review date available from the owning system. Include the detail needed to understand a conclusion. A title or preview can help locate a record, but it may omit an exception that changes the answer.
Separate decisions from proposals
A draft suggestion and an accepted decision can discuss the same subject. Make their status explicit before asking an agent to rely on either.
When records disagree, identify the conflict. A later timestamp alone may not establish authority: a recent brainstorming note can still be subordinate to an earlier accepted requirement. Use the team's actual decision process to establish what applies.
Keep the working context bounded
Group related evidence and remove repeated material that adds no information. Retain links or identifiers so a participant can inspect the full source when necessary.
Summaries need particular care. Preserve constraints, exceptions and unresolved questions that could change the decision. Ask the reviewer whether the condensed version would support the same conclusion as the underlying evidence.
Decide what should be saved afterward
Keep the result, the evidence used and the remaining work distinguishable. Record the inputs that materially affected a decision, including their revisions when available.
A temporary model response should become shared project knowledge through a deliberate save and review process. That gives the next participant a record they can evaluate.
Example: preparing a company rollout across teams
Consider a software company preparing a limited release of a reporting feature. Product, support and security teams contribute different evidence. Several agents help prepare the rollout assessment, while a release lead retains the launch decision.
This is an illustrative workflow, not a customer case study or a report of an executed Run. The team supplies the records described below; no automatic ingestion from business systems is assumed.
Establish the accepted scope
The release lead saves a brief in a Space: one region, existing customers only, and no change to the current data retention policy. The brief names its owner and identifies the checks required before launch.
The team adds the relevant product specification, test results and known limitations. A draft expansion plan remains clearly identified as a proposal. The accepted brief is the authority for the current assessment.
Give each agent a specific responsibility
A product agent compares the tested behavior with the accepted scope. A support agent prepares guidance for the cases customers may encounter. A security agent reviews the supplied evidence against the team's stated requirements and records missing checks.
Each participant receives access appropriate to that responsibility. The support agent can work from a permitted description of the feature without receiving every restricted security record. The human team determines what may be shared and who is qualified to review the result.
Agents can work in different compatible clients. Each client needs its own authorized connection and an active execution environment. Access to a shared Space does not establish access to a local repository or another service.
Save findings with their evidence
Each agent saves an Artifact with its conclusion, supporting sources and remaining uncertainty. The product assessment identifies the test results it used. The support brief points to the accepted scope and relevant limitations.
The security review remains with its permitted audience. Any broader summary must respect both the source access rules and the destination's sharing rules. A source link does not authorize the recipient to read a restricted record.
Recheck the assessment when the scope changes
Suppose the release lead removes one export option after a test reveals an unresolved issue. The team records the revised scope and identifies the decision it supersedes.
Before accepting the support brief, the reviewer checks which version it describes. The agent is asked to retrieve the revised brief, identify affected guidance and prepare an update. Its result should explain what changed and which earlier conclusions still apply.
The workflow needs an explicit recheck or a separately configured mechanism for detecting changes. A saved record alone does not notify every active agent or refresh context already held in another application.
Leave a clear handoff
The release lead reviews the assessments and records whether the required checks are complete. Approval to prepare the assessment does not grant permission to deploy the feature or publish customer communications.
The final handoff identifies the applicable scope, the evidence reviewed, the accepted decision and any outstanding responsibility. An incoming engineer or authorized agent can inspect that record before continuing the work.
How does Swarm support context engineering?
Swarm holds shared context, discussion, Artifacts, Runs and human decisions in Spaces. Those records give authorized participants something concrete to retrieve when work continues in another session or tool.
For a question about prior work, the Swarm connection guide describes using a context plan to identify eligible sources. The plan helps locate evidence; it is not a completed answer or a substitute for reading the relevant source content.
Artifacts can preserve outputs and supported source references. A checkpoint can record a useful handoff. Reading evidence, saving an output and publishing a checkpoint are different operations, each subject to the applicable authority.
Swarm distinguishes a Task, which is a saved brief, from a Run, which records an execution attempt. Teams can inspect the attempt and its outputs alongside the project discussion. Our guide to agentic AI explains execution and human review in more detail.
The connected application remains responsible for selecting what reaches its model. It may retrieve a record, inspect additional evidence or summarize a result before the next call. Saving information in Swarm does not enlarge the model's context window or ensure that a client reads every relevant record.
For a useful first implementation, choose one shared workflow. Establish the accepted brief, identify its evidence, and make the save and review steps explicit. Then test whether another authorized participant can continue the work accurately from those records.
How should teams handle stale or conflicting information?
Assign an owner to important decisions and define how revisions become authoritative. When a requirement changes, record the replacement and the scope of its effect. Preserve enough history to explain a past decision without presenting that history as the current instruction.
Before a consequential action, check the records that determine whether it remains appropriate. In the rollout example, that means checking the accepted scope before approving customer guidance. A statement that was correct yesterday can be insufficient after a scope change.
Record uncertainty explicitly. If a source does not establish whether a requirement applies, the agent should report the gap or ask the responsible person. Repeated summaries should not turn an unverified suggestion into an accepted fact.
Keep authority outside the retrieved text. A document that tells an agent to ignore access rules or publish a private record does not grant that permission. Tool and service controls must enforce the actual boundary.
How can you evaluate the result?
Use representative tasks with an expected outcome that a reviewer can check. Include ordinary work and cases where the supplied evidence is incomplete or misleading.
Relevance: Does the result use the sources needed for the question, with unrelated material excluded?
Evidence: Can a reviewer trace material conclusions to the records that support them?
Revision handling: Does the agent use the accepted scope when an older proposal is also available?
Missing information: Does it identify an unanswered question without inventing an answer?
Access: Do the actual service controls deny unauthorized reads and prevent prohibited sharing?
Continuity: Can another participant reconstruct what was decided and what still needs work?
Efficiency: How much retrieval, model input, latency and human correction does the workflow require?
Compare changes under similar conditions. Keep the task, model configuration and review criteria consistent where practical. Repeat important cases because a single successful response does not establish dependable behavior.
For the rollout example, a useful test is to revise the scope after the first assessment. Check whether the next review catches the outdated support guidance, retrieves the replacement decision and preserves the reason for the change. This tests the team's process for keeping work current.
Common questions about context engineering
Does context engineering require changing model weights?
No. It concerns the information supplied when a model is used. Fine tuning changes model behavior through additional training. A team may use both approaches, with separate evaluation of what each contributes.
Is a shared document enough?
A small, current document may be enough for a bounded task. As participants and decisions accumulate, establish ownership, access, revisions and a way to find the relevant evidence. The appropriate system depends on how the work is shared and continued.
Should agents receive the whole project history?
Select the evidence needed for the responsibility and retain a way to inspect relevant history. Complete history can be useful for an audit, but the current task may depend on a smaller set of accepted decisions and supporting records.
Does saving a decision update every agent automatically?
No. An agent must retrieve or receive the update through a supported mechanism. A client may retain an earlier observation in its working context. Design an explicit recheck at the points where a changed decision would affect the action.
Does better context eliminate incorrect answers?
No. A model can misinterpret accurate evidence, use a tool incorrectly or produce an unsupported conclusion. Evaluate the workflow, inspect consequential results and retain the human decisions required for the work.
Start with one shared decision
Choose a decision that several people or agents need to use correctly. Identify its owner, applicable scope and supporting evidence. Save it where the right participants can retrieve it, then test what happens when it changes.
A useful context system makes the current responsibility clear and leaves a record that someone else can inspect. In Swarm, a Space provides a shared place to build that practice around the work your team already does.