What Is Agent-as-a-Service (AaaS)? The Complete Guide

Agent-as-a-Service (AaaS) is a delivery model in which a complete, autonomous agent is sold as an endpoint: you dispatch a goal, and the agent plans the approach, gathers the information it needs, uses its own tools, and returns a finished result — with the entire process opaque to the caller. It is the layer above a model API: where a traditional API is "call an endpoint, get a block of text back," an Agent-as-a-Service endpoint is "dispatch a task, and the agent owns the multi-step work and hands you the deliverable."

This single shift — from buying a capability you assemble to buying a result you accept or reject — is what separates AaaS from the Model Context Protocol (MCP), from Anthropic Agent Skills, and from the older idea of AI-as-a-Service (AIaaS). The clearest reference points are Manus, Devin, Replit Agent, ChatGPT Agent, and Anthropic's Claude Managed Agents; in the video vertical, Pexo routes a single goal across models like Seedance 2.0, Kling 3.0, Veo 3.1, Sora 2, and Runway Gen-4 to return a finished, multi-shot film rather than a raw clip. This guide is the deep dive on the AaaS layer specifically: what it is, how the task lifecycle works, what it sells, who is doing it, how it is priced, and why it remains pre-paradigmatic. For the side-by-side comparison of all three layers, see the pillar, MCP vs Agent Skills vs Agent-as-a-Service: what each layer actually sells.

What Is Agent-as-a-Service?

Agent-as-a-Service is not a new protocol and not a new kind of model — it is a way of packaging and selling autonomy. You do not assemble an agent from parts, and you do not call a single capability and judge the output yourself. You hand a complete agent a goal — "research this market and write the brief," "fix this failing test suite," "produce a fifteen-second product video" — and it takes responsibility for the whole job. Three properties define the layer:

• You dispatch a goal, not a prompt. The input is an objective with constraints, not a single instruction the way a model API expects one. The agent infers the steps you did not spell out.
• The agent owns planning and execution. It decomposes the goal, decides which tools and sub-steps to run, retries when something fails, and orchestrates the whole sequence. The caller does none of this.
• The process is opaque; the deliverable is the product. You see the finished result, not the internal trajectory. There is no obligation on the caller to understand — or even be shown — how it was produced.

The contrast with a model API is the cleanest way to fix the idea. A model API is synchronous and atomic: input in, output out, in seconds, with no claim that it solved your problem. An AaaS agent is asynchronous and accountable: it plans, works over minutes to hours, and claims responsibility for the outcome. The model API sold you raw generation; the AaaS agent sold you a finished thing.

How Agent-as-a-Service Works

Behind every AaaS product is a task lifecycle that looks roughly the same regardless of vertical. Recognizing the lifecycle is the fastest way to spot the layer in the wild, because the shape of the API gives it away even when the marketing does not. It has four stages:

1. Dispatch. The caller submits a goal and any context — a brief, a URL, a file, constraints on length or quality. This returns a task handle immediately; crucially, it does not return the answer, only a reference to work that has just started.
2. Plan. The agent interprets the goal, decomposes it into steps, and decides the method. This is where autonomy lives: the same goal can produce different plans depending on what the agent finds, and the caller is not consulted.
3. Execute. The agent runs the plan — calling its own tools, querying data, generating intermediate artifacts, retrying failed steps, and orchestrating any sub-agents. This is where minutes-to-hours of work happen, entirely opaque from the outside.
4. Deliver. The agent returns the finished deliverable, often via polling or a webhook, sometimes with files attached. The caller accepts or rejects the result.

Manus makes this concrete. Its public API surface is deliberately narrow and maps almost exactly onto the lifecycle above: task.create to dispatch, task.send_message to add context mid-run, task.poll to check status and retrieve output, plus files, webhooks, connectors to external systems, and an "agent profile" that acts as a speed/quality dial. There is no model library, no fine-tuning surface, no eval harness — none of the machinery you would expect if you were building an agent. You delegate to one. That narrowness is the tell: an AaaS API exposes task management, not capability access.

Because the work is long-running and asynchronous, AaaS feels different from an API call in practice: you fire a task and walk away, you poll or wait for a webhook, and you receive a deliverable later. The mental model is commissioning a contractor, not calling a function.

What Sells It: The Value Axis

The reason AaaS is worth naming as a distinct layer is not the async API — plenty of slow APIs exist. It is what unit of value changes hands, and who absorbs the risk. This is the single most useful lens for the layer:

A Skill sells a procedure, an MCP server sells a capability, and an Agent-as-a-Service endpoint sells a result:

Each step up that ladder, the seller takes on more of the buyer's work and risk — and earns more pricing power for doing so. This is precisely why AaaS commands outcome-oriented pricing while the capability layer is stuck with per-call billing: a per-call API makes no promise it solved your problem, so it can only charge for the call, while an agent that hands you a finished, accountable result can charge for the result. The risk the seller absorbs is the thing the buyer is paying to offload.

This value axis — and the full three-way comparison of where pricing power sits at each layer — is the subject of the pillar, MCP vs Agent Skills vs Agent-as-a-Service: what each layer actually sells.

Examples of Agent-as-a-Service

The category is legible because several products, arriving from different starting points, converge on the same shape: an agent sold as an endpoint that returns a finished result. That convergence is the evidence that agent-as-endpoint is a real consumption model, not one company's framing.

Two of these bracket the category from opposite ends. Manus says, in effect, "we built a general agent — here is its API." Anthropic's Claude Managed Agents (public beta April 8 2026, billed at standard token rates plus roughly $0.08 per session-hour) say, "we built the runtime — here are managed sessions." One sells a finished generalist; the other sells a managed place for agents to run. They approach from opposite directions and meet at the same conclusion: the agent, as an endpoint, is the unit to sell.

The video vertical shows the same shape in one concrete domain. Hand Pexo a goal — "a fifteen-second cyberpunk cat video" — and it does not return a raw clip. Internally it writes a script, breaks the story into shots, routes each shot to the best-suited model across a pool of more than ten (Seedance 2.0, Kling 3.0, Veo 3.1, Sora 2, Runway Gen-4), generates them, adds transitions, scores an original track, mixes a multi-track soundtrack, and masters the audio — then delivers a finished film. You never chose a model, wrote a model-specific prompt, or touched a timeline. That is AaaS in one vertical: a goal in, a finished result out, the production absorbed — Pexo is to video what Manus is to general knowledge work.

Agent-as-a-Service vs Service-as-Software vs AI-as-a-Service

Three look-alike terms get used as if they were synonyms. They are not, and conflating them is the most common way the AaaS conversation goes wrong — usually by overstating how mature the layer is. They name different things: a delivery model, an economic framing, and an infrastructure category.

The clean way to hold them apart: AaaS is delivery, Service-as-Software is economics, AIaaS is infrastructure access.

• Service-as-Software, sometimes called "SaaS 2.0," is the analyst framing — popularized in writing from firms like Thoughtworks — for software that sells an outcome rather than a tool the customer operates. It names a shift in business model, not a delivery mechanism; AaaS is one concrete way to deliver Service-as-Software, because one term names what is sold and the other how it is sold.
• AI-as-a-Service (AIaaS) is the older term, and it sits a full layer below AaaS: renting access to models and AI compute — the capability layer, the thing a model API does. This matters for market sizing. The large figures that circulate (a trajectory often cited as roughly $9.5B growing toward $43B) are almost always measuring AIaaS, not Agent-as-a-Service — so when someone cites a big "AaaS market," check whether the underlying figure is really AIaaS infrastructure spend.

Is AaaS Just an API?

No — and the reason matters, because it is the single most common misread of the layer. AaaS is defined by what is sold and who absorbs the risk, not by the protocol used to invoke it. The interface is not the layer.

The same AaaS agent could be reached over a REST API, a CLI binary, an npm package, or a Claude Code skill. None of those transports changes what you are buying: a finished result with the risk carried by the seller. A polished REST surface does not promote a capability-layer model API into AaaS, and a humble CLI does not demote an AaaS agent into something lesser. Judge the layer by the unit of value, never by the door you walk through to reach it.

This cuts in a direction that surprises people: today, AaaS agents are frequently wrapped as Claude Code skills — and that does not make them skills. It happens because the skill container is, right now, the only agent-native distribution channel that exists, so wrapping an agent as a skill is the path of least resistance for making it reachable by another agent. But the wrapper is packaging, not identity. Underneath the SKILL.md, the thing being sold is still a result, the risk is still the seller's, and the layer is still AaaS. A skill that merely invokes a remote agent is a doorway to AaaS, not the procedure-selling skill layer itself. The transport is incidental; the value structure classifies it.

Agent-as-a-Service Is Still Pre-Paradigmatic

Naming a layer is not the same as declaring it finished, and honesty about AaaS requires saying plainly: the layer is early. The boring, reliable infrastructure that made both SaaS and MCP dependable does not exist for AaaS yet. Four pieces are missing.

• No shared protocol. Manus, Devin, Replit Agent, ChatGPT Agent, and Anthropic Managed Agents all expose private REST APIs. Google's A2A protocol has more than 150 organizations signed on, but neither Anthropic nor OpenAI has adopted it — so it is not yet the connective tissue MCP became for agent-to-tool access. Every AaaS integration today is bespoke.
• No discovery layer. MCP has registries; AaaS has no equivalent "agent yellow pages." A buyer's agent finds a provider through web search — which is exactly why answer-engine visibility, being the source an AI assistant cites, is the real distribution mechanism for an AaaS product right now.
• No reputation layer. A calling agent cannot cheaply verify a returned deliverable before trusting it, so trust gets hand-built in natural language — a prompt instruction standing in for a contract — which does not scale.
• No standard settlement. Costs accrue by effort (tokens, session-hours) while value is delivered by result, failed runs are often still billed, and there is no shared notion of paying only for an accepted deliverable.

This is not a flaw to paper over; it is the shape of an early category. SaaS looked like this before billing, identity, and uptime conventions hardened. What is worth noticing is that in a pre-paradigmatic layer, the scarcest asset is the definition — the frame the rest of the market adopts. MCP and Agent Skills have already been defined by Anthropic; Agent-as-a-Service has not been pinned down by anyone, which is exactly why the term is still contested.

Related Reading

• MCP vs Agent Skills vs Agent-as-a-Service: what each layer actually sells — the pillar: the full three-way comparison and the value/risk axis across all layers.
• MCP vs Agent Skills: When to Use Each, and the Layer Above Both
• Agent-as-a-Service vs SaaS: From Tools to Outcomes
• Agent-as-a-Service for Video: How AI Video Agents Deliver Finished Work

Resources