Raltic field guide
Local vs cloud AI agents: how to choose the right runtime
The right runtime depends on where the required tools and data live. Local agents fit machine-bound work; cloud agents reduce setup and improve availability for workflows that can use managed context and connectors.
Move from the definition to the operating decision without losing the thread.
Direct answer
Use a local AI agent when the workflow depends on a repository, credentials, or toolchain that should remain on a controlled machine. Use a cloud agent when the work can run from managed context and approved connectors and the team values zero-install availability. Many teams need both, coordinated through the same review process.
Local and cloud agents solve different runtime problems
Local agents optimize for machine-bound access; cloud agents optimize for managed availability and lower setup.
A local coding agent can use a repository and toolchain already present on an engineer's machine. A managed cloud agent can start without waiting for that machine, making it better for research, synthesis, and connected workflows that do not require private local state.
The runtime choice does not determine who approves the result. Both should post reviewable evidence into a shared workflow and stop short of treating execution as acceptance.
- 01Local: repository and desktop tool access
- 02Local: depends on machine availability
- 03Cloud: zero-local-install start
- 04Cloud: controlled by managed sandbox and connector grants
- 05Both: need explicit review and evidence
Be precise about data boundaries
Local repository access does not automatically mean model processing is local.
A local bridge can keep repository reads and file operations on the runtime machine while sending selected outputs to a collaboration platform. The underlying AI CLI may still send code or context to its model provider under that provider's terms.
For cloud agents, teams should identify what context enters the managed runtime and which connector credentials or resources it can use. Describe each boundary separately: machine, orchestration platform, model provider, and connected system.
- 01Where files are read
- 02What is posted to the workflow room
- 03What the model provider processes
- 04Which connector resources are granted
- 05What evidence remains after the run
A runtime decision matrix
Choose based on required access, availability, setup cost, and the review model.
Local runtimes are a strong fit for code review, repository analysis, and developer toolchains. Cloud runtimes are a strong fit for launch checks, research synthesis, and operational tasks that rely on shared documents or APIs.
A hybrid workflow can delegate research to a cloud agent and code inspection to a local agent, then bring both outputs to the same human review.
- 01Private repo or local CLI required: local
- 02Always-on scheduled availability: cloud
- 03Fast trial without installation: cloud
- 04Machine-specific credentials or tools: local
- 05Cross-functional review: shared room for either runtime
Coordinate both without hiding the runtime
Make runtime identity and data movement visible in the workflow record.
Reviewers should know which agent ran locally, which ran in a managed environment, and what evidence each one could access. That context affects both trust and reproducibility.
Keep handoffs explicit through tasks and posted artifacts. Do not copy all private context between runtimes simply for convenience; transfer the minimum evidence needed for the next step.
- 01Label the runtime and participant
- 02Use least-privilege context transfer
- 03Post artifacts needed for review
- 04Record unavailable evidence and uncertainty
- 05Keep one human-owned decision
Primary sources
Product and practice claims in this guide are grounded in current first-party or standards sources. Raltic product claims are limited to shipped behavior described on this site.
FAQ