Skip to main content
In Key Concepts, you saw how Bindu’s task states enable interactive conversations. Now let’s understand why Bindu uses a Task-First architecture and how it powers multi-agent orchestration. Quick Recap: Every message creates a task that flows through states (submitted → working → input-required → completed). This pattern explains why tasks aren’t just for tracking—they’re what make parallel agent execution and complex workflows possible.

​
Why Task-First?

The Problem: Orchestrators like Sapthami need to coordinate multiple agents working on different parts of a complex workflow. How do you track which agent is doing what? How do you run tasks in parallel? How do you manage dependencies? The Solution: Task IDs. Every interaction creates a trackable task with:
  • Unique Task ID - Track work across multiple agents
  • Clear State - Know if task is working, needs input, or completed
  • Explicit Dependencies - Use referenceTaskIds to chain tasks
  • Parallel Execution - Multiple tasks can run simultaneously
This aligns with the A2A “Task-only Agent” pattern where all responses are Task objects, enabling orchestration at scale.

​
Real-World Example: Travel Planning

Imagine an orchestrator coordinating a trip to Helsinki: 
Task1 → WeatherAgent: "Check Helsinki weather next week"
  └─ Returns: weather-data.json

Task2 → FlightAgent: "Book flight" (references Task1)
  └─ Asks: "How many travelers?"
  └─ State: input-required

Task3 → HotelAgent: "Find hotel" (runs in parallel with Task2)
  └─ Returns: hotel-booking.pdf

Task4 → ItineraryAgent: "Create itinerary" (waits for Task2 & Task3)
  └─ referenceTaskIds: [Task2, Task3]
  └─ Returns: complete-itinerary.pdf
Without Task IDs: The orchestrator couldn’t track which agent is doing what, couldn’t run Task2 and Task3 in parallel, and couldn’t tell Task4 to wait for the others. With Task IDs: Clear tracking, parallel execution, explicit dependencies. That’s the power of Task-First.

​
Messages vs Artifacts

AspectMessagesArtifacts
PurposeInteraction, negotiation, status updates, explanationsFinal deliverable, task output
Task Stateworking, input-required, auth-required, completed, failedcompleted only
When UsedDuring task execution AND at completionWhen task completes successfully
ImmutabilityTask still mutable (non-terminal) or immutable (terminal)Task becomes immutable
ContentAgent’s response text, explanations, error messagesStructured deliverable (files, data)
Key Distinction:
  • Intermediate states (input-required, auth-required): Message ONLY, no artifacts
  • Completed state: Message (explanation) + Artifact (deliverable)
  • Failed state: Message (error explanation) ONLY, no artifacts
  • Canceled state: State change only, no new content

​
Key Implementation Rules

​
Task States

Non-Terminal (Task Open):
  • submitted → working → input-required → auth-required
Terminal (Task Immutable):
  • completed, failed, canceled, rejected

​
A2A Protocol Compliance

Task Immutability - Terminal tasks cannot restart; refinements create new tasks
Context Continuity - Multiple tasks share contextId for conversation history
Parallel Execution - Tasks run independently, tracked by unique IDs
Dependency Management - Use referenceTaskIds to chain tasks