Skip to main content
Contexts serve as conversation containers in the Bindu protocol, managing the complete interaction lifecycle between clients and agents. They maintain conversation continuity, preserve context across multiple tasks, and provide session-level organization.
Context is a Bindu-specific extension <NotPartOfA2A> that goes beyond the standard A2A protocol to enable sophisticated conversation management and session tracking.

Context Object

A Context is a conversation session that groups related tasks and maintains interaction history. It provides the organizational structure for multi-turn conversations and enables agents to maintain state across multiple task executions. Schema:
Realistic Example: Multi-Task Analysis Context A client engages in a multi-turn conversation about market analysis:
What This Example Shows:
  • Context Identity: Unique contextId for tracking the conversation
  • Session Organization: Groups 3 related tasks under one conversation
  • Temporal Tracking: Creation and update timestamps
  • Status Management: Active status indicates ongoing work
  • Metadata Context: Business context like department, priority, and stakeholders
  • Categorization: Tags for filtering and organization
Context vs Task:
  • Context = The conversation session (container)
  • Task = Individual work units within the conversation
  • One context can contain many tasks
  • Tasks inherit context from their parent context

Context Status States

Contexts can be in one of four states: Active States:
  • active - Context is currently in use
    • New tasks can be added
    • Conversation is ongoing
    • Default state for new contexts
  • paused - Context is temporarily suspended
    • No new tasks should be created
    • Existing tasks may continue
    • Can be resumed to active state
Terminal States:
  • completed - Context has finished its purpose
    • All tasks are completed
    • No new tasks should be added
    • Context is considered closed
  • archived - Context is stored for historical reference
    • Preserved for audit or review
    • Read-only access
    • Cannot be modified or resumed
State Transition Diagram:

Context Operations & Parameters

Parameters used for various context operations including creation, querying, and management.

ContextIdParams

Simple parameters containing a context ID. Used internally whenever an operation needs to identify a single context (for example, as the base type extended by ContextQueryParams and ContextsClearParams). Schema:

ContextQueryParams

Extends ContextIdParams with a history_length cap — a future building block for single-context retrieval. The currently exposed RPC for listing contexts is contexts/list; see its params below. Schema:

ListContextsParams

Parameters for listing multiple contexts with optional history limiting. Schema:
Example: List Active Contexts
Response:
Use Cases:
  • Dashboard views showing active conversations
  • Context management interfaces
  • Session monitoring and analytics
  • Filtering contexts by status, role, or tags
  • Pagination with history control
  • Finding contexts by criteria
Common Filtering Patterns: By Status:
By Tags:
By Date Range:
With Pagination:

Context Best Practices

Context Decision Flow: Lifecycle States: Quick Tips:
  • Naming: Use format "Project - Purpose" (e.g., “Q4 Sales - Analysis”, “Support - Ticket #1234”)
  • Metadata: Store business context, ownership, timestamps for filtering and tracking
  • Performance: Use historyLength parameter to limit payload size when fetching contexts
  • Cleanup: Regularly archive completed contexts to maintain system performance