| Internet-Draft | Agent Context Interaction Opt. | October 2026 |
| Chang & Peng | Expires 28 April 2027 | [Page] |
The context distribution is important in a multi-agent system, which will impact the execution latency, token consumption, and task completion success rate, especially in a complex and multi-round workflow.¶
This document specifies the scenarios and procedures of agent context distribution as well as the corresponding optimization during the procedures in order to provide precise control of the context distribution among the multiple agents.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In a multi-agent system, contexts such as agents' capabilities, metadata, and intermediate results are exchanged among agents through an Agent2Agent (A2A)protocol to support task execution.¶
At present, agent context interaction commonly occurs in two scenarios: interaction among independent agents and interaction among collaborative agents. In both scenarios, context information is typically distributed in a raw or unfiltered manner, without task-aware or relevance-based processing. As a result, large volumes of redundant or irrelevant context are propagated across agents, leading to excessive token consumption.¶
Furthermore, existing agent interaction protocols generally lack explicit task management mechanisms, such as task state tracking and progress awareness, for complex tasks that require multi-turn interactions and the coordinated invocation of multiple agents. In the absence of structured task context, the LLM’s attention may drift across interaction rounds, which can significantly increase execution latency and reduce overall task success rates.¶
In this document, we assume a task-oriented multi-agent control model in which a designated Master Agent is responsible for global task orchestration, while other agents are invoked on demand to execute specific subtasks. The Master Agent receives the user request, constructs the overall task, decomposes it into subtasks, and coordinates their execution by selectively invoking appropriate Server Agents.¶
Invoked Server Agents operate under the control of the Master Agent and focus exclusively on the execution of assigned subtasks. They do not maintain a global view of the task and do not directly interact with end users or other invoked agents unless explicitly mediated by the Master Agent. This master–invoked agent architecture establishes a clear separation between global task management and localized task execution.¶
Efficient context distribution is a critical capability in such a master–invoked multi-agent system and is largely determined by the design of the agent context interaction protocol. The protocol directly controls how much context is exchanged, how it is structured, and how it is propagated across agents. As a result, it has a direct and measurable impact on execution latency, token consumption, and task completion success rate, particularly in complex and multi-round agent workflows.¶
This document specifies the scenarios and procedures for agent context distribution and introduces corresponding optimization mechanisms applied during these procedures. The goal is to provide precise and task-aware control over context dissemination among multiple agents, thereby improving execution efficiency, reducing unnecessary token usage, and enhancing task completion success rates.¶
TaskContext: A structured state object that is created and maintained exclusively by the Master Agent throughout the lifecycle of a complex task. It provides a persistent and machine-interpretable representation of task progress, enabling the Master Agent to manage attention across multiple subtasks and prevent unintended context drift during multi-step execution.¶
AgentContext: The execution state that is specific to an individual agent within a multi-agent workflow. It is strictly isolated between subtasks; during each subtask invocation, only the AgentContext instance corresponding to the target agent is delivered. Upon completion, the corresponding agent returns exclusively its own updated AgentContext.¶
SynchronousContextInteraction: A context sharing mode in which an agent MUST wait for the completion of the current interaction round, including context exchange and result feedback, before proceeding to the next task or interaction. In this mode, context distribution and task execution are strictly ordered, ensuring deterministic task progression and explicit dependency resolution among agents.¶
AsynchronousContextInteraction: A context sharing mode in which an agent MAY exchange contexts with multiple agents concurrently without waiting for the completion of other ongoing interactions. This mode allows parallel context distribution and task execution, enabling higher system throughput and reduced overall execution latency in multi-agent collaborative workflows.¶
Master Agent: The agent responsible for receiving user requests, maintaining the global TaskContext, decomposing complex tasks into subtasks, invoking other agents, and evaluating subtask execution results.¶
Invoked Agent: An agent that is invoked by the Master Agent to execute a specific subtask. An Invoked Agent operates on an isolated AgentContext and returns only its updated execution state to the Master Agent upon completion.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
There are two main scenarios when comes to the context distribution among agents, that is, (1) Context Distribution among Independent Agents and (2) Context Distribution among Collaborative Agents.¶
+-------------+
| Master |
| Agent |
/ +-------------+ \
1 / 1 | 1 \
/ 2 |2 \2
/ | \
+------------+ +-------------+ +------------+
| Agent 1 | | Agent 2 | | Agent 3 |
+------------+ +-------------+ +------------+
(1) Context Distribution among Independent Agents
+-------------+
| Master |
| Agent |
/ +-------------+ \
1 / 3 | 5 \
/ 2 |4 \6
/ | \
+------------+ +-------------+ +------------+
| Agent 1 | | Agent 2 | | Agent 3 |
+------------+ +-------------+ +------------+
(2) Context Distribution among Collaborative Agents
In the first scenario, i.e. Context Distribution among Independent Agents, the agents in the multi-agent system are independent. The Master Agent receives the request, creates a main task and breaks down into several subtasks, and distribute those subtasks to correponding agents. The discover of the correponding agents is out of the scope of this draft. This could be for a tour-plan task, which could involve the agents of hotel-booking, flight-booking, and weather-checking. When the Master Agent receives the tour-plan task, it will break it down into subtasks and distribute context to each agent to accomplish the task.¶
In the second scenario, i.e. Context Distribution among Collaborative Agents, the agents in the multi-agent system are collaborative, that is, the input of the latter agent in a workflow will depend upon the former agent. The Master Agent receives the request, creates a main task and breaks down into several subtasks. It will distribute the subtasks to correponding agents in an order. The discover of the correponding agents is out of the scope of this draft. This could be for a see-a-doctor task, which could involve the agents of disease-diagnosis, prescription, and buy-medicine. When the Master Agent receives the see-a-doctor task, it will break it down into subtasks and distribute context to the first agent, and then depending upon the output of the first agent, the second accomplishes its corresponding tasks, and then the next agent follows the same procedure.¶
+--------------------------------------------------------------+
| Data Layer |
+--------------------------------------------------------------+
| |
| TaskContext AgentContext DeviceContext EnvironmentContext |
| |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| Operation Layer |
+--------------------------------------------------------------+
| |
| SynchronousContextInteraction AsynchronousContextInteraction|
| |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| Transport Layer |
+--------------------------------------------------------------+
| |
| STDIO StreamableHTTP WebSocket SoftBus |
| |
+--------------------------------------------------------------+
We design a structured context interaction format to optimize context exchange in multi-agent systems across several key dimensions.¶
Agent context interaction optimizations are designed across three layers: the data layer, the operation layer, and the transport layer. At the data layer, we introduce structured context formats, including the TaskContext and AgentContext, to precisely capture and represent task and agent states. The detailed design of DeviceContext and EnvironmentContext will be done later. SynchronousContextInteraction and AsynchronousContextInteraction are desined for both scenarios mentioned in Section 3, respecitively. The corresponding transport protocols are designed to support different sceanrios.¶
A fine-grained task management mechanism is defined for both the Master Agent and invoked agents. Clear task progress monitoring and handling procedures are specified, which mitigate attention drift within the model and improve overall task completion success rates.¶
An efficient two-layer task evaluation mechanism is further established. The Master Agent evaluates the outputs of the invoked-agent based on specific fields in the structured context, avoiding the need to process or transmit full-context outputs and thereby reducing excessive token consumption.¶
Support for context offloading is also provided. Both the Master agent and invoked agents are allowed to store or offload full context data to external storage systems, while only structured task descriptions and references to the full context are exchanged. This approach significantly reduces the overall token consumption of the multi-agent system.¶
A context isolation strategy is introduced to ensure that, during collaborative task execution, each agent receives only the context strictly relevant to its assigned task. Relevant context is precisely distributed to the corresponding agent in a well-structured manner, which reduces interference caused by unnecessary or unrelated contextual information.¶
The TaskContext schema defines a structured state object that is created and maintained exclusively by the Master Agent throughout the lifecycle of a complex task. Its purpose is to provide a persistent and machine-interpretable representation of task progress, enabling the Master Agent to manage attention across multiple subtasks and prevent unintended context drift during multi-step execution.¶
"TaskContext": {
"TaskID": "",
"UserQuery": "",
"TaskName": "",
"TaskDescription": "",
"GoalStatus": [
{"Goal": "", "Status": ""},
{"Goal": "", "Status": ""},
{"Goal": "", "Status": ""}
],
"OverallStatus": "",
"StartTime": "",
"EndTime": "",
"Optional": ["StartTime", "EndTime"]
},
The TaskContext schema includes fundamental identification and intent fields such as TaskID, UserQuery, TaskName, and TaskDescription, which collectively capture the origin and semantic scope of the task. The GoalStatus array records the progress of individual goals using explicit {Goal, Status} tuples, allowing the Master Agent to track partial completion and reason over intermediate milestones. An aggregated OverallStatus field reflects the global execution state derived from these goals.¶
Temporal attributes StartTime and EndTime provide optional lifecycle metadata for auditing and scheduling purposes. These fields are listed in the Optional array to indicate that their inclusion is not mandatory for functional correctness and may be omitted to reduce token overhead when time information is not required.¶
By maintaining this structured context, the Master Agent can explicitly steer the model’s focus toward active objectives, mitigate attention fragmentation across turns, and ensure consistent task execution semantics in long-running multi-agent workflows.¶
The AgentContext schema represents the execution state that is specific to an individual agent within a multi-agent workflow. The messages of different agents are strictly isolated between subtasks; during each subtask invocation, only the AgentContext instance corresponding to the target agent is delivered. Likewise, upon completion, the corresponding agent returns exclusively its own updated AgentContext to the Master Agent, without access to contexts belonging to other agents. This design enforces information isolation and prevents unintended cross-agent context contamination.¶
"AgentContext": {
"AgentID": "",
"AgentName": "",
"SubTaskID": "",
"SubTaskName": "",
"Dependencies": [],
"ContextItems": [
{
"ContextID": "",
"ContextType": "document|graph|video|image|audio|code|table|dataset|text|other",
"MediaType": "",
"ContextURI": "",
"Description": "",
"Priority": "must_preserve|compressible|reference_only|discardable"
}
...
],
"CompressionPolicy": {
"Strategy": "target_ratio",
"TargetRatio": 0.3,
"LossTolerance": "low",
"MustPreserveFields": [
"KeyInformation",
"Dependencies",
"ContextItems[].Description"
]
},
"todoItems": [
{"itemID": "", "description": ""},
{"itemID": "", "description": ""},
{"itemID": "", "description": ""}
],
"ItemStateUpdates": [
{"itemID": "", "state": 0},
{"itemID": "", "state": 1},
{"itemID": "", "state": 0}
],
"KeyInformation": [
{"itemID": "", "outputabstract": ""},
{"itemID": "", "outputabstract": ""},
{"itemID": "", "outputabstract": ""}
],
"EvaluationPolicy": {
"SuccessCriteria": [
{
"CriterionID": "",
"Description": "",
"Required": true
}
...
],
"ConfidenceThreshold": 0.8
},
"EvaluationResult": {
"Status": "",
"Confidence": 0,
"CriterionResults": [
{
"CriterionID": "",
"Status": "",
"EvidenceRefs": [],
"TraceRefs": []
}
...
],
"FailureReason": ""
},
"LastUpdated": "",
"Optional": [
"LastUpdated",
"CompressionPolicy"
]
}
The AgentContext schema contains identification fields including AgentID, AgentName, SubTaskID, and SubTaskName, which bind the context to a concrete agent and subtask instance. The Dependencies array expresses prerequisite relations among agents or subtasks, enabling the Master Agent to determine execution ordering and to identify upstream outputs required by the current subtask.¶
The ContextItems array provides a structured representation of the contextual information required by the target agent. Instead of representing the context through a single ContextURI, the context can be divided into multiple independently described context items. Each item is identified by ContextID and includes ContextType, MediaType, ContextURI, Description, and Priority. ContextType provides a semantic classification of the context, such as document, graph, video, image, audio, code, table, dataset, or text, while MediaType further specifies the concrete representation format. Together, ContextType and MediaType enable the receiving agent to select an appropriate tool or processing method for different types of context, reducing unnecessary processing attempts and associated resource consumption. They also allow heterogeneous and multimodal context resources to be represented within a single AgentContext.¶
ContextURI identifies the location from which the corresponding context item can be retrieved. Description provides a concise semantic description of the content referenced by ContextURI, allowing the receiving agent to understand what information the referenced resource contains before accessing it. For example, a Description may indicate that a ContextURI refers to a quarterly sales report, a source-code repository, or a specific segment of a video. Description therefore complements ContextURI by providing human- and agent-readable semantic information about the referenced context.¶
The Priority field specifies how an individual ContextItem should be treated when the receiving Server Agent performs local context compression. A value of must_preserve indicates that the item should be retained without semantic compression; compressible allows semantic reduction while preserving task-relevant information; reference_only allows the content to be omitted while retaining its reference and description; and discardable permits the item to be removed when necessary. Priority therefore defines the permitted reduction level of each ContextItem during the receiving Server Agent's local context processing.¶
The CompressionPolicy specifies the overall compression strategy that the receiving agent should apply during local processing of the received AgentContext. Strategy specifies the compression method, TargetRatio defines the intended overall compression ratio, LossTolerance specifies the acceptable degree of semantic information loss, and MustPreserveFields identifies fields that should remain available after compression. TargetRatio is treated as a target rather than a strict requirement when preservation constraints prevent further reduction.¶
CompressionPolicy and ContextItems.Priority operate at different levels. CompressionPolicy defines the overall compression objective for an AgentContext, whereas Priority constrains how each individual context item may be reduced. Item-level preservation constraints take precedence over the global compression target. Consequently, an implementation may produce a compressed context whose actual size exceeds TargetRatio when further compression would violate Priority or MustPreserveFields constraints.¶
Task execution is modelled through three coordinated structures. The todoItems array enumerates actionable steps assigned to the agent. The ItemStateUpdates array records the completion state of each item using a binary code where 0 denotes not completed and 1 denotes completed. The KeyInformation array provides concise output abstracts generated by the agent for each item, capturing the task-relevant information required by the Master Agent for subsequent reasoning and result validation.¶
The EvaluationPolicy specifies the evaluation requirements associated with the current subtask. SuccessCriteria defines one or more conditions against which the produced result can be assessed. Each criterion is identified by CriterionID and described by Description. The Required field indicates whether satisfaction of the corresponding criterion is mandatory for successful completion of the subtask. ConfidenceThreshold specifies the minimum confidence expected for an acceptable evaluation result.¶
The EvaluationResult records the structured evaluation produced for the subtask. Status represents the overall evaluation status and Confidence expresses the associated confidence value. CriterionResults provides criterion-level evaluation results and associates each result with the corresponding CriterionID. EvidenceRefs may reference contextual evidence supporting the evaluation, while TraceRefs may reference execution traces associated with the result. FailureReason provides additional information when the evaluation does not satisfy the defined policy.¶
EvaluationPolicy and EvaluationResult represent different phases of the subtask lifecycle. EvaluationPolicy is delivered as part of the AgentContext before execution and specifies the conditions under which the subtask result is expected to be considered acceptable. EvaluationResult is populated after execution and returned with the updated AgentContext. The Master Agent may use the returned EvaluationResult together with ItemStateUpdates and KeyInformation to perform its own final assessment before updating TaskContext.¶
After receiving the updated AgentContext, the Master Agent therefore evaluates subtask completion using both execution-state information and semantic result information. ItemStateUpdates provides a preliminary indication of whether the assigned work has been completed, while KeyInformation and EvaluationResult provide the information required for semantic validation against the original task objective and evaluation requirements. The Master Agent retains authority over the final task-level decision and over subsequent updates to TaskContext.¶
The optional field LastUpdated records the timestamp of the most recent modification and is listed in the Optional array to indicate that its inclusion is not required for functional correctness.¶
+------+ User Query+ +------+ +------+ +------+
| | System Prompt | | | | | |
| <-----------------+ | | | | |
| | TaskContext | | | | | |
| +-----------------> | | | | |
| | | | | | | |
| | TaskContext+ | | | | | |
| | System Prompt | | | | | |
| <-----------------+ | | | | |
|Master| AgentContext | ACI | Send | ACI | |Server|
|Agent +----------------->Client| AgentContext |Server| |Agent |
| | | +----------------> | | |
| | | | | |ContextItems+ |
| | | | | |todoItems | |
| | | | | +-----------> |
| | | | | |Compression |
| | | | | |Policy | |
| | | | | +-----------> |
| | | | | |Evaluation |
| | | | | |Policy | |
| | | | | +-----------> |
| | | | | | | |
| | | | | | Results | |
| | | | return | <-----------+ |
| | | | AgentContext | | | |
| |ItemStateUpdates+| <----------------+ | | |
| |KeyInformation+ | | | | | |
| |EvaluationResult | | | | | |
| <-----------------+ | | | | |
| | | | | | | |
| | Evaluation | | | | | |
| | Outputs | | | | | |
| +-----------------> | | | | |
| | | +---+ | | | |
| | | | | | | | |
| | | <---+ | | | |
+------+ +------+ Updated +------+ +------+
TaskContext
Figure 5 illustrates the interaction flow of the proposed Agent Context Interaction (ACI) optimizations. The workflow begins when the Master Agent receives the user query and system prompt, constructs the TaskContext, and generates an AgentContext for the selected subtask.¶
The ACI Client and ACI Server are conceptual entities representing the logical communication path between the Master Agent and the invoked Server Agent. In practice, they may be implemented using existing agent communication mechanisms, such as an Agent2Agent (A2A) client and server.¶
The Master Agent sends the AgentContext to the Server Agent through the ACI Client and ACI Server. The ACI Server delivers ContextItems together with todoItems to provide the contextual information and execution requirements of the subtask. CompressionPolicy specifies the local context compression strategy to be followed by the receiving Server Agent, while EvaluationPolicy defines the criteria and confidence requirements used to evaluate the subtask result.¶
After executing the subtask, the Server Agent returns the execution results to the ACI Server. The updated AgentContext, including ItemStateUpdates, KeyInformation, and EvaluationResult, is then returned to the Master Agent. ItemStateUpdates represents execution status, KeyInformation provides the task-relevant output, and EvaluationResult records the Server Agent's evaluation against the received EvaluationPolicy.¶
The Master Agent further evaluates the returned AgentContext and produces its own Evaluation Outputs before updating the global TaskContext. Based on the updated TaskContext, the Master Agent can determine whether the current subtask is complete and schedule subsequent agent interactions. This process enables structured context delivery, controlled local context processing, and layered task evaluation in multi-agent collaboration.¶
By explicitly specifying the context type, format, and content reference, the receiving Server Agent can select appropriate tools and processing methods, reducing ineffective attempts, repeated parsing, and unnecessary token consumption.¶
By defining the compression strategy, target ratio, loss tolerance, and fields that must be preserved, the protocol provides consistent constraints for how the receiving Server Agent compresses shared context, thereby reducing the risk of losing critical information.¶
By specifying success criteria and confidence requirements when a task is assigned, the receiving Server Agent can execute the task against a consistent evaluation objective, while structured evaluation results help the Master Agent determine whether the task has been successfully completed.¶
Agent Context Interaction Optimazation defines structured context exchange mechanisms among cooperating agents. While we do not introduce a new transport protocol, improper handling of context data may lead to security and privacy risks.¶
AgentContext messages may contain sensitive information, including user queries, intermediate reasoning artifacts, task metadata, and execution results. Implementations MUST ensure confidentiality and integrity of AgentContext messages by relying on secure underlying transport mechanisms, such as TLS-protected channels, and appropriate authentication and access control between agents.¶
The protocol promotes context isolation by design, where each agent receives only the context strictly required for its assigned task. Failure to enforce this isolation may result in unintended information disclosure or cross-task data leakage.¶
This document does not define agent identity formats or trust establishment procedures. Deployments are expected to rely on out-of-band mechanisms for agent authentication, authorization, and trust management.¶
The use of the ContextURI field introduces an indirection mechanism for accessing external or offloaded context data. While this approach reduces token consumption by avoiding the transmission of large artifacts, it also introduces additional security considerations related to pointer integrity and distributed state management.¶
Implementations MUST ensure the integrity and authenticity of ContextURI references. A malicious or tampered ContextURI could redirect an invoked agent to unauthorized resources or cause the retrieval of manipulated context data. Appropriate protections, such as signed references, authenticated storage endpoints, or secure capability-based access mechanisms, SHOULD be employed to ensure that only trusted agents can resolve and access the referenced context.¶
The lifecycle management of ContextURI references SHOULD also be carefully controlled. Storage systems that host offloaded context data SHOULD enforce explicit expiration policies (e.g., time-to-live or TTL) to prevent long-term persistence of sensitive information. Access to such storage endpoints MUST require appropriate authentication and authorization to ensure that only the intended invoked agents can retrieve the referenced context.¶
Deployments MUST further consider data residency and privacy implications when ContextURI references point to storage systems containing user-related information, such as UserQuery or intermediate task artifacts. Operators SHOULD ensure that storage locations comply with applicable data protection policies and that sensitive context data is protected both in transit and at rest.¶
The Master Agent and the storage endpoint referenced by ContextURI are required to operate within a trusted relationship. The Master Agent MUST ensure that the storage service providing context data enforces adequate security controls and maintains the integrity and availability of the stored context. Failure to ensure this trust relationship may result in context poisoning, data tampering, or unauthorized disclosure of task-related information.¶
This document does not require any immediate actions by IANA. Future extensions of the protocol may define registries or code points that require IANA assignment.¶
We would like to thank Yiyang Shao, Jinyang Li, Tao Liu, James Kunle Olorundare, Ujjwal Upadhyay, Zhuoran Ma, Muhammad Awais Jadoon and Muntaser Syed for useful discussion and ideas.¶
Yiyang Shao Huawei China Email: shaoyiyang@huawei.com Tao Liu Huawei China Email: liutao417@huawei.com Jinyang Li Huawei China Email: lijinyang9@huawei.com