Adding a second agent is a communication design problem before it is a model problem. The new agent has to be findable, it has to carry a stable identity, and it has to share a message format with the agents already running. Miss those and, I would expect, the split fails in ordinary ways: the wrong peer gets called, a skill list cannot be checked, or two frameworks leave a trace you cannot reconstruct.
Giovanna Carofiglio, Distinguished Engineer and Senior Director at Outshift by Cisco, is working on that layer in the open. On Chain of Thought she described the AGNTCY Collective, an open source effort Cisco, LangChain, and other companies launched in March 2025, so agents built with different frameworks and deployed remotely can still collaborate. I would use her interoperability questions as a gate. If you cannot fill in discovery, identity, and message format on paper, keep the work in one agent.
How will agents find each other?
Carofiglio expects specialized agents, closer to subject matter experts than to one general worker: a domain, a task, or an attachment to tools. Those agents only compose if a caller can search for them. The collective's discovery service, which she said had just launched, searches by skills, by publisher, by compatibility with given tools, and by reputation.
Write those four fields for every agent you might add. If the only address is a URL in a config file, you have pinned a dependency. You have not designed discovery.
She also separates finding an agent from copying it into your process. Once located, an agent can stay where it runs and be called as a service. That is the common case she describes, so discovery has to work across a network, not only inside one repository.
Who is this agent, and who stands behind it?
A search result is useless if you cannot tell what you found. The collective released an agent identity component and a schema for describing agents. Carofiglio compares the goal to OCSF, the Open Cybersecurity Schema Framework, which became a common language for cybersecurity data. She wants a first version of what defines an agent, because that definition is still easy to argue with. The properties she wants are concrete: a unique identity, clear provenance for the agent and for its data, and skills spelled out so the same record supports discovery, evaluation, and a reputation on those skills. Tasks need identifiers too, not only agents.
I would refuse a peer that cannot say who published it and which skills it claims. This is an AI alignment problem as well as a directory problem. Alignment is whether behavior matches the goals and constraints you intended. For one deployed agent, write the actions it may take, how you will evaluate responses, and when a person must review a decision. Guardrails and evaluation help you test and constrain that behavior. They do not, on their own, settle alignment. A second agent that advertises skills it lacks, or that takes a task you never identified, breaks the same contract in the gap between agents.
Which protocol is allowed to say what?
Carofiglio's protocol advice matches what I would tell a team. With protocols in general, several attempts usually chase the same job before a few become the reference. She sees that happening now, and the collective's plan is to support the protocols developers already have, while staying explicit about the job each one does.
MCP is for agent-to-tool interaction. It matters when tools are remote and not built into the agent. She expects it to spread earlier because it is simpler: agents call tools, and tools can offer an API-like surface behind MCP servers.
Agent-to-agent communication is harder. ACP is a protocol the collective worked on with LangChain as an extension of agent protocols. A2A is a recent proposal from Google, and she notes there are others. Declaring a single winner now is guesswork. What you can write down today is a rule: tool traffic uses one named protocol, peer traffic uses another, and a lower transport should be able to carry more than one peer protocol.
Their transport design is Slim, announced shortly before that conversation. It is meant to be group-based, low latency, and secure, and she said it is going to be data-centric rather than connecting points to points. She wants that shape because a natural language question often brings several agents with different skills together to combine outputs. A single point-to-point link does not match that, and without low latency she calls the pattern unusable. Security belongs in the same design: secure from the start, then, inside an enterprise, connections that still hold under zero trust.
Above the transport, the messages you debug need one schema. The collective is extending OpenTelemetry so agents can be instrumented and so metrics, events, logs, and traces can be tied back together when agents ship inside ordinary applications and come from different frameworks. She said an SDK for that schema had been released two days before the recording. A shared shape like that is what lets you see how data passed or which tool was called across frameworks.
A small sketch of the gate, not a protocol and not something the collective ships:
# Sketch only. A pre-split check, not a runtime or a vendor SDK.
def interoperability_gaps(spec: dict) -> list[str]:
gaps = []
for field in ("skills", "publisher", "tool_compatibility", "reputation"):
if not spec.get(field):
gaps.append(f"discovery missing {field}")
for field in ("agent_id", "provenance", "task_id"):
if not spec.get(field):
gaps.append(f"identity missing {field}")
if spec.get("calls_remote_tools") and spec.get("tool_protocol") != "mcp":
gaps.append("name an agent-to-tool protocol")
if spec.get("talks_to_agents") and not spec.get("peer_protocol"):
gaps.append("name an agent-to-agent protocol")
if spec.get("talks_to_agents") and spec.get("transport") != "group":
gaps.append("group transport for multi-peer calls")
if not spec.get("telemetry_schema"):
gaps.append("shared schema for metrics, events, logs, traces")
return gaps
What do you add when the group gets large?
A few agents can hide a sloppy contract. An agent swarm will not. AMD's Anush Elangovan describes swarms as a step change from single-agent systems: once tens or hundreds of agents coordinate, the dynamics resemble a pack more than an individual actor. My conclusion is that a multi-agent system needs its own alignment and security work.
Carofiglio puts the same pressure in three engineering requirements. Connectivity has to scale, which is why Slim is planned as data-centric. Security has to scale, and it starts at identity, then secure connection, including zero trust for agents inside an enterprise. Observability and evaluation have to scale with both. She wants a few metrics that capture how a multi-agent system actually behaves, because a long list confuses the people reading it. She wants that evaluation cheap enough to sit inside development, since it can otherwise turn into a long job of models and dataset creation. The move she is most interested in is active evaluation: score the run, quantify how much improvement is available, and recommend changes to the person composing the application or to the enterprise running it, for latency and for cost, including the cost of the evaluation.
Patterns for orchestration, and the overhead they add, are a later reading list. I would start with the episodes gathered as best on multi-agent systems only after this sheet is filled in.
Checklist
- List skills, publisher, tool compatibility, and a reputation signal for every new agent, so a caller can search for it.
- Give every agent a unique id and provenance for itself and its data, and give every task an id.
- Name the protocols: MCP on the tool side and an explicit agent-to-agent choice such as ACP or A2A.
- Beyond a pair of agents, plan a group, low-latency, secure transport plus one shared telemetry schema so the run can be reconstructed.
- Write down allowed actions, the evaluation, the human review point, and the latency and token budget. A blank line means the work stays in one agent.
More on this topic, with the related episodes, is on Chain of Thought. It draws on this episode.
Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.
Drafted with AI assistance from the episode transcripts.
Top comments (0)