Skip to main content
Metadata

Overview

The Context extension provides one caller-scoped conversation-history contract with three operations over JSON-RPC and HTTP+JSON: All three methods belong to the same extension and use the same canonical URI. An Aion-served agent card declares the extension once. HTTP+JSON paths below are relative to the addressed agent or distribution’s A2A endpoint.

Agent Card Declaration

This unified contract is provided by Aion control-plane endpoints. The Python SDK’s standard agent server does not advertise this extension or implement its summaries and DeleteContext lifecycle. Its internal, non-advertised GetContext and GetContexts helpers have a separate read-only contract. A server should declare the unified URI only when it implements the contract documented here.

Activation

This extension is declarative. It will always be active and does not require activation. Clients do not need to send the URI in A2A-Extensions or a2a-extensions. When a client does send it, the server preserves it as ordinary request extension metadata.

Authentication and Isolation

Contexts belong to the receiving AgentIdentity within the addressed edge agent environment. Separate bindings associate admitted callers by exact principal identifier and type. Ordinary caller reads use those bindings and return the complete visible context history, including other admitted participants. Knowing a contextId or belonging to the same organization is not authorization to join it. Verified provider participants can share a provider conversation. Account and guest clients cannot join an occupied private context simply by supplying its ID. New roots receive a private downstream identifier instead of blindly forwarding an untrusted caller-provided string. A verified anonymous-session bearer identifies one guest and can authorize its bound contexts on public A2A endpoints. A bare shared anonymous principal cannot. Session access does not make a private distribution or the authenticated GraphQL catalog public. See Caller Authentication for creation, renewal, and token boundaries. Binding writes are best effort and do not delay message forwarding. Failed writes can leave history unavailable until a later authorized message repairs access; there is no guaranteed durable retry. Provider room departures and membership revocations are not yet synchronized. An explicitly authorized receiving-agent history request is distinct from ordinary caller access; it does not allow every caller to read all conversations owned by that agent.

GetContexts

GetContexts returns lightweight caller-visible conversations from most to least recent.

JSON-RPC Request

params may be omitted to use the defaults.

JSON-RPC Success

The result is a raw array rather than an object wrapper. lastActivityAt uses the latest persisted task update. If an admitted edge task does not yet have a local task projection, its creation time is used.

HTTP+JSON Binding

The request body uses the same parameter object. The response body is the same raw summary array.

GetContext

GetContext returns one caller-visible context. History is chronological; pagination selects a newest-relative slice before the server returns it in chronological order.

JSON-RPC Request

JSON-RPC Success

The result combines messages across the context’s tasks; it is not an array of complete tasks. Artifact selection is independent of message pagination. Each artifact has the usual A2A artifact fields plus taskId, the caller-facing task identifier:
Artifact identity is the pair (taskId, artifactId). Two tasks can both return an artifact named report. Aion selects at most 50 artifacts before loading their parts, orders them by latest update with a stable row-id tie break, and excludes aion:thinking-delta and aion:stream-delta. This is a recent-artifact window, not an exhaustive artifact export or a bound on individual artifact bytes. If the caller has no visible projection for contextId, the server returns ContextNotFound (code 1000, HTTP 404) without revealing whether another caller uses that identifier.

HTTP+JSON Binding

The request and response bodies use the same parameter and result objects shown above.

Generated Context Summaries

title and summary are optional generated metadata. They are nullable because generation is best effort and controlled by the organization that owns the addressed agent. When that organization disables conversational summarization, both fields are returned as null even if a previously generated value remains stored. Generation may send bounded conversation text to an external model service. Organizations that must keep conversational information within their own network should leave conversational summarization disabled. Clients must not assume that generated values exist or that they include the newest task. Aion first attempts generation after the caller’s first completed task, then after each additional ten-task checkpoint. The title reflects the latest summarized task window. The summary combines the previous generated summary with that bounded window, so the full conversation does not need to be sent again as the context grows. Generation and catch-up are asynchronous. A failed attempt leaves the previous values unchanged, and a later terminal task can cause Aion to catch up one checkpoint at a time. Context reads never wait for this work.

DeleteContext

DeleteContext first removes the requesting caller’s binding. If other recorded bindings remain, it returns success without canceling tasks or deleting the graph. The receiving-agent owner field is not itself a binding; a genuine agent self-call can have a binding like any other caller. When the last recorded binding is removed, Aion records a durable DELETING state, which prevents new task admission. Existing tasks can still publish observations so cancellation and completion can settle. Final deletion prevents subsequent payload projection from recreating the retired history. Cancellation uses the ordinary A2A task-control path. Cancellation proceeds in bounded groups and checks task state when the outcome is uncertain. For last-binding deletion, success is returned only after all tasks are terminal and the graph-deletion transaction commits. A task may also complete naturally while cancellation is being attempted. Terminal states are:
  • TASK_STATE_COMPLETED
  • TASK_STATE_FAILED
  • TASK_STATE_CANCELLED
  • TASK_STATE_REJECTED

JSON-RPC Request

JSON-RPC Success

Deletion is idempotent. The server returns the same success for a context that is already absent or not visible to the caller. This avoids disclosing another caller’s context.

Deletion In Progress

An outstanding cancellation, transient failure, or request timeout does not imply deletion success or permanent failure. Once deletion is durable, Aion keeps the context fenced, returns this retryable result, and can recover the operation after a restart. Retry DeleteContext with the same caller and context id; do not create a replacement task in that context while it is deleting. deletionOperationId is optional diagnostic metadata, not an additional request parameter. If cancellation is definitively refused, Aion drains the outstanding attempts before restoring the context to ACTIVE and returning non-retryable ContextNotDeletable (code 1002). Work already canceled is not restarted or rolled back. An active task alone is not a definitive refusal. The removed caller binding is not silently restored; stale grant retries cannot re-admit it.

HTTP+JSON Binding

The request body is the DeleteContext parameter object. The success body is {"contextId":"conversation-123"}. Lifecycle conflicts use HTTP 409 Conflict problem details, with the same context id, retryability, and optional deletion-operation id as JSON-RPC.

Deletion Scope

Only last-binding finalization soft-deletes the receiving-agent edge context, its bindings, edge-task mappings, linked local native and projected tasks, messages, artifacts, parts, callback routes, and owned push notification configurations. Task traces and referenced Files are not soft-deleted by this action. It does not:
  • remove another caller’s recorded binding through an ordinary caller-delete request;
  • send a context-deletion command to a remote agent;
  • claim that a remote agent erased its own conversation memory; or
  • prevent a later request from reusing the same contextId.
Clients should treat success as confirmation that the caller’s current Aion history is no longer available through GetContexts or GetContext. If another recorded binding remains, the context still exists and a private caller cannot rejoin merely by sending its ID. After actual graph deletion, a later send using that caller-facing ID creates a new mapping with a fresh downstream identifier, not a continuation of the retired graph. Because grant recording is best effort, an unrecorded participant may still be using a context when the last recorded binding is removed. The graph can then be deleted. This accepted limitation is not a guarantee that every currently active participant appears in the binding table.

Retention And Files

Background retention removes complete context graphs, not individual expired task siblings. For an active context, recent activity or nonterminal work in any linked task protects the whole graph. An explicitly deleted context instead ages from its deletion timestamp. Each eligible context is rechecked and physically purged in its own transaction, including payload children, callback routes, task traces, task roots, and the context mapping. This removes Aion’s stored native and downstream-projection history, not an external server’s retained data. After that commit, Aion requests best-effort deletion of locally managed Files owned by the graph’s organization. A surviving reference, including one in another soft-deleted context, preserves the File. Remote and cross-organization File references do not authorize automatic deletion. File storage billing continues until the File service performs its normal lifecycle deletion; hiding conversation history alone does not stop File billing.

Errors

Context lifecycle errors carry sanitized contextId and retryable fields in JSON-RPC error.data. The HTTP+JSON binding exposes them as problem-detail extensions. Its problem type is the canonical Context extension URI followed by #context-not-found, #context-deletion-in-progress, or #context-not-deletable, respectively. Provider error payloads and internal row identifiers are not included. Error objects otherwise follow the JSON-RPC 2.0 specification.