Pricing for Agents That Act Across Multiple Systems: When One Task Touches Six Tools

Table of Contents

• The Pricing Problem Single-System Thinking Misses
• Why Cross-System Work Is Structurally More Expensive
• The Four Pricing Models and How They Bend Under Multi-System Load
• The Hidden Cost Center: Third-Party API Pass-Through
• Attribution: Who Gets Credit When Six Systems Cooperate
• A Practical Pricing Blueprint for Cross-System Agents
• Insights Most People Overlook
• References

The Pricing Problem Single-System Thinking Misses

Most early GaaS pricing was written for agents that live inside one box. A support agent that resolves tickets inside Zendesk. A coding agent that operates inside a repo. A research agent that returns a document. For those, the unit is obvious. You charge per resolution, per pull request, per report, and the cost of producing that unit is mostly your own inference plus a single integration you control.

Then customers started asking for the thing they actually wanted, which was never "answer this ticket." It was "take this refund request, verify the order in Shopify, check the fraud signal in Stripe, issue the credit, update the CRM, and tell the customer." That's one job from the buyer's perspective and six system boundaries from yours.

This is where pricing quietly falls apart. The vendor priced "per resolution" assuming a Zendesk-shaped resolution. Now a single resolution drags in five external APIs, three of which rate-limit, one of which charges per call, and one of which occasionally returns stale data that forces a retry. The vendor's unit economics were modeled on the easy version and they're now shipping the hard version at the same price. I've watched this exact margin leak sink the gross margin of more than one promising agent product, and it usually doesn't show up until the deals that close are the integration-heavy ones, which are, of course, the deals worth the most.

The taxonomy question, per-task, per-outcome, per-seat, is covered well elsewhere in this cluster, and you should read it as a foundation. Here the focus is narrower and harder: what changes the moment the agent stops living in one system and starts orchestrating across many.

Why Cross-System Work Is Structurally More Expensive

It's tempting to think a multi-system agent costs more simply because it does more steps. That's true but it undersells the problem. The cost structure is non-linear in three specific ways.

Failure surface compounds. If each system call succeeds 98% of the time, a workflow touching six systems succeeds 0.98^6, or about 89%. Every nine-failure cascade triggers retries, fallback logic, or human escalation, all of which burn tokens and engineering support time you didn't price. A single-system agent at 98% is reliable. A six-system agent built from the same parts is shaky, and reliability engineering is the cost nobody itemizes on the invoice. Agent reliability is its own deep topic in the GaaS cluster, but its fingerprints are all over your cost model.

State and context balloon. To act across systems coherently, the agent has to hold context from all of them. The refund agent needs the order, the payment, the customer history, and the policy doc in working memory at once. That's more tokens per step, more grounding calls, and more places for the model to lose the thread. Context isn't free, it's the line item that grows fastest as you add systems.

Coordination is real work. Deciding the order of operations, handling partial completion (the credit issued but the CRM update failed), and knowing when to roll back versus when to flag, this orchestration logic is where most of the engineering goes, and it's invisible in a per-task price. Researchers at firms tracking the space, including the team behind a16z's writing on the emerging agent infrastructure stack, have noted that the orchestration and memory layers are where durable value (and cost) concentrate, not the model call itself.

Put bluntly: a cross-system agent is not a single-system agent doing more. It's a different cost animal, and pricing it like the cheaper cousin is how you lose money on your best customers.

The Four Pricing Models and How They Bend Under Multi-System Load

Per-Seat: Almost Always Wrong Here

Per-seat pricing assumes a human-shaped relationship to the tool. Cross-system agents sever that relationship entirely, the whole point is that no human is sitting in six dashboards. Worse, per-seat decouples your revenue from your cost: a single "seat" might trigger ten thousand cross-system workflows a month, each one costing you real API and inference dollars while your price stays flat. The case against per-seat is strong generally; for multi-system agents it's close to disqualifying. The only place it survives is as a packaging veneer over a usage engine underneath.

Per-Task: Clean Until the Tasks Aren't Uniform

Per-task pricing works beautifully when tasks are uniform. The trouble with cross-system agents is that two tasks with the same name can have wildly different system footprints. One refund touches two systems and resolves instantly; another touches six, hits a rate limit, retries twice, and escalates. Charging the same for both means you're cross-subsidizing the expensive tasks with the cheap ones, fine on average, dangerous if a customer's mix skews heavy. Smart vendors keep per-task pricing but tier it by complexity, often by counting the number of system actions invoked.

Per-Outcome: The Right Default, With a Catch

Outcome pricing, you pay when the refund is fully processed, not per API call, aligns price with the buyer's mental model and absorbs the messy reality that some outcomes take two systems and some take six. The buyer doesn't care how many systems you touched; they care that the refund is done. This is usually the right default for cross-system work. The catch is auditing: when the outcome depends on six systems, defining "done" gets genuinely hard, and a failure in someone else's API can block an outcome you'd otherwise have delivered. Who eats that cost is a pricing decision, not just an engineering one. (The question of who defines and audits the outcome is itself a whole node in this cluster, and it gets thornier with every system you add.)

Hybrid: Where Most Serious Vendors Land

In practice, the model that survives contact with real cross-system deployments is a hybrid: a base platform fee that covers the cost of maintaining live integrations, plus usage or outcome charges on top. The base fee matters more than people think for multi-system agents specifically, because maintaining a working connection to NetSuite or Epic or SAP is ongoing labor, APIs change, auth tokens expire, schemas drift. You're not just selling outcomes; you're selling a promise to keep six brittle integrations alive. That promise deserves a line item. The well-documented downside, flagged in McKinsey's analysis of how generative AI is reshaping software economics, is that usage-driven costs are volatile and can compress margins if the pricing doesn't pass through cost variance, which brings us to the part most vendors get wrong.

The Hidden Cost Center: Third-Party API Pass-Through

Here's the cost line that single-system pricing never had to think about and that sinks multi-system gross margins quietly: the agent is spending the customer's money, and yours, inside other vendors' meters.

When your agent enriches a lead through Clearbit, runs a background check through a verification API, sends a transactional email through SendGrid, or pulls a credit report, each of those calls has a price. Sometimes you front it. Sometimes the customer's keys are used and they front it. Either way, your "per-outcome" price now contains a floating pass-through cost you don't fully control. If you priced the outcome at a flat rate and the underlying API raised its prices, or the agent's strategy started making three enrichment calls instead of one, your margin moved without anyone touching your pricing page.

There are three defensible ways to handle this, and the choice signals how mature the vendor is:

1. Pass-through at cost, itemized. The customer sees exactly what third-party APIs were consumed and pays cost (or cost-plus-small-margin). Transparent, FinOps-friendly, and it makes your margin robust to upstream price changes. The downside is it makes the bill look complicated, which can spook buyers.
2. Bring-your-own-keys. The customer connects their own API accounts; their agent spends on their meters. You charge only for orchestration. This is clean for margin but pushes integration burden onto the customer and only works for systems they already pay for.
3. All-in with a buffer and a cap. You bundle estimated third-party costs into the outcome price, build in margin to absorb variance, and protect yourself with a usage cap. Simplest bill, but you're now carrying the volatility risk, price it wrong and a heavy customer eats your quarter.

The vendors who survive are the ones who instrument every external call from day one, even if they choose to hide it on the invoice. You cannot price what you don't measure, and cross-system agents make a lot of measurable calls into systems whose prices you'll never control.

Attribution: Who Gets Credit When Six Systems Cooperate

There's a subtler problem lurking in multi-system pricing, and it's about credit, not cost.

When an outcome requires six systems and one of them is the customer's own ERP that did the actual ledger write, how much of the value did your agent create? In a partial-completion scenario, the agent did five of six steps perfectly but the sixth failed in the customer's flaky on-prem system, did you deliver the outcome or not? Your pricing has to answer this before a dispute forces it to.

This matters because cross-system agents create value that's genuinely distributed. The orchestration is yours. The systems of record aren't. A buyer's procurement team will, reasonably, ask why they're paying outcome prices for work that depended heavily on tools they already own and pay for. The honest answer, that orchestrating those tools reliably is the hard part, is true but needs to be priced and positioned, not assumed. Graceful degradation and partial-completion pricing are real disciplines here, not edge cases, because in a six-system workflow partial completion isn't rare. It's Tuesday.

The vendors getting this right write the partial-completion rules into the contract: what counts as a delivered outcome, what gets pro-rated, and what happens when the failure originated in a system the customer controls. Vague outcome definitions are where trust dies and where, per HBR's coverage of how AI is reshaping pricing strategy, the negotiation leverage quietly shifts to whichever side wrote the clearer definition.

A Practical Pricing Blueprint for Cross-System Agents

If you're pricing an agent that acts across systems, here's the structure I'd reach for, assembled from what's actually working in the market rather than what sounds clean on a slide.

Start with an outcome unit the buyer recognizes. "Resolved refund," "onboarded vendor," "reconciled invoice." Not "API call," not "agent run." The buyer should understand the unit without you explaining it.

Tier that outcome by system footprint, not just by name. A two-system outcome and a six-system outcome can share a name and not a cost. Bake complexity into the tier, most cleanly by counting distinct system actions or by defining "standard" versus "complex" variants up front.

Add a base platform fee that explicitly buys integration maintenance. This is the line item that makes cross-system pricing honest. You're keeping brittle connectors alive; charge for it, and the base fee also smooths the revenue volatility that pure usage pricing inflicts.

Make third-party API cost a deliberate, instrumented choice, pass-through, bring-your-own-keys, or buffered-and-capped. Never leave it implicit. Implicit pass-through cost is the single most common way cross-system agents go gross-margin negative without anyone noticing until the QBR.

Cap it. Usage caps protect both sides, they stop a runaway agent from generating a six-figure surprise bill across six metered APIs, and they protect your margin from a customer whose workflow mix skews catastrophically heavy. A cross-system agent without a cap is an uncapped liability wearing a pricing page.

Define partial completion in writing before you need to. Spell out what a delivered outcome is, what happens when a customer-owned system fails, and how disputes resolve. Do it in the contract, not in the support ticket after the first bad month.

None of this is exotic. It's the discipline of pricing for a workflow whose cost lives partly inside systems you don't own, and recognizing that the integration depth your best customers love is exactly the depth that quietly costs you the most.

Insights Most People Overlook

The integrations your customers value most are the ones that lose you money first. There's a perverse alignment problem: customers pay premium prices precisely for the deep, multi-system workflows, and those are exactly the workflows with the worst failure compounding and the highest third-party API exposure. The product team celebrates landing the SAP integration; the finance team should be nervous, because that integration is brittle, expensive to maintain, and now embedded in a flat outcome price. Your most strategic deals can be your worst-margin deals if you don't price system depth explicitly.

Retries are a pricing event, not just an engineering detail. In a single-system agent, a retry is a minor cost. In a six-system agent at realistic per-call reliability, retries and fallbacks aren't edge cases, they're a meaningful fraction of total compute, and they scale with the number of systems. Almost nobody models retry cost into per-outcome pricing, which means the more unreliable the customer's own systems are, the more money you silently lose on their account. The customers with the flakiest internal tooling are subsidized by the ones with clean APIs.

Bring-your-own-keys is a margin strategy disguised as a feature. Letting customers connect their own API accounts gets sold as flexibility and data control. The real reason sophisticated vendors push it is that it moves the most volatile, least controllable cost, third-party pass-through, off your books and onto the customer's, who is already paying it elsewhere anyway. It's one of the cleanest ways to make cross-system economics robust, and it's almost never framed as the margin move it actually is.

Outcome pricing secretly favors whoever owns the failure boundary. When the outcome depends on a customer-owned system that fails, a vague outcome definition means you eat the loss for something that wasn't your fault. The vendor who writes the precise definition, "outcome delivered when the agent completes its controllable steps; customer-system failures are excluded", shifts that risk back. This isn't lawyering for its own sake; in multi-system workflows the failure boundary is the single most valuable clause in the contract.

The base platform fee is really insurance against API churn. People read the base fee as covering "the platform." For cross-system agents, what it actually covers is the relentless maintenance of integrations against other people's changing APIs, the auth rotations, the deprecated endpoints, the schema migrations. Framed that way, it's not a SaaS subscription. It's a maintenance premium on a fleet of connectors you've promised to keep alive, and it should be sized to that promise, not to a per-seat habit inherited from old software.

References

• a16z, The Rise of the Agentic Web
• McKinsey, The Economic Potential of Generative AI: The Next Productivity Frontier
• Harvard Business Review, How Generative AI Changes Strategy