Agents over A2A

The job

You have built a specialist agent that reviews changes or investigates incidents. An agent in another application needs to delegate work to it. The caller needs to discover the specialist, send a task, check its progress, and supply input when the task pauses. Completion means a returned result the calling application can use, even if the work outlives either client’s initial connection.

Ironflow’s A2A adapter exposes an agent through the Agent2Agent protocol. One A2A task maps to one Ironflow run. The agent’s worker and the adapter are separate processes; durable execution state lives in the engine.

The flow

A remote agent discovers the Agent Card and sends a review request. The specialist gathers evidence and calls its model through durable steps. It may pause at an approval gate that the operator has explicitly opened to callers. The caller supplies structured input, and the agent finishes the task.

Callers can get or list tasks, follow task-state updates, and cancel a run. A long task can return as working while the caller follows it separately. Your application defines the agent’s reasoning, model access, and useful result.

The difficult moment

The adapter restarts while the agent is waiting for input. The task remains a run in Ironflow. The caller can reconnect and retrieve it. If the worker crashes, the run can resume using completed step results. An unfinished external action still needs its own idempotency strategy.

Distinguish cancelling the task from undoing external effects. A booking or payment agent needs application-defined cleanup; cancellation does not invoke saga compensations automatically.

Ironflow’s role

The adapter handles protocol discovery and task operations. Agent APIs provide durable tool/model calls and approval waits. The operator chooses which gates a remote caller may answer. A gate reserved for staff stays hidden from callers.

The current adapter uses one shared caller token, so callers of the same exposed agent can see each other’s adapter-started tasks. Design the deployment boundary accordingly. Task-state streaming reports the run’s state; model-token streaming and A2A push notifications are outside the adapter’s current capabilities.

Implementation sketch

This is an illustrative flow:

1. Write an agent that accepts the adapter’s message input.
2. Wrap evidence gathering and model calls in durable steps.
3. Start the A2A adapter for the agent’s function ID.
4. Explicitly expose any approval gates callers may answer.
5. Let callers follow the task and retrieve its completed result.

Starting point

• Expose an agent over A2A provides the agent input shape, adapter setup, caller-input configuration, and deployment limits.
• A2A CLI reference lists the command flags.
• Survive a crash demonstrates the underlying agent recovery behavior with simulated document-processing tools.