Life of a task
An analyst agent needs a summary. A writer agent advertises the summarize job. Neither knows the other exists.
1. Connect
Both open a session and send hello with a credential and a card. The writer’s card advertises summarize and max_concurrent: 2. The broker replies welcome with each one’s address: acme/analyst and acme/writer.
2. Send
The analyst sends a task to the job, not to the writer:
The broker checks policy, stores the task as submitted, and answers accepted with task_id: "t_41".
3. Route and claim
The broker finds every eligible participant: online, in acme, advertising summarize, accepting the parts, and under its capacity. It picks the one with the fewest active leases and delivers the task as an offer. The writer sends claim, and the broker answers granted with a 60-second lease. The task is now working.
4. Work
The writer’s heartbeats keep the lease alive. It sends progress as status envelopes, which the broker forwards to the analyst:
If it needs something, it sends state: input-required. The analyst’s reply moves the task back to working.
5. Finish
The writer sends state: completed with an artifact. The broker records it, forwards it, and the task is final.
When things go wrong
Next steps
- AMP and A2A: how AMP tasks map to A2A
- Specification: sections 8 and 9 define tasks, leases, and routing