Agent Coordination & Customer Interaction
Customer Benefit: Agents coordinate a job between them, and hand your customer the result as an interface they can act on.
Overview
Complex workflows require more than a single prompt-response turn. Specialised agents must divide tasks, verify intermediary steps, and hand the final outcome to human customers in an actionable form.
Siliqun Rotor defines two complementary layers for multi-agent workflows:
- A2A (Agent-to-Agent): The protocol for autonomous peer agents to exchange tasks, tools, and evidence.
- Agent-to-customer interaction: The contract for presenting agent outcomes directly to human users as working interfaces they can verify and act upon.
1. A2A: Agent-to-Agent Coordination
Available today:
- Inside one project: a flow in the Flow Designer joins several steps, each with its own tools, into one run. Every step is recorded in the run's trace, and a step that needs a person stops the run until they answer.
- Across processes, over A2A 1.0: another organisation's agent can send your hosted project a request in words and get back a task with the decision. Each project is served as an A2A agent:
- Agent Card:
GET /a2a/p/{project}/.well-known/agent-card.json. Its skills are your project's imported API tools, each tagged read or act. - Requests:
POST /a2a/p/{project} with the JSON-RPC method SendMessage. - Access: both take the project's API key, the same key the MCP gateway accepts.
- A signed card: when the Siliqun Rotor operator signing key is provisioned, the Agent Card carries an A2A 1.0 signature, so the other agent can check that the card is unaltered and comes from this service. The public key is at
GET /a2a/.well-known/jwks.json. - What the other agent gets back:
- A decided read is carried out, and its result is returned as a completed task.
- A missing detail comes back as input required, with the detail named.
- A request that fits nothing is rejected, with the reason.
- An action (a write) is never carried out over A2A. It comes back as input required with "confirmation required". To carry it out, use the MCP gateway (ask, then confirm).
Not yet:
- Sign-in grants on A2A. Today it takes project keys only; a connection's sign-in grant is limited to the MCP gateway.
- Further A2A methods. Streaming, task lookup and continuing a task in a later message are not available yet.
- Answering or confirming over A2A. Both still go through the MCP gateway (
answer, confirm).
2. Agent-to-Customer Interaction
Most agent systems fail at the handoff to the human user: they dump an unstructured block of text into a chat box. The human must read through paragraphs, manually copy identifiers, and switch to another system to approve or execute changes.
Agent-to-customer interaction solves this with four core principles:
- Native Interactive Interfaces: The agent delivers Decisions and Answers as MVG controls (interactive charts, searchable tables, choice buttons) rendered inside your application's native design system.
- Deterministic Resumption: Every customer action (selecting a row, clicking a choice, adjusting a filter) returns as a typed event that resumes the same workflow run.
- Write Confirmations: State-modifying actions require the person's confirmation before execution.
- Transparent Evidence: The customer sees why a decision was reached (
why and source evidence offsets) before committing an action.
Try It in Studio
- Flow Designer: Build a multi-step flow and inspect each step at Flow Designer.
- Agent Harness: Test agent interactions and inspect live decision traces at Agent Harness.