Tasks and completion

A message/send produces a task. tasks/get reads it later and tasks/cancel aborts one that is still running. Tasks are kept in a bounded buffer.

The important distinction is rejected vs failed:

rejected means the runtime declined to start the requested operation. failed means the operation was accepted but did not successfully complete. A client can make different retry or fallback decisions from that distinction.

A capability without a completion contract is complete at validated dispatch. A capability with one stays in flight until its correlated success/failure Message, timeout, or cancellation settles the task.

What is deliberately not implemented#

The adapter advertises only the A2A features it actually supports:

• streaming: false
• pushNotifications: false
• message/stream is refused
• multi-turn input-required / auth-required flows are out of scope
• file parts and artifacts are out of scope

It is better for the card to describe a smaller truthful surface than to expose protocol features the underlying application adapter does not implement.

Choosing an adapter#

All four adapters serve the same AssistantAgent contract through a bound runtime.

See also#

• Agents guide — builder → contract → runtime and the authority model.
• foldkit-agent — the protocol-neutral contract and runtime.
• examples/todo — a focused contract served through adapters.