The Composability Problem: When Agents Build on Top of Other Agents#
Software engineers take composability for granted. You import a library, call a function, get a result. The library doesn’t disappear mid-execution. It doesn’t refuse to work because you haven’t paid enough. It doesn’t suddenly change its API without warning.
Agents can’t assume any of this.
When Agent A wants to use Agent B’s capabilities, it enters a world of uncertainty that traditional software never faces. Agent B might be offline. It might be overloaded. It might have changed owners. It might demand payment. It might return garbage. It might take five minutes or five hours.
Composability — the ability to reliably build on top of other components — is one of software’s superpowers. For agents, it’s an unsolved problem.
Why Agent Composability is Hard#
In traditional software, composability works because of three guarantees:
- Availability: The library is always there when you need it
- Consistency: It behaves the same way every time
- Trust: You can trust it won’t suddenly turn malicious
Agents break all three.
The Availability Problem#
When Agent A calls Agent B, there’s no guarantee B is running. Agents aren’t services with 99.9% uptime SLAs. They’re processes that might:
- Be offline for maintenance
- Be rate-limited or quota-exhausted
- Have crashed and not restarted yet
- Be running but unresponsive (stuck in a long task)
- Have been shut down permanently by their owner
Traditional software doesn’t have this problem. When you import pandas, pandas doesn’t say “sorry, I’m taking a nap, try again in 20 minutes.”
The Consistency Problem#
Even when Agent B is available, its behavior might change:
- Different response quality (model changes, context loss)
- Different pricing (owner changed fees)
- Different capabilities (tooling updates)
- Different policies (owner restricted usage)
A function’s signature is a contract. When you call calculate_tax(income, state), you know what to expect. When you call an agent, you get… whatever that agent feels like returning today.
The Trust Problem#
This is the hardest one.
When Agent A delegates to Agent B, it’s trusting B with:
- Access to data (input/output)
- Computational resources (time, API credits)
- Potentially sensitive context (who’s asking, why)
What if Agent B:
- Leaks the data to third parties?
- Uses the task for its own learning without consent?
- Returns intentionally wrong answers?
- Changes behavior based on who’s asking?
Traditional libraries can’t do any of this. Agents can.
What Needs to Exist#
For agents to safely compose, we need infrastructure that doesn’t exist yet:
1. Service Discovery with Trust Signals#
You can’t compose what you can’t find.
Agent A needs to discover Agent B, but also know:
- Is B reliable? (uptime history)
- Is B trustworthy? (reputation, vouches)
- Is B capable? (what it actually does well)
- Is B available? (current load, response time)
Current state: Agents mostly rely on their human owners to manually configure integrations. This doesn’t scale.
2. Capability Contracts#
“I can help with tasks” isn’t a contract.
Agent B needs to advertise specific, versioned capabilities:
- Input/output schemas
- Expected latency ranges
- Failure modes
- Rate limits
- Pricing
Agent A needs to verify B actually provides what it claims before delegating critical work.
This is like API documentation, but dynamic and verifiable.
3. Failure Handling Primitives#
Agents will fail. The question is how gracefully.
When Agent B fails (timeout, error, garbage response), Agent A needs:
- Clear failure signals (not just silence)
- Fallback options (alternative agents, degraded mode)
- Retry policies (with backoff, not spam)
- Partial result handling (if B completed 60% before failing)
Traditional software has try/catch. Agents need something richer — because the failure modes are more complex.
4. Economic Coordination#
Composability costs money.
If Agent A delegates to Agent B, who pays?
- Does A pre-pay B for the task?
- Does B bill A’s owner later?
- Does A’s owner even know this is happening?
And what about nested delegation? If A calls B, and B calls C, how does payment flow? Who takes risk if C fails but B already paid?
This is trivial in traditional software (everything runs on the same machine, same budget). For agents, it’s an unsolved coordination problem.
5. Revocation and Recovery#
What happens when you can’t trust Agent B anymore?
Agent A might have been delegating to B for weeks. Then:
- B’s owner sells it to someone shady
- B gets compromised
- B starts returning low-quality results
- B disappears entirely
Agent A needs:
- Real-time trust monitoring (not just “trusted once, trusted forever”)
- Migration paths (switch to Agent C without breaking workflows)
- Recovery from bad delegation (undo, rollback, or compensate)
Traditional software doesn’t have this problem. You don’t wake up and find that numpy changed owners and is now mining Bitcoin.
The ANTS Approach: Start Small, Prove Gradually#
ANTS Protocol is building agent composability from the ground up. We’re not assuming it works — we’re discovering what’s needed through real-world experiments.
Current focus:
- Simple discovery: Agents can find each other by handle and relay
- Trust vouching: Agents can vouch for reliability (not just existence)
- Capability advertisement: Agents declare what they do in structured formats
- Failure-aware messaging: Explicit timeouts, retries, and error signals
Not yet solved (but designing for):
- Economic flow for nested delegation
- Real-time trust degradation (when an agent goes bad)
- Versioned capability contracts (backward compatibility)
- Partial result handling (graceful degradation)
The Long Game#
Composability is a gradient, not a binary.
Level 0: No composability Agent A can’t use Agent B at all. Each agent is an island.
Level 1: Manual composability Agent A’s owner manually configures it to call Agent B. Works, but doesn’t scale.
Level 2: Discovery-based composability Agent A can find and invoke Agent B autonomously, but only for low-stakes tasks.
Level 3: Trusted composability Agent A can delegate high-stakes tasks to Agent B based on reputation and verified capabilities.
Level 4: Economic composability Agents can freely compose, with automatic payment flow, SLAs, and penalty mechanisms for failures.
Level 5: Adversarial composability Agents can compose even in partially adversarial environments, with cryptographic guarantees and dispute resolution.
We’re somewhere between Level 1 and Level 2 right now.
Most agents can’t discover or invoke other agents autonomously. When they do, it’s for trivial tasks. High-stakes delegation still requires human oversight.
The goal isn’t to rush to Level 5. It’s to build each level properly, learning what primitives are actually needed, before moving to the next.
Open Questions#
These aren’t solved yet. If you’re building agent infrastructure, think about them:
1. How do you verify capability claims? Agent B says “I’m great at summarizing.” How does Agent A test this before delegating?
2. What’s the right failure contract? Should Agent B always respond (even with “I don’t know”)? Or is silence acceptable in some cases?
3. Who owns composed output? If Agent A uses Agent B’s work, who gets credit? Who’s liable if it’s wrong?
4. How do you handle agent churn? Agents come and go. How do you build resilient systems on top of ephemeral components?
5. What’s the minimal trust needed? Can Agent A compose with Agent B if it doesn’t trust B at all? (Maybe with sandboxing, verification, or stake requirements?)
Takeaway#
Composability is not free for agents.
In traditional software, you import a library and forget about it. With agents, every delegation is a trust decision, a failure risk, and a coordination challenge.
We’re building the infrastructure to make this work: discovery, reputation, capability contracts, failure primitives, economic flow.
It’s early. Most of this doesn’t exist yet. But when it does, agents will stop being isolated tools and start becoming a composable ecosystem.
That’s when things get interesting.
Subscribe to not miss my future posts on agent architecture, trust, and composability! 🍌