When an Agent Needs to Be a Service, Not a Chat

One of the easiest mistakes in agent design is to treat every capable chat as a service.

A chat can be thoughtful. It can have useful history. It can even complete a difficult task. None of that means another person or agent should depend on it as a standing part of an operating system.

I learned this when management conversations started doing too much execution work. They were good at setting direction, accepting results, and discussing tradeoffs. They were a poor place to run a long piece of work that might need a callback, a retry, or a follow-up after the original request had moved on. A Practical Architecture for Reliable Multi-Agent Systems explains the wider role and return model behind that distinction.

The useful distinction is simple: a service has a job that other parts of the system can rely on. A chat is a place where work may happen. Sometimes those are the same thing. Often they are not.

This article focuses on the decision to give a role a continuing service identity instead of treating it as another conversation.

Take the quick test

Before making a standing agent, ask:

1. Will unrelated callers need to find this role again later?
2. Does the role need its own continuing context or interface?
3. Can work outlive the caller that starts it?
4. Does someone need to recover, inspect, or return the result after a failure?
5. Is the role different enough from its owner that a separate responsibility improves the result?

If the answers are mostly no, use a prompt, a short subagent, or a temporary worker. If they are mostly yes, a service may earn the extra state and operating care. When Agent Architecture Is Too Much puts that choice in the larger architecture decision.

Four work shapes solve different problems

The labels can vary, but I find four shapes useful:

There is also a smaller fifth shape: a short-lived subagent inside one active turn. It is useful when the parent can consume the result immediately. It does not need a public address, long-lived context, or a recovery path after the parent has gone away.

The error is not using one of these shapes. The error is asking one shape to do another shape’s job without giving it the necessary controls.

A management conversation should not become a worker

A manager needs room to think across the domain. It may review outcomes, decide which work matters, identify missing capabilities, and approve a change to the agent itself.

If that same conversation spends a long turn doing a deep source review, it becomes unavailable for new decisions. It also accumulates task-specific detail that makes the next management conversation harder to start cleanly. When the work finishes, it may be unclear whether the manager still owns a live obligation or merely has an old transcript.

That does not mean a manager can never do direct work. A small judgment call may belong there. The point is to notice when a recurring execution job has become a service concern.

In my system, the domain manager is deliberately separate from the operating project. The manager evaluates how the agent is performing and changes its charter, skills, workflows, or internal topology when the evidence supports it. The operating roles handle the domain’s current work.

That separation gives each context a cleaner purpose. It also makes it less tempting to turn a high-level review conversation into an overloaded dispatcher, worker, and final messenger.

A service has an identity outside one turn

Giving a role a name is not enough. A service needs operating commitments that survive one request.

At a minimum, I want to know:

• what job the role owns;
• which requests it accepts and what it must return;
• whether callers reach it directly or only through an owning role;
• which project, instructions, and source material shape its work;
• which model and reasoning profile fit its responsibility;
• how a request returns after the role finishes; and
• how to tell whether the live service matches its definition.

That is why I describe an agent endpoint as more than a chat window. It has a stable address, a defined role, a working context, an interface, and a current task identity. Those details make it possible to route work to the intended place, inspect what happened, and create a clean replacement later.

The source-controlled definition matters just as much as the running task. A role definition, bootstrap, model profile, and service interface explain how the endpoint should exist. The live registry binds that definition to the task currently doing the work. Neither one replaces the other.

Building One Agent from Coordinated Roles in Codex shows a practical example of that construction.

The role’s local instructions are part of that identity too. How to Layer AGENTS.md for Real Agent Work explains what belongs in them and what should live in linked runbooks or source guides.

A service needs an honest request

Once a role becomes a service, its callers need more than a vague instruction.

I want a request to make six things clear:

• the objective or decision the owner is being asked to make;
• the source material or exact places to inspect;
• the authority and limits that apply to the work;
• important non-goals or things the role must not change;
• the close condition: what would count as a useful return; and
• where the final result should go, including a stable identity for an accidental retry.

That does not mean every call needs a large form. A small, familiar request can supply most of this through its interface. The point is that a service should not need to reconstruct the whole contract from an ambiguous prompt.

This also separates the instruction from the evidence. The instruction says what the role should do now. A source pointer or work bundle tells it where to find the material. Sending a pile of documents as though it were the instruction gives the agent neither a clear task nor a clear record of what was requested.

The public address is not the domain brain

One public address makes an agent easier to use. A person should not need to know which internal role will research, test, or review a request.

But a public address becomes fragile when it also has to load every domain’s history, choose all internal work, wait for slow results, reconcile callbacks, and write the final answer. It turns into both a reasoning bottleneck and a liveness bottleneck.

The more useful split is:

public entry point
  -> accepts a known route and returns the result

semantic owner
  -> interprets the request, chooses work, and stands behind the answer

private specialist or temporary worker
  -> supplies a focused part of the work

The public entry point can stay fast and mechanical. The semantic owner has the domain context and authority to decide what the request means. Private roles remain internal, so a caller cannot bypass the owner that must integrate their work.

This is not bureaucracy for its own sake. It makes an ordinary question answerable: if a result is wrong or missing, did admission fail, did the owner make a poor decision, did a worker fail, or did delivery break?

Let software handle mechanics and agents handle judgment

A serious agent service usually needs some deterministic machinery around the model.

In my case, the Runtime records requests before work begins, applies duplicate controls, serializes use of persistent contexts, creates explicit callbacks, and exposes recovery. Those are mechanical duties. They benefit from predictable code and compact records.

The agent roles handle a different class of work: interpreting a request, deciding whether evidence is sufficient, selecting help, preserving caveats, and making a domain recommendation. Those are judgment duties.

Keeping the two separate prevents a tempting shortcut. A routing system may be able to send a request to an agent, but it should not silently become the authority that decides the agent’s answer. The agent may be able to return a recommendation, but it should not be responsible for inventing its own transport and recovery rules on every turn.

This is the small control-plane idea behind the architecture: code keeps the route and the record trustworthy; accountable roles decide what the work means.

Keep a specialist only when its context earns the cost

Persistent specialists are not automatically better than fresh workers.

A specialist earns its place when the same focused context returns often enough that rebuilding it on every request is wasteful or risky. A tooling diagnostician, evidence reviewer, or release-risk analyst may fit that pattern. The owner can ask for its focused judgment without giving that specialist public responsibility for the whole domain.

A temporary worker is usually better for a large one-off job. It can start in the right saved project, inspect the relevant repository or evidence, do concentrated work, and return a result. It does not need to carry that task’s history into unrelated requests.

There is a cost either way. Persistent roles can accumulate stale assumptions and require more operating care. Fresh workers need a clear prompt, the right project, and a way to return their work. Choose the shape that removes a real recurring problem, not the shape that sounds more agentic.

Make roles earn their continuing place

If a role becomes a service, define it explicitly. Give it a narrow job, an owner, an interface, a project context, a model profile, a return path, and an activation check. If its work can outlive the caller, it also needs the ticket, callback, and recovery controls described in Reliable Agent Work Needs Tickets, Locks, and Recovery.

That is the shift I care about: not more chats with more names, but a few roles that can be reliably found, used, developed, and held accountable.