What is a cloud AI agent?
A cloud AI agent is an AI system that runs in a managed remote environment, can use tools, and can continue work without your laptop staying awake. Its useful state lives with the agent: files, installed software, task history, and the credentials it is allowed to use.
“Cloud” describes where the agent executes and who keeps that environment available. It does not name a model, a chat interface, or a level of autonomy. A terminal agent can run locally or in the cloud. An IDE can hand a job to a remote agent. The categories overlap.
The practical breakpoint comes when your laptop stops being only the control surface and becomes part of the job's runtime. If you have to keep it awake, preserve a particular shell setup, or be online when an event arrives, the agent is still coupled to you even if the model can act on its own.
Keep it local when
- You are present for the whole task and want to review each command.
- The useful state already lives on your laptop.
- The job needs local hardware, a desktop application, or data that must not leave the device.
- You need to work offline with a local model.
- Stopping when the lid closes is acceptable.
Use a cloud agent when
- The work should continue after you disconnect.
- Later runs need the same files, tools, and work history.
- A schedule, webhook, or another agent should be able to start the work.
- Independent jobs need separate files, ports, or toolchains instead of sharing one workstation.
- You want one addressable agent that can sleep between jobs instead of one process tied to one device.
What makes a cloud AI agent different from an LLM app?
An LLM turns input into output. An agent adds a loop around the model: inspect the current state, choose an action, use a tool, inspect the result, and decide what to do next. A cloud AI agent puts that loop in a remote environment that it can return to later.
That last part changes the kinds of jobs you can hand off. A chat response can draft a shell command. A cloud agent can run the command, save its output, notice that a dependency is missing, install it, and leave the resulting files ready for the next run. The environment is part of the product, not an implementation detail hidden behind the model call.
The shortest useful definition is:
A cloud AI agent is a tool-using agent whose execution environment and working state live in the cloud, so it can be invoked without the user's device remaining online.
The definition says nothing about whether the agent is general-purpose or specialized. A coding agent, a research agent, and an operations agent can all be cloud agents. What matters is the execution and state boundary.
Are local agents, IDE agents, and cloud agents separate categories?
Not cleanly. These labels answer different questions.
| Label | The question it answers | Typical shape |
|---|---|---|
| Local agent | Where does it execute? | On a device you operate, using its files and tools |
| IDE agent | Where do you interact with it? | Inside an editor, often sharing the editor's terminal and repository |
| Cloud AI agent | Where do execution and work state live? | In a managed remote environment that stays addressable after you disconnect |
| Serverless LLM app | How is the application invoked and scaled? | A request or event starts code; durable state usually lives in separate services |
Goose describes itself as a general-purpose agent that runs on your machine. A standard Claude Code installation also starts inside a project on your development machine. Those are local shapes, but either tool can be placed on a remote host.
Cursor shows why “IDE agent” is not the opposite of “cloud agent.” Its foreground agent can use the terminal attached to the editor, while its Background Agents run asynchronously in remote environments. The editor is the entry point. The job may still execute in the cloud.
Serverless functions are a lower-level building block. They are good at receiving events and scaling short, stateless work. Providers now also offer durable function patterns, so “serverless” no longer means “short-lived” in every case. The structural difference is ownership: with a serverless LLM app, you assemble the model calls, state store, retries, credentials, and operator interface. A cloud agent exposes the working agent as the unit you invoke.
What are the parts of a cloud AI agent?
1. A managed execution environment
The agent needs somewhere to run commands and install the software a job requires. For coding work that may include Git, a language toolchain, and test dependencies. For research it may include document converters or data-processing libraries.
Isolation matters because agent-written commands are untrusted by default. The environment should have a clear identity, bounded permissions, and a lifecycle the operator can inspect. “Runs in the cloud” is not enough information on its own.
2. Persistent working state
Useful work rarely fits in one model response. A checked-out repository, downloaded source material, generated reports, and installed packages need a durable home. A persistent disk lets the next run start from the state the previous run produced.
Memory is related but different. Memory is a small set of facts the agent deliberately carries forward. The disk is the complete working set. Treating one as a substitute for the other either bloats prompts or loses artifacts.
3. Ways to start work without opening chat
A cloud agent becomes operationally useful when more than a person can invoke it. Common entry points include a schedule, a webhook, an API call, or a request from another agent. A chat message is still useful, but it should not be the only ignition switch.
Triggers need delivery semantics. If the same webhook is retried, does the job run twice? If a scheduled job fails halfway through, where can the operator see it? These questions matter more than the trigger logo.
4. Connectors and bounded credentials
An agent that can only edit its own files has a narrow reach. Connectors let it read from or write to services such as source control, a database, a messaging system, or a spreadsheet.
Credentials should be collected outside the conversation, scoped to the smallest useful permission, and attached only when the tool runs. A cloud agent is easier to reach than a laptop process. That makes credential handling and network policy more important, not less.
5. A way to wait, resume, and report
Real jobs pause. A build takes time. An approval may arrive hours later. A rate limit may require a retry. The agent needs to record where it stopped, release resources when it can, and surface a result or a question to the operator.
This is why a cloud agent should remain addressable while idle without consuming active compute the whole time. Availability is a service property. It does not require a process to burn resources continuously.
How does a cloud AI agent work?
A typical run moves through a small lifecycle. The exact implementation varies, but the state transitions are recognizable.
- Trigger. A person, schedule, webhook, API client, or another agent submits work.
- Resume. The service wakes the agent's environment and attaches its durable state.
- Work. The agent plans, calls tools, observes results, and updates its approach.
- Save. Files, checkpoints, and a result record are written before the run finishes or waits.
- Sleep or wait. Active execution stops when there is no work. The agent remains addressable for the next trigger or human answer.
- Deliver. The result returns to chat, an API client, or the system that started the job.
The model is only active during part of this sequence. The rest is ordinary systems work: queueing, identity, storage, timeouts, accounting, and recovery. That is why moving a local agent to a remote virtual machine is a useful first experiment but not the whole managed-cloud experience. Someone still has to own the edges.
When does a cloud agent earn its keep?
The job outlives your attention
Long tests, a multi-source research brief, and a data cleanup can run after you leave. The value is not raw duration. It is a clean handoff: you can disconnect without losing the process, then return to a result and the files behind it.
The environment is expensive to rebuild
Some tasks need a repository plus a particular toolchain. Others accumulate a reference library over time. If every invocation starts by cloning, installing, and rediscovering context, an ephemeral environment spends time rebuilding what the agent already knew how to use.
Persistence has a cost too. Old dependencies drift, temporary files pile up, and compromised credentials remain dangerous until revoked. A durable environment needs inspection and deletion controls.
Several jobs need separate environments
You can open more than one local terminal. The constraint is not the tab count. Those agents still compete for the same CPU and memory, and they can collide over repositories, ports, package caches, and credentials. Running them safely means creating and maintaining that separation yourself.
A cloud service does not make concurrency unlimited. It can make the boundary explicit: one addressable environment per agent, with account-level limits on concurrent work. This fits independent jobs. Parallel writers against the same checkout still need coordination.
The setup has become undocumented infrastructure
A local agent inherits your shell configuration, package versions, cached logins, and environment variables. That is convenient until a successful run depends on state nobody recorded, or until a credential copied for one task stays on the machine.
Moving the agent does not eliminate drift. A persistent cloud environment can also grow stale. The useful change is ownership: the job's files and tools live in a named environment that can be inspected or deleted, while credentials can be managed outside shell history and dotfiles.
Work starts from events, not from a person
A daily digest, a new lead, or a repository event does not need somebody waiting at a chat box. Schedules and webhooks turn the agent from an interactive tool into a participant in an existing process.
Use this pattern when the work is genuinely variable and benefits from judgment. A fixed transform with known inputs and outputs should usually stay ordinary code. Putting an LLM in a deterministic path adds cost and new failure modes.
More than one client needs to reach the same agent
You may start work in a browser, inspect it from a terminal, and let another agent send the next instruction through an API. A stable remote identity makes those entry points converge on the same working state.
This is also the point where access control becomes visible. Every caller should act as a known account, and every action should be attributable. A public endpoint with one shared secret is not a collaboration model.
When is a local agent the better choice?
Choose local by default for a short, interactive job whose inputs already sit on your device. The agent gets immediate access to the current checkout, you can watch each command, and there is no remote environment to secure or pay for.
A local tool using your provider key also keeps model billing between you and that provider, without a separate hosting meter. Pair it with a local model and the work can continue offline. These are good reasons to stay local, not temporary shortcomings to outgrow.
Local is also the honest answer when policy keeps source data on the device, when the task depends on a GPU or peripheral attached to it, or when the work happens inside a graphical desktop application. A headless cloud environment cannot pretend those constraints away.
There is a useful hybrid pattern: keep the tight edit-and-review loop local, then hand long or scheduled work to a cloud agent. The two agents do not need to be the same product. A local MCP client can delegate a bounded task to a remote agent and pull the result back into the developer's normal workspace.
What tradeoffs come with cloud agents?
A larger security boundary
The agent may hold source code, credentials, and network access in a remotely reachable environment. Assume tool output and fetched content can be hostile. Limit credentials, restrict outbound access where practical, and require human approval before high-impact writes.
Cost that follows activity
Cloud execution, model calls, and durable storage are separate meters even when a vendor presents one balance. A sleeping agent can stop active compute, but stored data may still cost money. Long loops also turn a small prompt into a large bill unless the service exposes budgets and stop controls.
State that can become stale
Persistence saves setup time and also preserves mistakes. Repositories fall behind, packages age, and one task can leave files that confuse the next. A good agent makes its state visible and gives the operator a clean way to reset or delete it.
Dependence on a remote service
If the service is unavailable, so is the agent. Network latency sits in the interaction path, and migration may require moving files, secrets, and workflow definitions. Keep important artifacts in ordinary formats and understand how to export them.
How should you evaluate a cloud AI agent?
Start with the work, not the model list.
- State: Which files and installed tools remain available for later runs? Can you inspect and delete them?
- Invocation: Can chat, schedules, webhooks, and an API reach the same agent identity?
- Handoff: What happens when you close the client during a long command? Where does the final result appear?
- Boundaries: How are agents isolated? How are secrets collected and scoped? Which actions require approval?
- Failure: Can you see retries, timeouts, partial output, and the reason a run stopped?
- Cost: Which meters continue while idle? Can you cap a run before a loop consumes the budget?
- Exit: Can you download the files and remove the agent's state without opening a support ticket?
A polished chat interface cannot answer these questions. Ask for observable behavior.
Where does plori fit?
plori provides a cloud AI agent with its own persistent environment. Each agent keeps a disk, a shell with CLI tools, and memory. You can talk to it in the web app or let an MCP client create and drive agents programmatically.
For unattended work, a plori agent can keep a long command running, schedule a later run, or build a standing workflow with a schedule or webhook trigger. When the agent is idle, active compute stops. The environment and its files remain available for the next job.
For independent jobs, separate plori agents keep separate private directories and can be invoked independently, subject to the account's concurrency limit. Account- and agent-level environment settings keep tool configuration off one developer's laptop. Saved model keys are encrypted at rest and never shown again. This centralizes the setup, but it does not make credentials or persistent dependencies maintenance-free.
plori is not the right choice when you need a graphical desktop, on-premises execution, or a code-execution primitive to embed inside your own product. The comparison with local agents, managed cloud agents, sandbox APIs, and a VPS goes deeper on those boundaries.
Try a plori agent without signing up, or connect your own agent over MCP.
Common questions about cloud AI agents
Does a cloud AI agent run all the time?
It does not have to. A cloud agent can remain addressable while its active execution sleeps. A trigger wakes the environment, the agent does the work, saves its state, and releases active resources again. Check whether a provider still charges for storage while idle.
Is a cloud agent the same as an autonomous agent?
No. “Cloud” describes the execution location and lifecycle. “Autonomous” describes how much the agent may do without approval. A cloud agent can require confirmation before every external write, while a local agent can be allowed to run unattended.
Does every cloud agent have persistent memory?
No. Some remote agents start from a fresh environment for each job. Others keep a disk but not curated memory. Ask separately what persists: files, installed tools, conversation history, explicit memory, and workflow state.
Can an IDE agent also be a cloud agent?
Yes. The IDE can be the control surface for an agent that executes remotely. Cursor Background Agents are one current example. Judge where the work and state live, not where the prompt was typed.
Is a serverless agent a cloud agent?
It can be. Serverless describes how code is invoked and scaled. If the application supplies durable state, tool access, identity, and a way to resume work, it may expose a cloud agent. A single function that sends one prompt to a model is still an LLM application, not an agent with a working environment.
Do I need a cloud agent for coding?
Not for the tight edit loop. A local or IDE agent is usually faster when you are present and the repository is already open. Add a cloud agent when builds should continue after you disconnect, when jobs start from repository events, or when a remote environment should preserve its own tool setup.