When does an AI agent need a platform instead of a simple service?

Name the obligation before naming the platform

The useful starting question is what the service promises after it accepts work. A formatting assistant may promise a response within twenty seconds or an explicit failure. An investigation service may promise to retain a task overnight, resume after a deployment, and let an operator stop pending changes. Those promises create different engineering obligations even if both use the same model SDK.

Write the promise in user-observable terms. Then identify the component and team responsible for keeping it. A diagram containing a queue, database, and worker is incomplete until someone owns the cases where those components disagree.

Shared mechanisms have their own operating cost

A platform can reduce repeated implementation, but it also creates a dependency for every adopter. Its interfaces need compatibility rules, migrations, support, capacity, incident response, and an exit path. Centralizing a weak implementation merely distributes its failure more widely.

The economic comparison is repeated local work versus the full cost of providing a dependable shared capability. Five teams using different models is weak evidence for centralization. Five teams separately maintaining task admission, release attribution, and a staffed recovery console is a stronger signal, provided their requirements genuinely agree.

Two assistants with very different promises

Consider two hypothetical internal products. A writing assistant handles 300 requests per day, performs no external writes, and allows the user to retry a failed request. Existing authentication and request telemetry cover its operating needs. A conventional web service is a plausible starting point.

A second product accepts 40 investigations per day. Each may wait six hours for a reviewer, call tools owned by three teams, and survive a weekly worker rollout. Its volume is smaller, but acceptance creates a longer obligation. A durable execution service and explicit release policy can address concrete gaps. This does not yet establish that the company needs a general-purpose platform for every agent.

Use an obligation decision record

Complete this artifact with an existing system name rather than a proposed product category. A missing owner is a decision to resolve, not permission to add another component.

Obligation	Existing owner and evidence	Unmet case	Smallest justified addition
Accepted work survives process replacement	Job service; replacement drill	None for bounded batch work	Reuse current job contract
Human waits survive release cycles	No current owner	Reviewer responds after old workers retire	Durable wait and compatible executor
Behavior revisions are attributable	Image registry only	Prompt changes without a release record	Release manifest and resolver
One tenant cannot monopolize capacity	Shared FIFO queue	Bulk jobs block urgent requests	Tenant-aware scheduler
An operator can stop affected work	Application-specific scripts	New workloads lack a supported control	Owned intervention interface

The filled rows above are illustrative. For a real decision, add an accountable owner, operating estimate, failure test, and date to revisit each addition.

Prove one boundary before generalizing it

Select one recurring failure and run the same drill in the current service and proposed mechanism. For example, replace a worker after task acceptance and inspect the user-visible result. Assess whether the candidate actually closes the obligation and whether its support burden is acceptable. Queue delivery guarantees still need application interpretation: SQS documents possible redelivery.

Do not claim production readiness from a happy-path demonstration. Retain the drill record, unresolved cases, and operating owner. The detailed recovery design belongs in resuming a long-running agent safely.

Preserve an off-ramp for the first adopter

Define the minimum adoption interface and how a workload can leave. Keep domain decisions in the application unless they are demonstrably shared. A platform that requires every team to adopt one prompt style, one business state machine, and one model before it provides basic admission is imposing product coupling along with infrastructure.

Review the choice after actual adoption. If the second workload needs a fundamentally different guarantee, narrow the shared boundary rather than expanding an abstraction until it hides the differences.

Where the decision remains local

NIST’s Generative AI Profile supports lifecycle governance, not a particular topology. This guide’s decision record is a proposed way to assign those responsibilities. It cannot determine staffing, consequence tolerance, or a vendor’s actual guarantees. Compare the burden of a new boundary using the microservice architecture decision, then continue with the broader method in AI Agent Platform Engineering.