"Multi-agent" is the most over-claimed phrase in this category. In most products it means a table of agent records and a message row that nothing ever picks up. Botmanor's delegation path invokes the target agent: it runs that agent's own turn, with that agent's model binding, its knowledge bases and its tools, and returns the real response to the caller — recording the whole exchange on the message record so the hand-off is auditable rather than inferred.
There are two ways in, and they share one runtime. A delegation can be requested explicitly through the API — "send this task to that agent" — or it can be requested by a model mid-conversation, because an agent's outbound peers are exposed to it as delegate pseudo-tools. Either way the same service executes it, which means the bounds and the audit trail are identical no matter who initiated the hand-off.
The bounds are the part that makes this safe to switch on. Delegation depth is capped, so a chain of agents asking each other for help terminates instead of recursing until something times out. Cycles are rejected outright: an agent already present in the active delegation chain cannot be delegated to again, so A→B→A fails fast with a clear error rather than looping. And the model is only offered the delegate tool while depth budget remains, so the loop is bounded before the model can even ask.
Trust is enforced, not assumed. Agent-to-agent connections and messages pass the workspace's tool policies, which can require a minimum trust level — unverified, verified publisher, or internal — before a connection is created or a message is sent. A workspace that only wants its own agents talking to each other can say so once, as policy, instead of relying on everybody remembering.
Honest boundaries, clearly drawn. Delegation resolves the target agent inside the caller's own workspace — cross-workspace delegation is deliberately out of scope for this pass, because it would cross a tenancy line that Botmanor does not cross casually. Like the tool loop, delegation runs on the OpenAI-wire provider path today. And the external side of the agent-to-agent story — the registry of third-party agents, their agent cards and their published skills — is a catalog you can maintain now, with live external invocation following the same path as the internal runtime.
Today agent-to-agent delegation runs in the execution layer for OpenAI-wire providers, but creating outbound A2A connections is API-only in the current UI. Because a real user cannot complete the full story by clicking through the web app alone, this page is presented as a narrative pattern rather than a clickable "Do it yourself" section.
Ready to make this your story?
