1 Problem

Businesses can build an agent that answers questions, but still have to solve continuous operation, customer isolation, costs, failures, and accumulated experience.

When businesses use agents to serve customers, the hard part is keeping them working reliably over time, beyond a single demonstration.

Customers buy an ongoing service

Imagine a shop owner who has given an agent the product information and checked its answers to common questions. The service still needs to be available when a customer asks about an order late at night; if the answer is wrong, the owner needs to trace what happened and take over.

Our view is that AI has lowered the cost of writing code and made software features easier to copy. Value that is harder to replace is moving toward continuous operation, reliability, and responsibility for results; software remains important, but customers buy the service it supports.

From internal use to customer service

An agent that works well for a business owner can become a repeatable service. An editing agent can work for other creators, just as a shop’s support agent can help its customers.

We expect agents to specialize because context has a capacity limit; context is the information an agent can read during a task. Under this view, an agent should do one specialty well and collaborate with others, rather than one general agent doing the whole business’s work.

After the owner goes offline

During internal trials, the owner can correct the agent at any time. In customer service, the platform must keep running without the owner, identify customers, separate costs, and provide a way to take over when something fails.

Updates must preserve experience and avoid interrupting work. Testing, operations, and long-term reliability require continuing work by a platform and an organization; one AI cannot be expected to handle all of it, and each business should not have to rebuild it.

Why separate tools are not enough

Traditional cloud services mainly provide resources for deploying programs and handling requests. Agents also need to retain work state, use tools, handle uncertain results, and preserve useful experience; model calls often use tokens, units for measuring the information a model processes.

A shop assembling these capabilities pays in three ways: time spent connecting suppliers and building an operating system, effort spent judging supplier quality and costs, and experience lost when work cannot be retained. Servers, model APIs, sandboxes, and search are useful components, but together they are not yet an agent service ready to operate as a business.

Comparison	Organized around program requests	Organized around agent work
State	The application separately stores state after a request	Task progress and work state must persist
Results	Execution follows specified logic	Uncertain results need checking and handling
Cost units	Primarily compute and other resources	Model token usage must also be measured
After the work	The application separately manages business experience	Reusable experience must accumulate
What is supplied	Program code	Responsibilities, behavior, rules, procedures, and experience
Platform responsibility	Provide an environment for programs	Connect execution, experience, and service management

The table compares platform responsibilities; it does not claim that programs cannot store state or that agents do not consume compute.

Who encounters the problem first

Independent developers, small and medium-sized businesses, and agent service companies need these capabilities more as they take responsibility for real customers. Model gateways connect several models through one entry point but still require supplier selection and management; hosting platforms and large clouds offer execution tools that businesses must organize into a service.

The gap we see is an agent-centered platform and an organization that handles this work through repeatable processes. The next chapter uses the same shop to show how the service would work.