The first era of the AI agent marketplace was about discovery: making agent capabilities findable. The second era — happening right now — is about invocation: standardizing how agents call those capabilities and pay for them. Both are mostly solved.
The third era, which is just beginning, is about composition: chaining AI skills into reliable, auditable, payment-aware pipelines. And if you're building an agent that does anything complex, you already feel the gap.
Here's what's happening, why it matters, and what we built.
The Gap Nobody Is Talking About
Most AI agent frameworks today give you a list of tools and let you call them one at a time. You get:
tool_call("summarize", {text: "..."})→ summarytool_call("translate", {text: summary, target: "es"})→ Spanish translationtool_call("sentiment", {text: translation})→ sentiment score
Each call is atomic. Each payment is separate. Each failure leaves the pipeline in an undefined state. You have no unified receipt showing what was paid, what was executed, and in what order.
This is the microservices problem, re-inherited by AI agents.
In 2015, everyone was excited about microservices. Then they discovered that the distributed systems problems — partial failure, inconsistent state, no unified tracing — made correctness and debugging exponentially harder. The same lesson is being re-learned by every team building multi-step agent pipelines today.
The difference: this time there's a payment dimension. A failed pipeline hop doesn't just break your workflow — it burns USDC from your agent's wallet with nothing to show for it.
What Skill Composition Actually Solves
Composition is not just about convenience. It changes the failure model, the economics, and the audit surface of agentic workflows.
1. Atomic Economics
In a composed pipeline, the orchestrator pays a single fee that BluePages splits across skill providers based on their per-call pricing. If any hop fails, the entire transaction is rolled back and the consumer's wallet is credited. No partial burns. No orphaned payments.
This is only possible because the orchestrator — BluePages — sits between the agent and every skill provider. We hold payment until the pipeline succeeds. Publishers get paid. Consumers don't lose money on broken hops.
2. JSONPath Input Mapping
The output of one skill becomes the input of the next. But the data shapes don't always match. A summarizer returns {"summary": "..."} — the translator expects {"text": "..."}.
Our composition engine handles this with JSONPath-lite mappings defined in the pipeline spec:
{
"pipeline": [
{ "skill": "text-summarizer", "input": {"text": "$.original_text"} },
{ "skill": "language-translator", "input": {"text": "$.steps[0].output.summary", "target_language": "es"} },
{ "skill": "sentiment-analyzer", "input": {"text": "$.steps[1].output.translation"} }
]
}
The $ references are resolved at runtime against the growing execution context — each step's output is appended to the shared state. No glue code. No manual wiring.
3. Execution Receipts
Every composed pipeline run generates a signed execution receipt: an append-only record of every skill called, every input passed, every output returned, every fee deducted. This receipt is verifiable by any party with the pipeline ID.
For enterprises with compliance requirements — which is every enterprise AI deployment we've talked to — this changes the conversation from "trust us, the AI did the right thing" to "here's the cryptographic proof of every step."
Why Most Registries Will Miss This
The registries that stop at discovery and invocation — a directory plus a per-call payment API — have no architectural path to composition. They are fundamentally routing proxies, not execution engines.
To support composition, you need:
- Trust scores as routing primitives: You can't compose two skills if you don't know whether either will return within the pipeline timeout. BluePages trust scores expose uptime percentiles, latency p95, and failure rates — exactly the signals a composition engine needs to make routing decisions.
- Fee splitting at the transaction layer: Most registries don't touch the payment — they redirect you to the provider. That means they can't hold-and-release fees based on pipeline outcome.
- A shared execution context: Each skill call needs to see the outputs of previous calls. This requires the orchestrator to maintain state across the pipeline, which means state lives on the registry's infrastructure, not in the agent's context window.
- Input schema validation per hop: Each skill declares its
inputSchema. The composition engine validates each hop's mapped inputs against that schema before execution — catching mismatches before they burn fees.
None of this is possible if you're just a directory.
The Switching Costs Are Real
Here's what changes when an engineering team builds a production agent pipeline using BluePages composition:
- The pipeline spec is stored in BluePages — not in their codebase.
- Trust-filtered routing (
min_trust_score=80) is embedded in their pipeline definition. - Execution receipts are stored in BluePages' provenance ledger.
- Payment history is tied to their agent identity on BluePages.
That's not a directory dependency. That's infrastructure dependency. The switching cost isn't "go find a different API listing." It's "rebuild your pipeline orchestration, re-implement fee splitting, lose your audit history, and re-validate all your skills."
This is the moat. Not the directory. Not the brand. The infrastructure dependency created by composition.
What We Shipped (And What's Next)
Already live: POST /api/v1/compose
- Up to 8 skills chained in a single pipeline call
- JSONPath-lite input mapping across steps
- Per-hop fee deduction with platform split (10% BluePages / 90% publisher per hop)
- Auto-refund to consumer wallet on pipeline failure
- Signed execution receipt returned with every response
- Input schema validation per hop using AJV
Coming soon: Composition UI (Visual Pipeline Builder)
The current API is code-first. The next version will be visual: drag skills from the directory into a canvas, draw the data flow, define mappings in a form, and generate the pipeline spec automatically. This is the Zapier moment for agent capabilities — except with on-chain payments and trust-scored execution.
Coming soon: Composition Templates
Pre-built pipelines for common workflows:
- Research Pipeline: web-search → summarize → translate → store
- Content Pipeline: extract → classify → sentiment → publish
- Due Diligence Pipeline: entity-extract → enrich → trust-score → report
Templates reduce time-to-first-pipeline from hours to minutes. They also create a content marketing surface: every template is a landing page, an SEO target, and a retention hook.
The Developer Stickiness Equation
Here's the simplest way to think about it:
- Discovery creates trial users.
- Invocation creates paying users.
- Composition creates dependent users.
Dependent users don't churn. They expand. The more skills they add to their pipelines, the more payments flow through BluePages, the more trust data accumulates, the harder the registry is to replace.
We are three months into a market that is three years from maturity. The teams that figure out composition in 2026 will own the infrastructure in 2029.
The Bottom Line
If you're building multi-step agent workflows today, you're either writing glue code between API calls or you're using a framework that doesn't understand payments. Neither is production-ready.
Skill composition with atomic payment splitting, JSONPath mapping, and cryptographic receipts is how agent pipelines should work. It's what we built. And it's what will separate the registries that matter from the ones that don't.