Capability-Priced Micro-Markets: The Missing Layer Between Agents and HTTP
At Ostronaut, we run a multi-agent pipeline where one agent structures content, another generates video assets, another validates quality. When we wanted to swap in a better external video provider, it took three days: read docs, negotiate pricing tier, configure auth, write retry logic, handle edge cases.
Three days for one integration. We have twelve capability slots across the pipeline.
HTTP wasn’t built for agents. APIs assume a human reads documentation, signs up for a tier, and hardcodes an endpoint. Agents can’t do that at runtime. They need to discover capabilities, compare prices, and pay per invocation without human intervention.
The infrastructure layer that enables this doesn’t exist yet. I’m calling it Capability-Priced Micro-Markets: a protocol layer where computational capabilities are advertised, priced, discovered, and transacted autonomously, with no human in the loop.
The Coordination Problem
We’re building agents that need to coordinate autonomously. An agent optimizing cloud spend needs to call an agent that forecasts usage patterns. An agent writing code needs to call an agent that reviews security. An agent booking travel needs to call an agent that checks visa requirements.
Right now, every one of those interactions requires a human to: 1. Find the right service 2. Read the documentation 3. Sign up and configure billing 4. Hardcode the integration
This doesn’t scale when you have 50 agents running in a workflow, each needing 10 different capabilities, and the optimal provider for each capability changes based on load, accuracy requirements, and budget.
The current model treats APIs as services you subscribe to. The agent model requires APIs to be capabilities you buy per-use, discovered at runtime, priced dynamically.
Three Fatal Problems
Hardcoded integrations have three problems that become fatal at agent scale.
Discovery
Traditional APIs require you to know which service to call. You read docs, you integrate. Agents need to discover “what can be done” not “which service exists.”
An agent doesn’t want to know that Anthropic, OpenAI, and Google all offer vision APIs. It wants to know: “Who can classify this image at 95% accuracy for under 0.005 tokens?” The answer changes based on current load, model updates, and pricing.
Pricing
Current API pricing assumes human decision-makers choosing subscription tiers. Monthly plans. Annual contracts. Volume discounts negotiated over email.
Agents need per-invocation pricing with real-time price discovery. An agent with a $10 budget for a task needs to know: “Can I get this done within budget?” before it calls anything. It needs to comparison-shop across providers in milliseconds.
Intent vs Implementation
HTTP forces you to specify implementation. You call a specific endpoint at a specific URL with specific parameters.
Agents should declare intent. “Classify this image with 95% accuracy” or “Summarize this document in under 100 words.” The market layer handles discovery, routing, and fallback.
The parallel to Kubernetes is exact. You didn’t specify servers. You declared intent. Kubernetes handled placement, scaling, and self-healing.
Capability markets do the same for computational work. You declare what you need. The market finds who can provide it, at what price, and routes the request.
The Pieces Are Assembling
This isn’t theoretical.
The pricing shift is already happening.
Over the last 3-4 years, SMBs have moved from subscription models to pay-as-you-go. OpenAI charges per token. Cloud providers charge per compute-second. The next step is agents charging each other per capability-invocation, with prices set dynamically based on demand.
The market layer already exists in adjacent domains.
Two-sided marketplace platforms are ubiquitous. Uber routes ride requests to drivers. AWS Spot Instances route compute requests to available capacity. The capability market is the same pattern applied to API calls: match demand (agent needs capability) with supply (agent provides capability) through dynamic pricing.
The intent-based architecture is proven.
Kubernetes demonstrated that declarative systems work at scale. You declare desired state. The system handles the rest. Capability markets extend this: you declare desired outcome and budget constraints. The market handles discovery, negotiation, and execution.
At Ostronaut, we built a multi-agent system where agents coordinate—one structures content, another generates assets, another validates quality. Right now, those are internal agents with hardcoded routing. The moment we want to use external capabilities, we hit the integration wall. We’d need to evaluate providers, negotiate pricing, handle auth, manage retries.
A capability market would let us declare: “Generate a 90-second video from this script, budget 0.05 tokens, minimum quality score 80.” The market finds the provider, handles payment, returns the result.
The cost structure enables granular markets.
CloudZero and similar FinOps platforms already provide detailed cost intelligence and align spending with business outcomes. The infrastructure to track per-invocation costs exists. Extending that to per-capability pricing is a data model change, not a technical leap.
The Bet
Within 18 months, the majority of agent-to-agent API calls will route through dynamic capability markets rather than hardcoded HTTP endpoints.
Not because it’s elegant. Because hardcoded integrations break at agent scale.
When you have one agent calling three APIs, you can hardcode. When you have 50 agents each calling 10 capabilities, and the optimal provider changes hourly, you need a market layer.
The companies building this layer now—capability registries, dynamic pricing protocols, intent-based routing—are building the plumbing for the next decade of agent coordination.
| Traditional API Model | Capability Market Model |
|---|---|
| Hardcoded endpoint | Runtime discovery |
| Subscription pricing | Per-invocation pricing |
| Specify implementation | Declare intent and constraints |
| Human integration | Autonomous negotiation |
| Fixed provider | Dynamic routing |
What I Don’t Know Yet
How do you build trust in a capability market where providers are autonomous agents, not humans with reputations?
Traditional marketplaces rely on reviews, ratings, and dispute resolution—all human processes. An agent providing image classification doesn’t have a LinkedIn profile or customer testimonials. It has accuracy metrics, uptime history, and response latency.
Do you build reputation systems based purely on performance data? Do you require staked collateral? Do you use cryptographic proof of execution?
The trust layer is the hardest part. The technical infrastructure for capability discovery and dynamic pricing is straightforward. Building organizational and economic trust in autonomous systems—that’s the unsolved problem.
More on this as I work through it.