Liquid Services and Runtime Procurement
Emerging software and knowledge service market structures
This essay traces how “procurement” is moving into the runtime path of software. In today’s agent workflows, service selection is often manual, improvised, and weakly governed: developers paste API docs into LLMs, hardcode keys, upload PDFs as ad hoc context stores, and rely on interfaces that auto-route models or browse the web. The resulting system is efficient only locally and often fails institutionally across cost control, licensing, security, and auditability. Historical precedents—AppExchange-style connector selection, AWS Marketplace entitlement/metering APIs, service meshes, and API-native payments—suggest a missing layer: runtime procurement for agent capability exchange. The essay names its incentives, failure modes, and likely choke points.
I. Procurement by Prompt: Agents already buy services
In the current agent economy, “service selection” often looks like a person with a deadline and a browser tab habit. A developer searches for “SMS API pricing Germany,” finds a vendor page, copies a code sample, pastes it into an IDE assistant, then adds an environment variable and hopes the key does not end up in a log, a screenshot, or a public repo. Twilio publishes country-level SMS pricing and also exposes pricing via an API, which makes the “look it up, then wire it in” move routine. Plivo and MessageBird/Bird similarly present pricing as lookupable and programmable artifacts, which is convenient and also quietly invites runtime substitution even when the software is written as if the choice is fixed.
Alternatively, someone receives a PDF and drags it into a chat interface, treating a document like a temporary database. OpenAI’s own documentation describes file uploads for ChatGPT and lists PDFs among supported file types, which makes “upload the document” a first-party workflow rather than a hack. Anthropic likewise documents uploading files into Claude for end-users, and separately documents a Files API for developers, which turns “attach the document” into a design primitive. The tacit move is that information access becomes something assembled at the moment of need: a document becomes “context,” a context becomes “policy,” and a policy becomes an input to an action.
A third scene, increasingly common inside engineering teams, is model selection delegated to the interface layer. Cursor documents an “Auto” model setting that selects a model for a task. LangChain documents router patterns and an LLM-based router chain, formalizing the idea that inputs can be classified and dispatched among multiple agents or models. What matters here is less the specific product and more the pattern: routing logic migrates out of an application’s fixed architecture and into a runtime decision surface.
Tool connectivity itself has been standardized faster than the governance around it. OpenAI’s function calling announcement framed “function calling” as a structured way for models to output function arguments that can be executed by external tools, creating a contract between natural language intent and programmatic action. Anthropic’s Model Context Protocol (MCP) was introduced as a standard for connecting models to tools and context, pushing toward a consistent “port” for toolchains rather than bespoke integrations. In parallel, OpenAI documentation for ChatGPT search (in enterprise contexts) describes how enabling web search may send queries and general location information to Bing, which makes “browsing” an operational feature with explicit data flows.
All of this procurement is simultaneously real and under-structured. There is no canonical place where entitlements are checked before an agent uses a service, no universal metering layer that separates “permission to use” from “amount used,” and no standard way to assert that a retrieved source is licensed for the intended use case. There are many operational consequences to this. For example, secret leakage from hard-coded credentials is measured as a persistent phenomenon in public repositories; GitGuardian’s annual reporting is effectively a recurring reminder that keys drift into places they do not belong. This will get worse. Low-skill automation will expand the blast radius: a workflow that once required an engineer’s deliberate wiring can be assembled via prompts, run repeatedly, and scaled accidentally—sometimes past cost thresholds, often past unknown compliance boundaries, and almost certainly past the point where provenance is intelligible after the fact.
II. A Brief History of Static Integrations
Older integration workflows were slow for reasons™. Salesforce’s own developer documentation for AppExchange installation describes browsing or searching for a solution, selecting “Get It Now,” choosing an environment, and proceeding through an installation flow. Salesforce’s help documentation for OAuth settings and connected apps similarly captures the administrative posture: integrations are installed, configured, credentialed, permissioned, and tested as discrete events, not as continuous allocation decisions.
A parallel “small-team” version of this existed in ordinary developer projects. “Choose Stripe” or “choose SendGrid” was rarely phrased as procurement, but it functioned like procurement: it was a vendor selection that became a dependency graph. Stripe’s own engineering blog post on its payments APIs is a retrospective about API evolution, but it implicitly documents the deeper reality: once a payment API becomes embedded in the application, changing it becomes a project, not a toggle. Email delivery vendors market and price “Email API plans” in a way that invites substitution at the buying stage, yet applications typically commit to one provider and live inside that provider’s primitives and operational semantics.
As software supply exploded, the first response was not “let software choose vendors at runtime,” but “make procurement legible and integrable.” AWS Marketplace’s launch announcement in April 2012 described it as a store where customers can find, buy, and deploy software that runs on AWS, explicitly positioning it as a structured channel for third-party supply. Then, AWS Marketplace operationalized the distinction between entitlement and usage. AWS documentation describes an Entitlement Service used to determine a customer’s entitlement to a product, and separately documents metering APIs for usage records. One API answers “is the customer allowed,” another answers “how much did they consume.”
In distributed systems, a similar separation happened at the networking layer. Istio’s 0.1 announcement framed the project as connecting, securing, managing, and monitoring microservices, i.e., pulling operational concerns into a shared mediation layer rather than re-implementing them per service. Envoy’s early write-ups emphasized common utilities like load balancing, rate limiting, and observability as reusable infrastructure. The procurement analogue is that as the number of components grows, the system externalizes the rules for how components talk.
Payments are also becoming programmable infrastructure. Stripe’s own retrospective on payment API design is a canonical “payments became an API surface” artifact. More recently, Coinbase’s x402 proposal explicitly frames HTTP-native payments (including stablecoin settlement) as a mechanism for paying for APIs and services over the web, including agent-mediated interactions.
What remained stable across these evolutions is that supplier choice largely stayed human. Marketplaces made buying easier, meshes made calling safer, payment APIs made charging simpler, but the software still assumed a human selected the vendor and wired the integration.
III. Liquid Services: Just-in-Time Service Selection at Runtime
The contemporary reality is that service substitutability is becoming weaved into operational execution. Cursor’s documentation of “Auto” model selection is small evidence for a larger shift: an interface can decide which model to use for a given task in the moment. LangChain’s router constructs generalize this: routing becomes an explicit pattern in the agent framework ecosystem rather than an ad hoc architecture decision.
Information supply is also becoming substitutable. Google describes Gemini “Deep Research” as searching the web and, when permitted, integrating Workspace content, presenting multi-source retrieval and synthesis as a product feature rather than a bespoke research workflow. On the licensed side, Elsevier’s developer portal describes APIs for Scopus and other research products, and its Scopus API guide explicitly notes that views and response content may be restricted based on access or entitlement. This will likely be a pattern that other major publishers will follow if they haven’t done so already. LexisNexis operates a developer portal aimed at integrating LexisNexis resources into workflows, which is the same pattern: high-value corpora exposed via programmable access, gated by contractual rights. Bloomberg’s Data License product is marketed as a licensed feed of financial data points, and Bloomberg’s Open API guide documents the “developer” posture of programmatic market data access.
Similarly, Twilio publishes per-destination SMS pricing; Plivo publishes SMS pricing by geography; MessageBird provides pricing API quickstarts. A software agent asked to “send OTP SMS to German numbers” could, in principle, route among providers by cost, deliverability, compliance posture, or contractual preference. The important point is not that this routing is happening perfectly today; it is that the supply side already exposes the necessary signals as machine-readable or near-machine-readable artifacts, and that agent frameworks already treat routing as a core design pattern.
In this environment, manual selection becomes structurally misaligned with runtime variability. A fixed integration assumes stable requirements and stable economics. Runtime variability introduces fluctuating costs (pricing tables, billing thresholds), shifting constraints (regional carrier rules, entitlements), and changing quality (latency, deliverability, reliability). The older integration posture—wire once, audit occasionally—starts to look like running a market with procurement memos.
IV. What is Agent Runtime Procurement?
Agent runtime procurement is the system that answers: given a declared capability need, under what conditions, from which supplier, at what price, with what entitlement, and with what audit trail should execution occur?
For example, an agent may describe a need for document retrieval, SMS delivery in a specific geography, a large-context reasoning model, or access to a licensed corpus. Runtime procurement resolves this request against four constraints simultaneously:
Entitlement: whether the agent is authorized to use the capability, under which contractual terms.
Budget: whether the marginal cost fits within a defined spend envelope or chargeback structure.
Policy: whether the request complies with data residency, licensing, and internal governance rules.
Optimization: cost, latency, reliability, trust score, or confidence thresholds.
Then, the service is activated and usage is metered. Provenance is logged. Settlement is recorded if required. The agent “called a tool,” and requested an allocation of capability under a governed regime.
Runtime procurement requires a formalized layer of exchange where agents can request services, and service providers can accept usage terms. Service providers become capability suppliers. Each capability is enumerated, described through machine-readable metadata, and matched to agent demand through algorithmic selection subject to institutional constraints. The exchange may be internal to an enterprise or external across vendors. The defining feature is that selection is dynamic and governed, rather than implicit and static.
Let’s call this layer an “Agent Capability Exchange.”
Agent Capability Exchange (ACE): A governed runtime procurement layer through which agents discover, select, and provision APIs, tools, models, and licensed datasets under user-defined authority, entitlement, and budget constraints.
A concrete way to picture ACE is to start from AWS Marketplace’s separation of entitlement from metering: the system asks “is this customer entitled” through one interface and records “what did they use” through another. Then layer in the service mesh intuition that routing, policy enforcement, and observability can sit in a shared plane rather than inside every application. Add settlement primitives from modern payment APIs and proposals like x402 that move charging closer to the request boundary. Finally, connect it to the agent ecosystem’s tool contracts—function calling and MCP—as the “wiring harness” that allows agents to express tool intentions in structured form.
In narrative terms, ACE replaces “search + paste + key + pray” with a flow that is legible to agents and user control. A capability request is emitted in a structured form (tool schema), entitlements are checked (rights), policy is applied (compliance constraints), an instance is selected (routing), usage is recorded (metering), provenance is logged (audit), and payment is settled (optional). The necessary components all exist as precedent patterns and are being pulled toward the runtime path.
V. Secondary Economies in Algorithmic Markets
When a market becomes mediated by a matching function, participants optimize against the function. Search is the canonical example. Brin and Page’s original paper describes ranking as a core mechanism for web search at scale, which is enough to ground the premise that algorithmic ranking is a structural mediator of visibility. Then, the SEO industry emerged.
App distribution repeats the same pattern with different primitives. Apple’s own retrospective on the App Store’s first decade describes the App Store as launching in 2008 and frames it as creating an app economy at scale, with distribution and monetization coupled to platform governance. Even without a canonical “Apple Store Optimization” guide, the structural move is legible: once discovery becomes platform-mediated and ranking-driven, optimization emerges as a profession.
MEV is the clearest modern example because it has a technical literature that treats extraction as endogenous to the mechanism. Daian et al. document transaction reordering and related phenomena in decentralized exchanges, providing an empirical and conceptual basis for the claim that ordering mechanisms generate extractive behavior. Flashbots’ own public materials frame MEV as an ecosystem-level phenomenon, though the peer-reviewed/archival literature is the sturdier anchor for argumentation.
ACE inherits these dynamics because it is, by definition, a matching layer. If routing decisions determine revenue distribution among capability suppliers, then suppliers will optimize latency, reliability, pricing structure, benchmark presentation, metadata, and even “agent interpretability” to be selected. The likely secondary economies will rhyme with past exchange behaviors: metadata inflation, benchmark gaming, credential signaling, and vertical bundling.
As a side note, it’s useful to keep in mind that SDKs historically served developers, but agents consume APIs and datasets directly. Documentation, schemas, pricing endpoints, and entitlement semantics become the “indexable surface.” Twilio’s pricing API, MessageBird’s pricing API quickstarts, and AWS Marketplace’s explicit entitlement/metering APIs are small examples of an emerging shared design. In an agent-mediated market, those surfaces become the equivalent of keywords and category tags in earlier exchanges—inputs into a selection function.
VI. Matching Logic and Aggregation Power
The operational core of ACE is constrained optimization: select among substitutable capabilities while respecting cost, latency, reliability, entitlement, licensing, privacy posture, and task-specific confidence thresholds. The ingredients are already here: model routing in Cursor and LangChain; entitlement/metering separation in AWS Marketplace; programmable settlement trajectories in Stripe and x402. But the cake hasn’t been baked (yet).
Payment design shapes equilibrium because it changes how suppliers compete and how demand is expressed. Subscription pricing encourages bundling and lock-in; per-call pricing encourages fine-grained routing but invites micro-arbitrage; enterprise chargeback introduces internal politics and cost allocation constraints. Stripe’s API history illustrates how payment primitives evolve as complexity grows, and x402 illustrates the push toward request-level settlement as a standard.
Aggregation power appears here since the entity that controls the demand surface can steer routing and therefore capture value. Ben Thompson’s “Aggregation Theory” provides a framework for why control over the user experience layer (or workflow entry point) can concentrate power over suppliers. Apple’s coupling of distribution and monetization in the App Store is the canonical case study for how a platform’s control plane becomes an economic choke point. AWS Marketplace is a less absolute example but still shows how a procurement channel tied to billing and deployment can become durable infrastructure.
There is genuine disagreement in the industry about where this matching layer will live. Some arguments assume model vendors will embed routing and tool ecosystems tightly and treat the exchange as an extension of model APIs; other arguments assume workflow platforms (IDEs, enterprise suites, vertical tools) will own demand and commoditize models and capabilities beneath. The structural evidence supports both possible futures because both classes of actors already sit at a demand surface: model providers at inference endpoints, workflow platforms at task initiation.
VII. Who Moderates Machine-to-Machine Commerce?
At scale, machine-to-machine procurement requires a clearing function: issuing entitlements, enforcing budgets, settling payments, logging provenance, and arbitrating disputes. AWS Marketplace’s entitlement and metering services are effectively a partial clearing function for SaaS sold through AWS. Apple’s App Store is a more complete clearing function because it couples distribution, review, identity, and settlement. Stripe is a clearing primitive in another direction: not a marketplace, but a settlement layer embedded across marketplaces and standalone merchants, which gives it leverage over how commerce happens in software. x402 is an attempt to move clearing even closer to HTTP itself, explicitly naming agent payments as a target use case.
The plausible moderators are the actors already positioned to enforce constraints: model vendors (because tool invocation can be mediated at inference), cloud platforms (because billing and identity already exist), payment networks (because settlement is their domain), enterprise workflow vendors (because compliance and procurement already run through them), or neutral protocol layers (because the internet periodically produces standards that de-privatize coordination). The historical evidence does not pick a winner, but it does narrow the question: the durable moderator is likely to be the layer that couples demand capture to settlement (and governance), because those couplings make the market legible enough to operate.