How to Build an Agent-as-a-Service Business Model With LLMs

Introduction

Learning how to build an agent-as-a-service business model with LLMs has become urgent because buyers now pay for finished work instead of software seats. Gartner forecasts that over 40 percent of agentic AI projects will be cancelled by the end of 2027, mostly because of rising costs, unclear value, and weak risk controls. That forecast is a warning aimed at builders who skip the economics and ship a clever demo. A durable agent business starts with one narrow job, a price tied to a measurable outcome, and metering precise enough to protect your margin on every task. This guide walks through the full path, from defining the model to architecture, pricing, billing, evaluation, security, and a pilot launch. Each step includes working code you can adapt, plus benchmarks from vendors that already charge by the resolution. By the end you will know which numbers to track and which mistakes to avoid before your first invoice goes out.

Quick Answers on How to Build an Agent-as-a-Service Business Model With LLMs

What is the fastest way to understand this business model?

To learn how to build an agent-as-a-service business model with LLMs, sell completed work done by agents and charge per task, resolution, or usage rather than per seat. Customers pay for outcomes.

How should you price an LLM agent?

Start with your measured cost per attempt, divide by the expected resolution rate, and add a margin floor. Intercom charges 99 cents per resolution, while HubSpot charges 50 cents per resolved conversation.

What do you need to launch the first version?

You need one narrow job, a multi-tenant agent runtime, a usage meter, an evaluation harness, and a price floor above your cost. The seven-step build below turns those pieces into a pilot.

Key Takeaways

• Sell outcomes, not seats: price per resolution or per completed task, and keep a margin floor above your measured cost per attempt.
• Pick one narrow, measurable job, because an agent whose success can be verified automatically is far easier to price and improve.
• Meter every billable event with an idempotency key, since your invoice is only as trustworthy as your usage log.
• Evaluate before you charge, because a published resolution rate becomes a liability when your harness cannot reproduce it.

What Is an Agent-as-a-Service Business Model With LLMs?

Knowing how to build an agent-as-a-service business model with LLMs starts with its meaning: a company sells completed work performed by autonomous language-model agents, billed per task, resolution, or usage rather than per software seat. The vendor owns reliability, model cost, and margin.

Why Agent-as-a-Service Is Replacing the Seat License

Seat-based licensing assumed that humans do the work and software merely assists them. Large language model agents break that assumption because a single agent can complete an entire ticket, reconciliation, or research task without a person clicking through screens. When the software performs the work, charging per seat stops matching the value delivered, and buyers notice quickly. Citi Ventures frames the shift through Jensen Huang’s prediction that every SaaS company will become an agents-as-a-service company. The same analysis traces pricing moving from seats to usage and ultimately to outcomes. That progression explains why so many vendors now quote prices per resolution instead of per user per month.

The economics of the old model depended on marginal cost near zero, and agents reverse that assumption. Every agent attempt consumes model tokens, tool calls, and sometimes human review, so each task carries a real variable cost. A vendor that sells flat seats while customers run thousands of agent tasks can lose money on the heaviest accounts. Usage and outcome pricing restore the link between what customers consume and what the vendor spends. They also let a buyer justify the purchase against the cost of a human-handled task instead of against another software license. This is why the pricing page is now part of the product architecture rather than a marketing afterthought.

Not every product should abandon seats, and the transition is rarely instant. Many vendors keep a platform fee for access, governance, and support, then add a variable component for agent work. Customers value that structure because it caps worst-case spend while still rewarding the vendor for delivering outcomes. Later sections compare seats, usage, outcomes, and hybrids with concrete prices from Intercom, HubSpot, Salesforce, and Zendesk. For now, the key point is that an agent business has a cost curve and a revenue curve that must be designed together. The remainder of this guide treats them as one system.

Market Signals Behind Services-as-Software

Looking at the demand side, analysts expect agentic capabilities to spread quickly through enterprise software. Gartner projects that 33 percent of enterprise software applications will include agentic AI by 2028, up from less than 1 percent in 2024. The same forecast expects at least 15 percent of day-to-day work decisions to be made autonomously by 2028. Those figures describe a market where agents become a default feature, which pressures standalone vendors to prove measurable outcomes. Buyers will compare your agent with the one bundled into their existing platform. A narrow, well-measured agent business can still win, but only by being better at one specific job.

Revenue evidence is arriving from the vendors that moved first. Intercom launched its Fin agent in 2023 and now prices it per resolution, while HubSpot, Salesforce, and Zendesk have adopted usage or outcome models of their own. Sacra estimates that Sierra reached about 400 million dollars in annualized revenue by October 2026, up from 26 million at the end of 2024. The same profile reports that Sierra raised 950 million dollars at a 15.8 billion dollar valuation in May 2026. Those figures are third-party estimates, so treat them as directional rather than audited. They still show that buyers will pay real money when an agent closes real tickets. The lesson for a new entrant is that distribution and trust matter as much as model quality.

Skepticism is just as visible in the market, and builders should read it carefully. Vendors have rebranded chatbots, assistants, and robotic process automation as agents without adding any autonomous capability, a pattern analysts call agent washing. Buyers who have been burned once ask harder questions about evidence, so vague claims hurt conversion. A credible agent business publishes its resolution rate, its definition of a resolution, and its failure handling. Transparency becomes a competitive moat in a category full of exaggeration. The practical response is to measure everything and show your work.

Capital flows confirm the interest but also raise the bar for smaller teams. Well-funded competitors can subsidize prices to win accounts, which compresses margins for entrants without deep pockets. A small team therefore needs a vertical where domain data, integrations, or compliance knowledge create a barrier. Horizontal chat agents will be bundled by large platforms, while vertical agents with deep workflow knowledge remain defensible. In the early years, services-as-software rewards depth of workflow knowledge over breadth of features. Choosing that vertical is the subject of the next section.

Choosing a Niche and the Job Your Agent Owns

Moving on from market context to your own product, the first decision is which job your agent owns from start to finish. A good first job has a verifiable outcome, a high volume of repetitive cases, and a human cost per case that you can measure today. Customer support resolution, invoice matching, lead qualification, and IT ticket triage all fit that pattern. Each has a clear definition of done, such as a closed ticket, a matched invoice, or a booked meeting. Jobs without a checkable result, like open-ended strategy advice, are poor candidates because you cannot price or evaluate them. Write the outcome in one sentence before you write any code.

Specialization also determines how defensible the business becomes over time. The discussion of domain-specific agents versus general agents explains why narrow agents with curated tools and data usually outperform generalists on accuracy and cost. A vertical agent can embed regulations, terminology, and system integrations that a general assistant lacks. That depth shortens onboarding for each customer and reduces the number of failure modes your team must handle. It also gives you a natural pricing unit, such as per claim processed or per ticket resolved. Resist the urge to serve every industry in the first year.

Architecture of a Multi-Tenant Agent Platform

Turning to architecture, an agent service has five layers: an API gateway, a tenant-aware orchestrator, a model layer, a tool layer, and a metering pipeline. The gateway authenticates the customer and attaches a tenant identifier to every request. The orchestrator runs the agent loop, deciding when to call the model, which tool to invoke, and when to stop. The model layer abstracts one or more LLM providers so you can swap models without rewriting workflows. The tool layer exposes controlled actions such as reading a knowledge base or updating a ticket. The metering pipeline records every billable event with the tenant identifier attached.

Tenant isolation is the design decision that most affects cost, risk, and sales cycles. The AWS Prescriptive Guidance on multi-tenant agentic AI describes siloed deployments, where each tenant gets dedicated agent resources, and pooled deployments, where tenants share them. It also names noisy neighbors, resilience, cost, and tenant context as first-class concerns for agents. Pooled designs are cheaper to run and easier to update, but they demand strict context handling. Siloed designs suit regulated customers who require dedicated infrastructure and will pay for it. Many vendors start pooled and offer a siloed tier to enterprise accounts.

Tool access is where agents touch customer systems, so design it deliberately from the start. Modern models call tools through structured output, and function calling in LLMs is the mechanism most frameworks wrap. Each tool should declare a narrow schema, validate its arguments, and run with the tenant’s credentials rather than a shared master key. Memory deserves the same discipline, because conversation history and retrieved documents must never leak across tenants. A simple rule works well: every read and write in the system carries a tenant identifier that is checked at the data layer. Test that rule with automated cross-tenant probes before your first customer goes live.

Picking Models, Frameworks and Tool Protocols

Building on that architecture, model choice is mostly a cost and latency decision rather than a loyalty decision. Route simple classification or extraction steps to small, inexpensive models and reserve frontier models for reasoning-heavy steps. Measure accuracy on your own evaluation set instead of trusting public leaderboards, because your tickets will differ from benchmark questions. Keep prompts and tool definitions provider-neutral where possible so you can renegotiate or switch. Log the model version with every task so a regression can be traced to a specific change. Treat the model as a replaceable component, not as the product.

Framework choice follows the same pragmatic logic that governs model choice and tool design. The comparison of Microsoft Agent Framework versus OpenAI Agents SDK lays out the trade-offs teams weigh when picking an orchestration layer. The OpenAI Agents SDK, for instance, is a lightweight Python framework whose core pieces are agents, handoffs, guardrails, sessions, and tracing. Teams that want typed workflows may prefer the approach compared in Pydantic AI versus LlamaIndex workflows. Whichever you choose, favor frameworks that give you tracing and explicit control flow, because debugging a non-deterministic loop without traces is painful. Avoid deep coupling to framework internals that you cannot replace later.

Tool protocols are the third choice, and standardized protocols reduce integration work for every new customer. The Model Context Protocol lets an agent discover and call tools exposed by separate servers through a common interface. That makes it easier to add a customer’s CRM or ticketing system without custom glue code. The convenience comes with security obligations, since every connected server expands your attack surface. A later section on security returns to that risk in detail. Start with the smallest set of tools that completes the job, and add connections only when a paying customer needs them.

Pricing Design: Seats, Usage, Outcomes and Hybrids

Shifting to pricing, four structures dominate agent businesses today: seats, usage, outcomes, and hybrids. Seats are simple to sell and forecast, but they ignore the variable cost of agent work. Usage pricing charges for tokens, actions, or conversations, which tracks cost but exposes customers to bills they struggle to predict. Outcome pricing charges only when the agent finishes the job, which aligns incentives and shifts failure risk to the vendor. Hybrids combine a platform fee with variable charges and are common in enterprise deals. The comparison table later in this guide lines up all four across eight dimensions.

Real price points from the market show just how wide the range really is. Salesforce prices Agentforce actions at 20 Flex Credits each, which works out to 10 cents per action. Credits are sold at 500 dollars per 100,000, and the company also cites an existing price of 2 dollars per conversation. Intercom charges 99 cents per resolution for Fin, and HubSpot moved to 50 cents per resolved conversation. Those prices span a twenty-fold range per billed unit, yet each unit represents a different amount of work. A conversation, an action, and a resolution are not interchangeable, so compare cost per completed outcome rather than headline unit prices. Always translate a competitor’s price into your own unit before you react to it.

Outcome-based pricing deserves extra scrutiny because it is attractive and risky at the same time. You earn revenue only when the agent succeeds, so every failed attempt is a pure cost. The definition of success must therefore be precise, observable, and agreed with the customer in writing. Intercom, for example, counts a resolution when the customer confirms the answer worked or stops asking for help after the last AI response. Ambiguity about escalations, partial answers, and reopened tickets leads to billing disputes. Write those edge cases into the contract before launch, not after the first argument.

Hybrid structures often win in practice because they balance predictability and alignment. The overview of how AI agent pricing is evolving tracks the move from per-seat toward consumption and outcomes across the market. A typical hybrid charges a monthly platform fee that includes a bucket of resolutions, then bills overage per resolution. Annual prepaid buckets, which Intercom offers for Fin, give customers budget certainty and give the vendor cash up front. Set caps and alerts so a customer never receives a surprise invoice during a traffic spike. Review prices every quarter, because model costs and competitor prices are changing quickly.

Metering and Billing Infrastructure

Moving on to billing, your invoice is only as trustworthy as the usage records behind it. Every billable event, such as a resolved ticket or a completed action, should produce one record with a tenant identifier, a unique event identifier, a timestamp, and a quantity. Stripe’s meter events API accepts an event name, a customer identifier, and a numeric value, and it supports an identifier for idempotency so retries do not double count. Stripe also notes that events must be timestamped within the past 35 calendar days and no more than five minutes in the future. The live-mode endpoint is limited to 1,000 calls per second per account, with one concurrent call per customer per meter. Pre-aggregating events before sending them is the documented way to stay under those limits.

Decide early whether to build your own metering layer or adopt a managed one. Stripe’s documentation now recommends its Metronome product for new usage-based integrations that need prepaid credits, real-time usage visibility, or high-volume ingestion, while basic Meters remain supported for existing setups. Whichever path you choose, keep your own append-only event log as the source of truth so you can reconcile disputes. Reconcile that log against billed usage every day, and alert on gaps larger than a small tolerance. The practice of FinOps for agentic AI extends this discipline by attributing model spend to the same tenant and task identifiers. Joining revenue events and cost events on one key is what makes per-customer margin visible.

Unit Economics and Gross Margin Control

Stepping back to the arithmetic, unit economics decide whether outcome pricing makes money, and the math is simple. Your cost per attempt is the sum of model tokens, tool calls, retrieval, and any human review required for one conversation. Your cost per resolution equals cost per attempt divided by the resolution rate. Suppose an agent resolves 65 percent of conversations and each attempt costs 12 cents, so each resolution costs about 18.5 cents. At a price of 99 cents per resolution, that leaves a gross margin of roughly 81 percent before infrastructure and support. Agent cost per task measurement is the practice of tracking this figure continuously instead of estimating it once.

Resolution rate is the lever with the most leverage, because it sits in the denominator of your cost per resolution. If the same agent improves from 65 percent to 80 percent resolution, cost per resolution falls from about 18.5 cents to 15 cents without any price change. At a 30 percent resolution rate, the same attempt cost becomes 40 cents per resolution, which still clears a 99 cent price but leaves little room for support and infrastructure. Failed attempts also create hidden costs, because escalated conversations may still need a human. The break-even resolution rate equals cost per attempt divided by price per resolution, which is 12 percent in this example. Track the gap between your actual rate and that break-even line every week.

Several practical techniques can reduce your cost per attempt without hurting answer quality. Prompt caching is the most direct, since Anthropic’s documentation states that cache reads cost 0.1 times the base input price for most models, while five-minute cache writes cost 1.25 times. Reusing a long, stable system prompt and tool definitions across many requests therefore cuts input spend sharply. Routing easy tasks to smaller models, trimming retrieved context, and capping the number of agent loop iterations all lower cost further. Set a hard step limit and a per-task budget so a runaway loop cannot erase a day of margin. Review the largest cost drivers monthly, because the best optimization changes as usage patterns shift.

Reliability, Evaluation and Guardrails

Stepping back from features, reliability is the real product when customers pay for outcomes. An agent that is right 90 percent of the time still fails one customer in ten, and each failure costs money under outcome pricing. Build an evaluation set from real, anonymized cases before launch, and label the correct result for each. Run every prompt, model, or tool change against that set and block releases that lower the score. Measuring AI agent performance requires tracking task success, cost, latency, and escalation rate together rather than accuracy alone. A dashboard that shows only accuracy hides the trade-offs that decide profitability.

Guardrails should be deterministic wherever the stakes are high for the customer. A language model can be asked to behave, but a rule in code cannot be talked out of its behavior by a clever prompt. Deterministic guardrails for AI agents such as allow-lists for tools, schema validation, spending limits, and mandatory approval for irreversible actions provide that certainty. Place them outside the model, so a compromised prompt cannot disable them. Log every blocked action, because the log reveals attack attempts and flawed workflows alike. Pair rules with a human escalation path that is fast enough to preserve the customer experience.

Evaluation must continue after launch through sampling, auditing, and review of customer feedback. Randomly sample a few percent of completed tasks for human audit, and compare the audit result with the agent’s own success flag. Disagreement between the two is your best early warning of silent failure. Customer-reported reopens and refunds provide a second, delayed signal that should feed back into the evaluation set. Publish a clear definition of your resolution rate and measure it the same way every month. Consistency matters more than a flattering number, because enterprise buyers will ask for the method.

Security, Tenant Isolation and Compliance

Turning to security, an agent that can act on customer systems is a high-value target. Give each agent a scoped, temporary, and auditable identity instead of letting it inherit a human’s account access. Citi Ventures makes exactly this recommendation for agent identities, along with task-scoped permissions and real-time policy enforcement. Store tenant credentials in a secrets manager, issue short-lived tokens per task, and revoke them when the task ends. Prompt injection remains a practical threat, because untrusted text in an email or web page can instruct the agent to misuse a tool. Treat every retrieved document as hostile input and keep sensitive tools behind explicit approvals.

Tool servers add their own risks, which the guide on MCP server security risks covers in detail, including over-broad permissions and untrusted server code. Compliance work should begin before the first enterprise deal, since security questionnaires will ask about data residency, retention, and subprocessors. Decide how long you keep prompts and outputs, and let customers delete their data on request. Encrypt data at rest and in transit, and isolate logs so one tenant’s content never appears in another’s debugging session. Document these controls in a security overview that your sales team can share. A short, honest document often shortens procurement more than a long marketing deck.

Putting a Pilot in Front of Your First Customers

Next, take the agent from internal tests to a supervised pilot with two or three friendly customers. Choose accounts with enough volume to produce statistically meaningful results within a few weeks. Agree on the outcome definition, the price, and the escalation path in writing before the first task runs. Offer a discounted or free pilot period in exchange for data access, weekly feedback, and a case study if results are good. Keep a human in the loop for every task at first, then reduce review as the audited success rate stabilizes. The goal is to learn your real resolution rate and cost, not to maximize early revenue.

A supervisor role turns a pilot into an operating model. The article on the agent supervisor role and responsibilities describes a person who monitors agent queues, reviews exceptions, and tunes instructions. In a small company that person might be you, and in a larger one it is a dedicated operations hire. Their dashboard should show open tasks, failures by category, cost per task, and customer sentiment. Weekly reviews of failure categories usually reveal two or three fixable causes that account for most errors. Fixing those causes raises the resolution rate faster than switching models.

Customer onboarding should be repeatable and documented from the very first pilot account. Provide a checklist covering data sources, tool permissions, escalation contacts, brand voice, and success metrics. Connect integrations through scoped credentials that the customer can revoke at any time. Run a shadow mode for a few days in which the agent drafts answers but humans send them, then compare quality. Share a weekly report that shows tasks completed, resolution rate, and estimated hours saved. Customers who see these numbers every week tend to trust the product more than customers who must ask for them.

Ethics and Accountability When Agents Act for Customers

Looking at the ethics of selling autonomous work, accountability comes first. When an agent acts for a customer, someone must own the consequences of a wrong refund, a leaked record, or a misleading message. Contracts should state plainly who is responsible for what, and the vendor should accept responsibility for the agent’s behavior within its defined scope. Disclose to end users when they are interacting with an automated agent, and offer a clear route to a human. Enterprise agent governance tools, including Microsoft Agent 365, aim to make this oversight practical for large organizations. Keep an audit trail that lets you reconstruct why the agent did what it did.

Labor impact is the second ethical question, and it deserves honest treatment. Selling agents that replace human tasks displaces workers in the customers’ organizations, even when the customer frames the change as redeployment. Vendors can reduce harm by designing agents to handle repetitive volume while routing sensitive or emotional cases to people. Help customers plan retraining and role changes instead of marketing headcount reduction as the main benefit. Be transparent about error rates, because customers and their end users bear the cost of mistakes. A business built on trust lasts longer than one built on inflated claims.

Risks and Where the Model Falls Short

Despite the opportunity, the risks facing agent vendors are both substantial and quite specific. Gartner estimates that only about 130 of the thousands of agentic AI vendors are real. It also expects over 40 percent of agentic projects to be cancelled by the end of 2027. The cancellations stem from escalating costs, unclear business value, and inadequate risk controls, which map directly onto the problems this guide addresses. Margin risk appears when model prices, usage, or failure rates move against you. Revenue risk appears when customers dispute what counts as a resolution. Reputation risk appears when one agent mistake reaches a customer’s customer. List each risk with an owner and a metric before launch.

Platform dependence is the structural risk that many founders underestimate. If your agent runs on one model provider and one cloud, a price increase, outage, or policy change lands directly on your margin. The analysis of vendor lock-in in agentic AI platforms explains how proprietary orchestration, memory, and tool formats make switching expensive. Mitigate this by keeping prompts, tool schemas, and evaluation sets portable. Maintain a tested fallback model for every critical customer workflow in production. Negotiate committed-use discounts only after you understand your steady-state volume.

Outcome pricing carries one more risk that deserves its own mention: adverse selection and gaming. Customers may route their hardest cases to your agent while keeping easy cases in-house, which lowers your resolution rate and raises your cost. Customers can also influence resolution signals, for example by closing tickets quickly to reduce charges. Contract language should cover minimum volumes, dispute windows, and audit rights. Limits on liability are also needed, because a single bad action can cost more than months of fees. Insurance and clear indemnities belong in the plan for larger accounts.

The Future of Agent-as-a-Service Businesses

Looking ahead, the likeliest change is that outcome pricing becomes ordinary and then fades into the background. A SaaStr analysis of HubSpot’s repricing argues that as resolution rates rise, the gap between per-use and per-resolution pricing shrinks toward zero. Its author bets that per-resolution pricing will be a footnote in most categories within two to three years. If that happens, differentiation shifts from the pricing model to the quality of the outcome. Vendors will then compete on reliability, integration depth, and customer trust. Builders should therefore invest in measurable quality starting right now.

Costs will keep moving, which rewards businesses that pass savings through selectively. The discussion of generative AI cost per token trends frames token price as a budget line to revisit regularly rather than a fixed input. Model prices have generally trended downward, which widens your margin if your prices stay put and invites competitors to cut theirs. Plan for a world in which today’s 99 cent resolution is tomorrow’s 50 cent resolution. Your defensibility then depends on data, workflow depth, and customer relationships rather than on model access. Reinvest part of the savings into evaluation, integrations, and support.

Marketplaces and agent-to-agent commerce are the third trend to watch. Marketplaces may offer a distribution channel that shortens the path from launch to first customer. Agents may eventually buy services from other agents, which will require machine-readable pricing, identity, and settlement. Standard protocols for discovery and payment are still immature, so early adopters should expect churn in the tooling. The practical advice for anyone studying how to build an agent-as-a-service business model with LLMs is to keep metering and identity layers clean, since they underpin any marketplace listing. The chart below compares per-unit prices and resolution rates across vendors today.

How to Build an Agent-as-a-Service Business Model With LLMs, Step by Step

Building on the architecture, pricing, and reliability decisions above, the seven steps below turn them into a working pilot. Each step produces an artifact you can test, so progress is visible rather than assumed. The code uses Python and the OpenAI Agents SDK for the agent loop, plus plain Python for tenants, metering, and evaluation. Adapt the snippets to your stack, since the structure matters more than any single library. Run every command in a virtual environment and keep API keys in environment variables, never in source files. The steps assume a support-resolution agent, but the same pattern fits invoice matching or ticket triage.

Step 1 – Write the outcome contract

Start by writing down exactly what your agent promises to deliver and how you will know it succeeded. A one-page outcome contract should name the job, the definition of a resolution, the escalation rules, the price per outcome, and the monthly cap. For a support agent, a resolution might mean that the customer confirmed the answer or sent no follow-up within 72 hours. Writing this first prevents the most common dispute in outcome pricing, which is disagreement about what counts. It also becomes the specification for your evaluation set in Step 5 and your meter in Step 4. Store the contract as structured data so the same file drives billing, evaluation, and reporting.

{
  "job": "support_resolution",
  "resolution_definition": "customer confirms answer or sends no follow-up within 72 hours",
  "escalation": "handoff to human queue when confidence is low or action is irreversible",
  "price_per_resolution_usd": 0.99,
  "monthly_cap_usd": 5000,
  "dispute_window_days": 14
}

Share the contract with the pilot customer and ask them to mark anything ambiguous. Pro tip: include two or three worked examples of borderline cases, because examples settle arguments faster than definitions do. Version the file and record which version applied to each billed task. That small habit makes later audits, disputes, and refunds much more straightforward. Revisit the contract after the pilot, once real data shows where the definition was too loose or too strict.

Step 2 – Build the agent with scoped tools

Create the agent with a short instruction, a small set of tools, and an explicit step limit. The snippet below uses the OpenAI Agents SDK documentation as its reference, which describes agents as language models configured with instructions and tools, executed by a runner. Install the package with pip and set your API key as an environment variable before running anything. Each tool is an ordinary Python function with type hints and a docstring, which the SDK converts into a schema for the model. Keep tools narrow, such as looking up an order or drafting a reply, instead of exposing a generic database query. Limit the agent to about 6 turns so a loop cannot run away and burn budget.

python3 -m venv .venv && source .venv/bin/activate
pip install openai-agents stripe
export OPENAI_API_KEY="your-key-here"

from agents import Agent, Runner, function_tool

@function_tool
def lookup_order(order_id: str) -> str:
    """Return the status of an order for the current tenant."""
    return f"Order {order_id}: shipped, arriving in 2 days"

support_agent = Agent(
    name="SupportResolver",
    instructions="Resolve the customer's issue using the tools. If unsure, escalate.",
    tools=[lookup_order],
)

result = Runner.run_sync(support_agent, "Where is order 1042?", max_turns=6)
print(result.final_output)

Run the script and confirm that the agent calls the tool and returns a sensible answer. Then add one deliberately hard case, such as a request that needs a refund the agent is not allowed to issue. The correct behavior in that situation is to escalate, not to improvise. Pro tip: write that escalation case into your tests now, because escalation logic is the first thing to erode when prompts are edited later. Capture the full trace of each run, because the trace shows which tool calls drove the cost. The SDK includes built-in tracing for exactly this purpose, so you do not need extra tooling.

Step 3 – Add tenant context and isolation

Wrap every agent run in a tenant context so that tools, credentials, and memory are always scoped to one customer. The simplest pattern passes a tenant object into the tool layer and refuses to execute when it is missing. Each tenant record holds its own credentials reference, price plan, and monthly cap. Load secrets from a secrets manager at call time rather than keeping them in process memory between requests. Create at least 2 test tenants and add a cross-tenant test that tries to read another tenant’s order and asserts that it fails. Run that test in continuous integration on every commit so an isolation regression never reaches production.

from dataclasses import dataclass

@dataclass(frozen=True)
class Tenant:
    tenant_id: str
    stripe_customer_id: str
    monthly_cap_usd: float
    allowed_tools: frozenset

ORDERS = {("acme", "1042"): "shipped", ("globex", "1042"): "delayed"}

def lookup_order_for(tenant: Tenant, order_id: str) -> str:
    if "lookup_order" not in tenant.allowed_tools:
        raise PermissionError("tool not enabled for tenant")
    return ORDERS[(tenant.tenant_id, order_id)]

acme = Tenant("acme", "cus_123", 5000.0, frozenset({"lookup_order"}))
assert lookup_order_for(acme, "1042") == "shipped"

Decide now whether tenants share one deployment or receive dedicated ones, because that choice changes your cost structure. Pooled deployments keep infrastructure cost low and releases simple, while siloed deployments cost more and suit regulated customers. Keep the tenant identifier in every log line and metric label so you can answer which customer caused a given cost spike. Rate limit per tenant to protect the pool from noisy neighbors. Document the isolation model in plain language for security reviews.

Step 4 – Meter every billable outcome

Emit exactly one meter event whenever the outcome contract says a billable outcome occurred, and never before. Stripe’s meter events API takes an event name, a customer identifier, and a numeric value, and it accepts an identifier that makes retries safe. Use a deterministic identifier built from the tenant and task, so a retried request cannot create a second charge. Stripe also documents a limit of 1,000 live-mode calls per second per account, so batch or pre-aggregate if you expect higher volume. Create the meter once in the dashboard or API with an event name such as support_resolution. Remember that Stripe now recommends Metronome for new usage-based integrations with complex needs, so compare options before committing.

import stripe

stripe.api_key = "sk_test_replace_me"

def record_resolution(tenant, task_id: str) -> None:
    stripe.billing.MeterEvent.create(
        event_name="support_resolution",
        payload={"value": "1", "stripe_customer_id": tenant.stripe_customer_id},
        identifier=f"{tenant.tenant_id}:{task_id}",
    )

curl https://api.stripe.com/v1/billing/meter_events \
  -u "$STRIPE_SECRET_KEY:" \
  -d event_name=support_resolution \
  -d "payload[value]=1" \
  -d "payload[stripe_customer_id]=cus_123"

Keep your own append-only log of every meter event, and reconcile it against Stripe’s usage summaries each day. Stripe processes events asynchronously, so invoices may lag recent events by a short time. Alert on rejected events, which Stripe reports through error events such as invalid timestamps or missing customers. Pro tip: send the event only after your own state machine confirms the outcome, not when the model merely claims success. A premature event is revenue you may have to refund.

Step 5 – Build an evaluation harness

Assemble a golden set of at least 50 real, anonymized cases with the correct outcome labeled for each. Run the agent over the whole set and compute the resolution rate, the cost per attempt, and the escalation rate. The method matters as much as the number, so write down how a case counts as resolved and keep it identical across runs. For free-text answers, a stronger model acting as a judge can score quality against a rubric, as described in this guide to evaluating LLM outputs with LLM-as-a-judge. Calibrate the judge against human labels on a sample before trusting it. Block any release that lowers the resolution rate or raises cost per attempt beyond a threshold you set in advance.

import json

def evaluate(agent_runner, cases):
    resolved, cost = 0, 0.0
    for case in cases:
        outcome = agent_runner(case["input"])
        cost += outcome["cost_usd"]
        if outcome["status"] == case["expected_status"]:
            resolved += 1
    n = len(cases)
    return {
        "resolution_rate": resolved / n,
        "cost_per_attempt_usd": cost / n,
        "cost_per_resolution_usd": cost / max(resolved, 1),
    }

cases = [json.loads(line) for line in open("golden_set.jsonl")]

Re-run the harness whenever you change a prompt, tool, or model, and store the results with the version identifiers. A simple table of results over time shows whether quality is drifting. Add adversarial cases that try prompt injection and cross-tenant access, since these failures are costly. Compare your measured resolution rate with the break-even rate from the unit economics section, and do not launch if the margin of safety is thin. Treat the harness as production code, with reviews and versioning like any other service.

Step 6 – Set price guardrails and spending caps

Translate your measured numbers into a price and a set of protective limits. Start from cost per resolution and add the margin you need after support and infrastructure. Then compare the result with market anchors such as 99 cents at Intercom and 50 cents at HubSpot. Then add a monthly cap per tenant and an alert at 80 percent of the cap so customers never face surprise invoices. Add a per-task budget that stops the agent when token and tool spend exceed a multiple of your expected cost, for example 5 times. Expose these settings as configuration so you can adjust them without redeploying code. Review every one of these figures after each pilot week.

PRICING = {
    "price_per_resolution_usd": 0.99,
    "margin_floor": 0.60,
    "per_task_budget_usd": 0.60,
    "alert_at_fraction_of_cap": 0.8,
}

def price_is_safe(cost_per_attempt: float, resolution_rate: float) -> bool:
    cost_per_resolution = cost_per_attempt / max(resolution_rate, 0.01)
    margin = 1 - cost_per_resolution / PRICING["price_per_resolution_usd"]
    return margin >= PRICING["margin_floor"]

print(price_is_safe(0.12, 0.65))

Test the guardrails by simulating a traffic spike and a runaway loop in staging. Confirm that the cap triggers, the alert fires, and the agent degrades gracefully to human handoff. Pro tip: log every cap event with the tenant identifier, because those events usually signal either an attack or a customer ready for a larger plan. Document the behavior in your terms of service so billing limits are never a surprise. Share the results with your finance contact so the cost model and the invoices tell the same story.

Step 7 – Launch a supervised pilot

Launch with two or three pilot customers, a human review step on every task, and a weekly review meeting. Track four numbers each week: resolution rate, cost per resolution, escalation rate, and customer-reported errors. Compare the audited success rate with the agent’s own success flag to detect silent failures. Expand autonomy only after 4 consecutive weeks in which the audited rate stays above your threshold. Convert the best pilot into a written case study with the customer’s permission, because evidence is your strongest sales asset. Then widen the rollout one customer cohort at a time, keeping the same weekly review ritual.

pilot:
  customers: 3
  human_review: all_tasks
  weekly_metrics: [resolution_rate, cost_per_resolution, escalation_rate, reported_errors]
  promote_to_autonomous_when:
    consecutive_weeks_above_threshold: 4
    audited_resolution_rate_min: 0.70

Plan for the first serious incident before it actually happens to you. Write a short runbook that says how to pause the agent for one tenant or for all tenants, who contacts the customer, and how credits are issued. Practice the pause in staging so nobody hesitates during a real problem. After any incident, add the failing case to the golden set so it can never return unnoticed. Finally, schedule a quarterly pricing review, since model costs and competitor prices change quickly.

Key Insights

• Gartner forecasts that over 40 percent of agentic AI projects will be cancelled by the end of 2027. Cost discipline and proven value are therefore the first filters for any new agent business.
• Gartner estimates that only about 130 of the thousands of agentic AI vendors are genuine, so buyers reward vendors who publish measurable results.
• Intercom prices Fin at 99 cents per resolution and reports that the agent resolves more than one million customer conversations every week, proving that outcome pricing can scale.
• HubSpot cut its AI customer agent price from 1 dollar per conversation to 50 cents per resolved conversation, which shows how quickly outcome-based pricing is spreading among incumbents.
• Salesforce prices an Agentforce action at 20 Flex Credits, or 10 cents, with credits sold at 500 dollars per 100,000, so enterprise buyers can model agent cost per action.
• Stripe limits live-mode meter events to 1,000 calls per second per account, so high-volume agent vendors must pre-aggregate usage or use the higher-throughput streaming endpoint.
• Anthropic documents that cache reads cost 0.1 times the base input price for most models, making prompt caching one of the cheapest ways to protect agent gross margin.
• Klarna's assistant handled 2.3 million conversations in its first month, equal to about 700 full-time agents, while resolution time fell from 11 minutes to under 2 minutes.

Taken together, these data points describe a market that is real but unforgiving. Vendors such as Intercom, HubSpot, and Salesforce have converged on pricing tied to units of completed work, which makes cost per outcome the number that matters most. Gartner's cancellation forecast and its agent-washing estimate show that buyers will punish products that cannot prove value. Billing and caching documentation from Stripe and Anthropic shows where the practical levers sit, namely accurate metering and lower input cost. Klarna's results show the size of the labor pool being addressed, which explains why the category attracts so much capital. A builder who combines a narrow job, honest measurement, and disciplined unit economics is positioned to capture value without joining the failures.

Dimension	Seat license	Usage-based	Outcome-based	Hybrid
Best for	Tools that humans operate directly	Workloads with high variance in volume	Verifiable, repeatable jobs with a clear definition of done	Enterprise deals that need budget certainty
Revenue predictability	High, because seats change slowly	Low to medium, because it follows customer volume	Low until resolution volumes stabilize	Medium to high, anchored by the platform fee
Customer risk	Pays regardless of results	Pays for attempts, including failed ones	Pays only for successful outcomes	Limited by the platform fee and spending caps
Vendor risk	Heavy users erode margin	Revenue tracks cost closely	Failed attempts are unpaid cost	Shared between fixed and variable charges
Metering complexity	Minimal	Moderate: tokens, actions, or conversations	High: needs a precise success definition	High: tracks both usage and outcomes
Typical billing unit	Per user per month	Per token, action, or conversation	Per resolution or completed task	Platform fee plus a bucket and overage
Published example	Classic SaaS subscriptions	Salesforce Flex Credits at 10 cents per action	Intercom Fin at 99 cents and HubSpot at 50 cents per resolution	Annual resolution buckets for Fin
Sales motion	Simple procurement	Pilot first, then ramp with volume	Requires trust and a written outcome agreement	Negotiated enterprise contract

Agent-as-a-Service in Practice: Three Working Examples

Beyond the theory, three vendors show how agent pricing works in practice and where it strains. Each example below describes what the vendor implemented, a measurable outcome, and a limitation worth noticing. The examples focus on pricing and packaging decisions because those are the choices a new entrant must make first. The case studies that follow go deeper into operating results. Reading them together shows the range of approaches from per-resolution to per-action billing.

HubSpot's Per-Resolution Repricing

HubSpot implemented a new pricing model for its Breeze Customer Agent in April, replacing a charge of 1 dollar per conversation with 50 cents per resolved conversation. The change means customers pay only when the agent actually closes an issue, which removes the risk of paying for failed attempts. According to SaaStr's analysis of the repricing, HubSpot's agent resolves about 65 percent of conversations across more than 8,000 customers. Intercom's Fin averages 66 to 67 percent in the same analysis, up from roughly 27 percent at launch. The same analysis notes that HubSpot's price is the lowest in the market, which gives it a wedge with smaller businesses. The approach has limits, because per-resolution bills vary from month to month and finance teams struggle to budget for them. The author also argues that the pricing model matters less as resolution rates rise, and calls the move more expected than bold.

Salesforce Agentforce Flex Credits

Salesforce rolled out Flex Credits for Agentforce in May 2025, with credits sold in packs priced at 500 dollars per 100,000. Each action an agent performs consumes 20 credits, or 10 cents. The company positioned this beside its existing price of 2 dollars per conversation, and Salesforce's announcement says thousands of organizations had already used that option. The same release cites survey data showing that 90 percent of CIOs say managing AI costs limits their ability to drive value, which explains the push for flexible pricing. The approach gives buyers a single metered currency for many agent actions, but an action is a technical unit rather than a business outcome. A customer still has to estimate how many actions a resolved case takes, so total cost remains hard to forecast. The release names customers but offers no quantified results for any of them, which limits what it proves.

Zendesk's Outcome-Based Pricing

Zendesk adopted outcome-based pricing for its AI agents, billing only for issues that the AI resolves autonomously and including a starter level of usage at no extra cost. The company says it is the first in customer experience to offer this model, and it projects that soon up to 80 percent of customer interactions will be automated. Zendesk's announcement also describes an in-product dashboard that shows resolution usage and automation rate, which gives customers the visibility needed to trust the bill. The projection is a forecast without a published method, so it should be read as ambition rather than evidence. The page also omits price points, the size of the starter allowance, and the exact criteria for a resolved issue. Those gaps are a real limit for buyers comparing vendors, and they illustrate why you should publish your own definitions. Even so, the move shows that a large incumbent considers outcome billing ready for mainstream plans.

Lessons From Three Agent Businesses at Scale

Stepping back from pricing mechanics, three operating stories show what happens when agent businesses meet real volume. Each one pairs a concrete problem with a deployed solution and a measurable result, followed by an honest limitation. They come from a vendor that sells agents, a second vendor serving large enterprises, and a company that deployed an assistant on itself. The common thread is that outcomes were measured before they were priced. Reading them together shows both the upside and the work required to reach it. The lessons feed directly into the pilot and risk sections of this guide.

Case Study: Intercom's Fin and the 99 Cent Resolution

Intercom faced a pricing problem when it launched Fin in 2023, because customers hesitated to pay for an AI agent that might not work and trust in AI was low. Per-seat pricing did not fit a product that replaces human work, and charging per conversation did not reflect delivered value. The adjusted pricing took about three months to launch on Stripe Billing and charges 99 cents per resolution. A resolution counts when the customer confirms the answer or asks for no further help. According to Stripe's customer story, Fin generated tens of millions of dollars in revenue in under a year and now resolves more than one million customer conversations every week. Customers can shift budget from seats to resolutions and buy annual buckets that give them spending certainty. The vendor-published story gives no resolution rate, customer count, or margin, and its figures are self-reported and unaudited.

Independent commentary adds useful context to those vendor-reported numbers about Fin. SaaStr's review of per-resolution pricing reports that Fin's average resolution rate reached 66 to 67 percent, up from about 27 percent at launch. That improvement shows how much of the revenue story depends on steady quality gains. The same review raises a concern that per-resolution bills are unpredictable, with some Intercom customers asking for resolution caps or flat-rate tiers. That criticism still applies to any outcome-priced agent, including yours. The practical lesson is to pair outcome pricing with budget controls such as caps and annual buckets.

Case Study: Sierra's Enterprise Agent Platform

Sierra set out to solve a problem that large consumer brands share: handling millions of service conversations with accurate, on-brand agents that are safe to connect to core systems. The company built an agent platform that charges by conversation volume for routine interactions and by resolved outcome for more complex inquiries. According to Sacra's profile, customers include WeightWatchers, SiriusXM, Sonos, ADT, and Nordstrom, and enterprise clients reportedly see 70 percent containment with satisfaction scores above 4.5 out of 5. Sacra estimates annualized revenue of about 400 million dollars in October 2026, up from 26 million at the end of 2024. The profile also reports a 950 million dollar Series E at a 15.8 billion dollar valuation in May 2026. These revenue figures are estimates, and the profile warns that its information is not guaranteed to be accurate or complete.

That model comes with well-documented trade-offs that any new entrant should study carefully. Sacra notes that Sierra's approach requires dedicated AI engineers for each customer, which may limit scalability and compress margins compared with turnkey software. The company also disclosed a coordinated attempt by bad actors to jailbreak more than a dozen customer agents, and a Gap.com agent answered off-scope questions because of a misconfigured guardrail. Containment is also not identical to full resolution, since the profile does not define the term. For a new entrant, the lesson is that high-touch deployment can win large accounts but constrains growth, so productizing onboarding early matters.

Case Study: Klarna's Customer Service Assistant

Klarna needed to handle a very large volume of customer service chats across many markets without letting wait times and costs grow in proportion. The company launched an AI assistant and reported that in its first month the assistant handled 2.3 million conversations, about two-thirds of all service chats. Klarna's announcement says the work equaled that of roughly 700 full-time agents, cut resolution time from 11 minutes to under 2 minutes, and operated in more than 35 languages. Klarna estimated that the assistant would improve profit by 40 million dollars in 2024. The company says customer satisfaction was on par with human agents, but it gives no numeric score. The company published these figures itself, and they describe the first month rather than long-term performance.

The case is instructive for agent vendors because Klarna is the buyer-side proof of the value pool they target. A vendor selling to a company like Klarna competes with the economics of an in-house build, so the price per outcome must beat the internal cost per conversation. The limits of the evidence matter too, since the release is a company announcement with self-reported numbers and no independent audit. A cautious reading treats it as a ceiling on potential savings, not a guaranteed result. Your pilot data should replace any borrowed benchmark as soon as it exists.

Common Questions About Building an Agent-as-a-Service Business Model With LLMs