Where Should an Agent Run?

The default: a server, with two clear exceptions

Run a shared production agent on a team-operated server unless one of two conditions overrides that choice. Keep it on a developer machine when the work is short-lived, belongs to one person, and does not need crash recovery or exact reproduction. Use a managed service when runs are sporadic, avoiding infrastructure is valuable, and the service’s isolation boundary is acceptable for every credential, tool, and piece of data the agent can reach.

That recommendation is about control, not model capability. An agent is a loop that lets a model choose tools and react to their results. Anthropic’s description of effective agents, published December 19, 2024, notes that such systems may operate for many turns and trade latency and cost for task performance. Where that loop executes changes who can reproduce it, which identity it uses, whether it can resume, and how far a compromise can spread.

Latency is rarely the deciding factor. Agent runs are dominated by model time rather than the network hop to a laptop, server, or managed runtime. No supplied measurement puts a millisecond figure on that difference, so topology should not be justified with an invented speed claim.

Comparison at a glance

Criterion	Developer machine	Team-operated server	Managed service
Start-up	Fastest: use the existing checkout, tools, credentials, and local state	Requires a deployable runtime and a shared execution path	Infrastructure is removed, but the agent must fit the service’s execution model
Reproducibility	Weakest: local state and credentials can produce a run nobody else can reproduce	Stronger: the team can run the same deployed code in the same environment	Depends on whether the service exposes enough configuration and run history; managed does not automatically mean reproducible
Credentials	Usually begins with the developer’s local credentials	Forces an explicit decision about whose credentials the agent uses	Credentials must be usable inside the provider’s isolation boundary
Observability	Logs and artifacts tend to remain with one machine and one operator	Shared logs and run records are available to the team	The provider defines what can be observed and exported
Durable state	Local disk is not durable workflow storage	Can use durable storage independent of the process	Suitable only if durable state and resume semantics are part of the service design
Cost at different utilisation	No separate runtime choice, but it cannot become dependable shared capacity	A long-running host fits steady load	Per-invocation billing fits sporadic load, which is common for agents
Isolation and blast radius	The agent sits beside local files, tools, state, and credentials	The team defines the host and credential boundary	The provider defines the isolation model; that can be the benefit or the blocker
Wrong when	Runs must be shared, resumed, audited, or reproduced	The team cannot justify operating a host for sporadic work	Tools or data cannot be placed inside the provider’s boundary

Developer machine: quickest start, weakest shared guarantee

A developer-machine agent is the agent process running in the same working environment the developer already uses. Its mechanism is direct access: the checkout, command-line tools, local files, caches, and credentials are already present. That is why it is the fastest option to start.

The same direct access makes it the hardest option to reason about. A successful run may depend on an uncommitted file, a particular tool version, a warm cache, an environment variable, or a credential available only to that developer. The recorded prompt and model response are not enough to reproduce such a run because the agent’s environment supplied part of the input. Local credentials, local state, and a run nobody else can reproduce come as one package.

That trade is reasonable during development. One engineer can inspect each tool call, stop a bad run, repair the workspace, and decide whether the result should be committed. It also suits a one-off task whose useful output is the final patch rather than a resumable execution history. The cost is not a quoted infrastructure price; no price evidence was supplied. The concrete sacrifice is shared operation: the machine and its owner become part of the runtime.

Local execution does not solve identity. If the agent inherits a developer’s credentials, downstream systems see the person’s authority rather than an autonomous workload with a bounded role. Before moving that pattern into production, decide whether to give the workload its own agent identity and audit trail and how credentials used by autonomous agents will be rotated. Changing the host without changing the identity merely relocates the ambiguity.

State is the hard stop. An agent that must resume after a crash needs durable storage wherever it runs. A laptop does not provide that production guarantee. Saving a transcript to local disk can help a developer inspect a failure, but it does not make the execution resumable after the machine or process disappears. The durable record has to contain enough state to determine what completed, what remains, and which external effects must not be repeated.

Local execution also gives a compromise a particular blast radius. The agent can reach whatever the developer account, local filesystem, and installed tools permit. That may be acceptable in a disposable development environment with narrow credentials. It is the wrong answer when the same machine holds unrelated repositories, broad production access, or state that cannot be reconstructed. The topology decides what is adjacent to the compromised process.

Pick a developer machine for exploration, short coding tasks, and runs with a present human owner. Do not pick it for unattended work that must survive interruption, produce a shared operational record, or be reproduced by another engineer.

Team-operated server: the production baseline

A server is a stable, team-controlled runtime on which the agent is deployed and invoked. Its mechanism is standardisation: the team chooses the code revision, dependencies, configuration path, credential injection, logs, and storage connections. Moving the agent there buys reproducibility and shared observability because execution no longer depends on one person’s workstation.

Reproducibility is not automatic. If every run reads mutable external data without recording what it saw, two executions can still diverge. The server improves the starting point: engineers can identify the deployed agent version and inspect a common run record. Reconstructing the full decision path may also require tool inputs, tool results, model responses, and external side effects. That is the boundary between ordinary logging and agent run replay and debugging.

The immediate cost of the move is an identity decision: whose credentials does the server use? Copying a developer token into a server preserves the local design’s central flaw while removing the developer who could notice misuse. A shared team token makes individual runs difficult to distinguish. An agent-specific identity with the minimum required permissions gives each run a stable principal, but the team must issue, store, rotate, and revoke its credentials. The server is valuable partly because it makes this question impossible to ignore.

State must live outside the agent process if a run has to survive a crash. Process memory, a temporary filesystem, and a durable workflow record are different things. Temporal’s workflow documentation, retrieved August 26, 2026, describes one concrete mechanism: an ordered event history is replayed to reconstruct pre-failure state, while recorded activity results prevent completed external work from being repeated during replay. Temporal is an example rather than a requirement; the relevant condition is that the chosen server design has durable state and defined resume behaviour.

A long-running server has the right cost shape for steady utilisation. The fixed host can accept work continuously, so paid capacity is repeatedly used. The same host is wasteful when the agent runs briefly and then sits idle. No host price or break-even percentage was supplied, so the decision cannot honestly be reduced to a numeric threshold. Measure occupied runtime and idle runtime for the actual queue before claiming that a persistent host is cheaper.

Latency still does little to separate the server from the other options. Moving the loop away from the developer adds a network path for invocation and tool access, but model calls dominate a typical agent run. Choose the server for state, identity, observability, and control—not for an unsupported claim that it will finish sooner.

The server’s isolation model is yours to design. That is valuable when the agent must reach internal tools or sensitive data that cannot enter a third-party runtime. It also means the team owns the mistakes: a host with broad network access and a powerful shared credential creates a broad blast radius. Putting several agents on the same host can also join their reachable state and credentials unless the execution boundary separates them. Topology is therefore part of the software’s authority model, not housekeeping left until deployment.

Pick a server when runs are shared, must be observable by the team, need durable state, or must stay inside a boundary the team controls. It is the wrong answer when utilisation is too sporadic to justify a continuously available host and the team gains no necessary control from operating one.

Managed service: less infrastructure, delegated isolation

A managed service runs the agent on infrastructure selected and operated by a provider. The mechanism is delegation: the team submits work and configuration while the provider supplies the execution substrate. That removes the infrastructure task and hands over the isolation model.

Handing over isolation is either the whole point or a non-starter, depending on what the agent touches. It is the point when the team wants each invocation placed in a provider-defined boundary without operating the hosts itself. It is a non-starter when credentials, source code, internal records, or reachable tools may not cross that boundary, or when the provider’s model cannot express the separation the application requires.

Managed does not mean credential-free. The service still needs authority to call tools. The engineering question becomes how credentials enter the managed boundary, what a single run can reach, and whether one compromised run can use authority intended for another. If those answers are unavailable, the isolation model is not understood well enough to approve the topology.

The same caution applies to state. A managed invocation that disappears after completion is suitable for a self-contained task, but it does not satisfy a requirement to resume after a crash. A managed service is viable for long-running work only when durable run state and explicit resume behaviour are part of the design. Otherwise, durable state must sit in a separate store controlled by the application. For the deeper implementation choice, see durable execution for long-running agent workflows.

Observability is also delegated. A provider-defined run page may be convenient, but convenience is not the criterion. The team needs the specific evidence required to reproduce and audit a run. If prompts, tool inputs, tool results, state transitions, or exported logs are absent, the service may be easier to operate while being harder to investigate. Treat any unverified retention or export capability as unknown rather than filling the gap with an assumption.

Managed per-invocation billing has the right cost shape for sporadic work: payment follows executions rather than an idle host. Agent workloads are usually sporadic, so this frequently favours the managed option. Cost inverts as utilisation rises. Once work is steady enough to keep a long-running host occupied, fixed capacity wins over repeated per-invocation charges. The ownership label alone does not settle this; compare the billing mechanism. Serverless functions versus long-running hosts is the next decision when both can meet the same state and isolation requirements.

Do not choose a managed service to save the network hop. Model time still dominates the run. Choose it because its operating and billing model match sporadic executions and because its isolation boundary is acceptable.

Pick a managed service for intermittent agents when the provider’s boundary can contain every tool, credential, and data source involved, and when its state and run records meet the application’s needs. Reject it when sensitive access cannot leave a team-controlled environment or when required isolation and recovery behaviour cannot be verified.

State and blast radius eliminate options before cost does

Use the criteria in this order:

1. Can the run be abandoned? If not, require durable storage and defined resume semantics. A plain laptop process is eliminated.
2. Can the agent’s tools and data enter a provider-controlled boundary? If not, eliminate the managed service and use a team-controlled server.
3. Must another engineer reproduce and inspect the run? If yes, require a standard runtime and shared run record. A developer machine is normally eliminated.
4. Whose authority should downstream systems see? Assign an agent identity before production. Do not let moving off a laptop silently turn a personal credential into a service credential.
5. What does one compromised execution reach? Compare local files and developer authority, server-side network and service authority, and the managed service’s declared boundary. Thoughtworks’ evolving field notes on agentic development and supply-chain risk, retrieved August 26, 2026, are a useful reminder that this is part of engineering the software loop, not merely operating its host.
6. Is demand steady or sporadic? After the previous constraints are satisfied, use a long-running host for steady load and per-invocation billing for sporadic load.

The topology decides the blast radius of a compromise, which makes topology a software engineering decision rather than an operational one. Deployment cannot repair an authority boundary the application never defined.

Which to pick when

Pick the developer machine when one developer owns a short run, can supervise it, and can discard or restart it. Its fast start is worth the weak reproducibility because no shared or durable guarantee is required.

Pick the team-operated server for the default shared production case. It is the strongest fit when the team needs reproducible deployment, shared observability, durable state, and control over the credential and network boundary. Pay the engineering cost of operating it when those controls are requirements rather than preferences.

Pick the managed service when executions are sporadic, removing infrastructure matters, and the provider’s isolation, credential, state, and run-record model is acceptable for everything the agent touches. Per-invocation billing then matches the workload. Do not pick it when that delegated boundary is prohibited or cannot be verified.

If a run must survive failure but does not need a team-controlled isolation boundary, either a server with durable storage or a managed service with verified resume semantics can work. Let utilisation decide between them: long-running host for steady load, per-invocation service for sporadic load. That is a resolved condition, not a generic it-depends answer.