Single agents running in a developer’s local shell handle isolated code generation well, but complex software engineering requires breaking down large issues, managing task dependencies across multiple context windows, and isolating simultaneous file changes. Parallel work creates coordination needs when tasks share files, services, dependencies, or context.
Coordinating this work means choosing which architectural layer manages execution state. The market offers three distinct approaches: coding agents that manage subagents directly through built-in delegation, multi-agent workspaces that organize parallel branches and team handoffs, and programmable frameworks that let engineering teams build custom state machines. These represent different architectural choices rather than interchangeable product categories.
This comparison uses ten representative products across these three approaches to illustrate workload-specific tradeoffs. It examines how they manage task dependencies, isolate development workspaces, and expose human review controls, helping engineering teams select the right coordination boundary before addressing the separate challenge of governing the external actions those agents take.
TL;DR
- Built-in delegation: Shortlist Claude Code or Codex when coordination within your existing coding interface meets the workflow’s needs. Include OpenCode when provider choice and local configurability matter.
- Parallel workspaces and review: Compare Conductor for branch-mapped workspaces and handoffs with Nimbalyst for parallel sessions, visual artifacts, and diff review.
- Local and remote development: Include Orca when agents need workspaces across local, SSH, or self-hosted environments.
- Persistent work tracking: Evaluate Gas Town when durable task tracking and a verification-gated merge queue justify the operating overhead.
- Programmable workflows: Compare LangGraph for explicit workflow state and control flow, Deep Agents SDK for a higher-level harness with subagents, and OpenHands SDK for a programmable coding-agent loop and workspace environments.
- Production integration and governance layer: Use Arcade.dev alongside the chosen coding agent or orchestrator for multi-user agents connecting to production systems. Its actions runtime combines per-action enforcement, reliable tool execution, and centralized AI agent governance for actions routed through Arcade.
AI coding-agent harnesses and orchestration tools compared by approach
Coding agents with built-in orchestration
Built-in orchestration tools embed task delegation directly into the agent’s primary interface, letting developers spawn parallel threads without leaving the terminal or IDE.
| Product / surface | Choose when | Coordination and dependencies | Execution and isolation | Human review and intervention |
|---|---|---|---|---|
| Claude Code | Native terminal delegation fits the workflow | Subagents; experimental agent teams add a shared dependency-aware task list. | Configurable shell sandbox. Local MCP servers and hooks run outside that sandbox. | Configurable approval prompts for commands and file edits. Approval behavior depends on permission mode and rules. |
| OpenAI Codex | Local and cloud execution flexibility is required | Parent-coordinated subagents, including spawning workers, waiting for results, and directing follow-up work. | Local subagents inherit parent sandbox and approval settings. Cloud tasks receive separate isolated workspaces. | Configurable action approvals; users can inspect subagent threads and ask Codex to steer or stop workers. |
| OpenCode | Provider choice and local configurability are paramount | Primary agents delegate work to subagents, including parallel tasks. | Local execution without a built-in sandbox. Docker or a VM supplies additional isolation. | Configurable allow, ask, and deny rules for tools and commands. |
Multi-agent workspaces
Multi-agent workspaces sit above individual coding agents, organizing checkouts, branches, terminals, and merge queues to reduce collisions between parallel code changes.
| Product / surface | Choose when | Coordination and dependencies | Execution and isolation | Human review and intervention |
|---|---|---|---|---|
| Conductor | Visible parallel workspaces and handoffs matter | Branch-mapped workspaces; users divide work into reviewable units and integrate it through pull requests. | Local Mac execution with the user’s permissions, or managed cloud sandboxes. | Diff comments and PR review; tool-call approval behavior depends on configured permissions. |
| Nimbalyst | Visual artifacts and session reviews belong together | Parallel sessions, workstream grouping, and session chaining. | Local agent sessions; optional Git worktrees separate branches and working directories. | Keep or revert written changes through diff review; separate permission modes can request approval before actions run. |
| Orca | A cross-agent remote development IDE is needed | Worktrees and agent terminals; dependency-aware orchestration with an experimental opt-in UI panel. | Local, SSH, or self-hosted server execution. Worktrees separate files, rather than sandboxing processes or network access. | Review diffs, send line comments to agents, and inspect pull requests and checks. |
| Gas Town | Durable work tracking justifies operations overhead | A lead agent called the Mayor assigns work to workers; persistent task tracking and a verification-gated merge queue coordinate completion. | Self-managed native or Docker deployment, with Git worktrees for worker files. | Escalations support human oversight. PR merge mode can require an approving review; automated verification alone is not human approval. |
Programmable frameworks and environments
Programmable frameworks let engineering teams build agent loops, define retry behavior, and run continuous background workflows.
| Product / surface | Choose when | Coordination and dependencies | Execution and isolation | Human review and intervention |
|---|---|---|---|---|
| OpenHands SDK | A programmable coding-agent platform is required | SDK agent loop; configured TaskToolSet delegates synchronous subtasks and returns results to the parent. | Local, Docker, or remote workspaces; tools run in the selected environment. | Configurable confirmation policies can require approval for all actions or actions classified as risky by a security analyzer. |
| LangGraph core library | Custom state and recovery logic are needed | Graph nodes, edges, and shared state define sequencing, branching, and parallel paths. | Application-defined execution environment and checkpoint storage. | Configured interrupts pause execution, save state, and resume with human input. |
| Deep Agents SDK | A higher-level programmable harness is preferable | Optional planning tools and subagent delegation; the parent can dispatch multiple subagents in parallel. | Pluggable filesystem backends. Sandbox backends isolate code execution; local shell execution runs on the host. | Configured tool-call interrupts let reviewers approve, edit, or reject selected actions before execution. |
How we evaluated AI coding-agent harnesses and orchestration tools
We compared documented support for task dependencies, workspace isolation, human review, persistent state, integrations, model flexibility, and the infrastructure teams must operate. Claims about task limits, multi-model execution, and security boundaries come from first-party implementation documentation, product pages, and public repositories.
A session checkpoint lets an agent resume a conversation or retry a code edit. If a workflow step stops after creating a pull request but before saving its final state, restarting that step can create a duplicate pull request. The application must handle that possibility; saved workflow state does not guarantee exactly-once execution in external systems.
We distinguish OSI-approved open-source licenses from proprietary source-available distributions because their license terms permit different deployment options.
Coding agents with built-in orchestration
Subagents can handle temporary parallel work without a separate workflow engine. Codex can also move execution to separate cloud task workspaces.
Claude Code: Built-in terminal delegation
Best for
Developers needing rapid, built-in terminal delegation tightly integrated with Anthropic models and localized shell execution.
Overview
Claude Code is Anthropic’s coding agent for terminals and IDEs. Its built-in delegation lets a primary session coordinate subagents within the same interface.
Capabilities that matter
Claude Code supports documented subagent execution, letting the primary agent spawn independent workers with their own context windows. Experimental agent teams add a lead agent, peer messaging, and a shared dependency-aware task list. This setup lets the lead agent assign independent tasks to teammates, coordinate their outputs, and unblock sequential operations. The tool is optimized for Anthropic’s models and provides built-in Model Context Protocol client support for local stdio server connections. Optional memory directories let specific context survive across discrete conversations.
Tradeoffs and limits
Experimental agent teams are disabled by default and have documented resumption, coordination, and shutdown limitations. Only one team can exist per session, and nested teams aren’t supported. Teammates load the project context but don’t inherit the lead agent’s conversation history, so you need to pass context explicitly. The shell sandbox restricts filesystem and network access after permission checks, but extension processes and local MCP servers run outside this boundary. Native Windows installations and WSL1 don’t support the documented sandbox. WSL2 is required for sandboxed execution via bubblewrap and socat.
Pricing
Claude Code usage is governed by Anthropic Commercial Terms and consumes paid Claude plan allowances or API tokens. Pro subscriptions cost $17 per month when billed annually ($200 upfront) or $20 monthly. Active teammate subagents independently consume tokens.
OpenAI Codex: Local and cloud agent execution
Best for
Codex fits subagent delegation with the flexibility to move execution between local desktop environments and cloud task workspaces.
Overview
OpenAI Codex represents a family of coding-agent interfaces spanning CLI, IDE, and cloud surfaces. It coordinates complex work by letting a parent session manage multiple concurrent subagents and dispatch work to separate cloud environments while maintaining a unified interface.
Capabilities that matter
A parent session can inspect, steer, halt, and close subagent threads. A configurable concurrency cap limits how many tasks run simultaneously. Local agents inspect files and run installed tools. Cloud tasks run in separate, isolated workspaces using the established environment setup. The CLI and IDE support local and remote MCP servers.
Tradeoffs and limits
The execution and security boundary depends on the surface being used. Subagents inherit the parent session’s sandbox policy, permission mode, and MCP server access. Custom agent instructions don’t automatically provision a separate read-only sandbox. Cloud integration availability differs from API-key CLI or SDK usage, as API-key usage lacks native cloud features such as Slack integration or GitHub cloud review mechanisms. Workspace agents remain labeled as beta features within the CLI documentation.
Pricing
API-key Codex usage is billed at API rates, while ChatGPT subscriptions provide plan-based Codex allowances. Codex is available on Free ($0) and Go ($8 per month in the US), but Codex Cloud isn’t included with those plans. Cloud access is available to eligible Plus ($20 per month) and higher-tier accounts, subject to workspace settings. Pro has $100, $200, and $500 monthly tiers.
OpenCode: Multi-provider local agent harness
Best for
OpenCode fits workflows that need an open-source, multi-provider harness with out-of-the-box local execution and configurable parallel subagents.
Overview
OpenCode is an open-source coding agent developed by anomalyco, providing a terminal user interface and desktop packages across macOS, Windows, and Linux. It’s a provider-flexible harness that coordinates work across primary agents and dedicated subagent workers.
Capabilities that matter
Build and Plan are primary agents: Build has broad tool access, while Plan is configured for analysis and planning. General and Explore are subagents. General can perform multi-step work with broad tool access, while Explore is read-only. A primary agent can invoke subagents for parallel work. Teams can configure custom OpenAI-compatible endpoints or use the optional Zen billing service. Version 2 documents support for both local stdio and remote Streamable HTTP MCP servers, with external credentials stored outside the standard project configuration.
Tradeoffs and limits
OpenCode explicitly warns in its security documentation that it doesn’t sandbox the agent. The configurable permission rules govern user confirmation interface prompts, not hardened process isolation. If robust security isolation is required, operators must manually supply a Docker container or virtual machine environment. While automatic context compaction and child sessions are documented, a durable task-dependency scheduler or crash-recovery guarantee isn’t built into the harness.
Pricing
OpenCode software is distributed under an MIT license and costs nothing to use directly. Model provider inference costs or optional Zen pay-as-you-go charges apply separately based on usage.
Multi-agent workspaces for parallel coding agents
Separate Git worktrees give parallel tasks their own checkouts. Agents can still share local services, so configure distinct ports, such as Conductor’s CONDUCTOR_PORT.
Conductor: Parallel branch-based workspaces
Best for
Conductor fits concurrent agent work in the same repository when structured workspace isolation and collision management matter.
Overview
Conductor is a multi-agent workspace product that coordinates both local macOS desktop environments and managed cloud sandboxes.
Capabilities that matter
Conductor coordinates parallel work by strictly mapping workspaces to repositories and branches. This branch separation reduces simultaneous checkout interference when agents run in separate tabs. Cloud workspaces keep state after a local client disconnects, supporting asynchronous execution and cross-team handoffs. Conductor supports several underlying agents, including Claude Code, Codex, and OpenCode, letting teams use different models within the unified workspace architecture.
Tradeoffs and limits
Local macOS workspaces run with the host user’s standard permissions, and documentation explicitly states that local execution isn’t a security boundary. Cloud execution uses managed Vercel sandboxes. The pricing documentation notes that self-hosted cloud execution isn’t currently available. While branch separation isolates file edits, it doesn’t provide automatic semantic conflict resolution when merging complex parallel logic.
Pricing
Local execution is free. Conductor Pro costs $50 per month, and Conductor Teams costs $60 per user per month.
Nimbalyst: Visual review of parallel agent sessions
Best for
Nimbalyst fits work that combines parallel sessions with a shared interface for human review, visual diff inspection, and agent task handoffs.
Overview
Nimbalyst, the successor to Crystal, is a local-first desktop workspace that runs vendor agents and combines parallel sessions with collaborative review on macOS, Windows, and Linux.
Capabilities that matter
Nimbalyst coordinates parallel work by running Claude Code and Codex sessions side by side, using separate branches and checkouts for worktree sessions. It keeps a searchable, resumable, and branchable session history that records file read and write operations. Users can inspect visual diffs and manage Git state interactively. A collaboration server handles shared-data synchronization across teams.
Tradeoffs and limits
Visual diff review lets users keep or revert changes already written to disk. Separate permission modes can request approval before agent actions run; behavior depends on the selected mode and underlying provider. While Claude Code and Codex are fully supported, alternative providers like OpenCode remain labeled as alpha integrations. The desktop client is MIT licensed. Hosted collaboration is included with Nimbalyst Teams. The self-hosted collaboration server has a separate restricted source license under the Enterprise offering.
Pricing
Nimbalyst Individual is free. The Teams tier costs $20 per user per month (or $200 annually) and is explicitly documented as free during its beta period. Custom enterprise pricing is available.
Orca: Local and remote per-task worktrees
Best for
Orca fits cross-agent local and remote development with per-task worktrees and Git-centric review tools.
Overview
Orca, maintained by Stably, is a desktop and remote agent development environment. It launches CLI agents as terminal processes within per-task worktrees, providing a unified graphical interface for inspecting code generation, resolving conflicts, and managing pull requests.
Capabilities that matter
Orca assigns each task a distinct Git worktree, agent terminal, and browser tab so multiple agents can work in parallel. Tasks can run on the local desktop, via SSH, on self-hosted servers, or in on-demand virtual machines. Review tools include CI inspection, conflict resolution, pull request inspection, diff annotation, reviewer requests, and merge controls.
Tradeoffs and limits
While Orca isolates file edits via worktrees, worktrees don’t sandbox processes or restrict network egress. Supported launch configurations allow prefilling permission-bypass flags, and custom arguments can override global safety settings, placing the security burden on the operator. Advanced webhook dispatch and automated issue-to-CI pipelines depend on external configurations beyond the desktop client, so verify them against your specific infrastructure.
Pricing
Orca is free, open-source software under an MIT license. Running Orca requires separate agent subscriptions and local or remote execution infrastructure.
Gas Town: Persistent Git-native coordination
Best for
Teams that need persistent Git-native task tracking and a structured merge queue, and can operate the supporting infrastructure.
Overview
Gas Town is an open-source, persistent multi-agent workspace manager that tracks complex development cycles. It coordinates work by assigning distinct roles to different agents and processing completed tasks through a structured merge queue.
Capabilities that matter
A Mayor agent coordinates the workload, assigning tasks to Polecat worker agents. Witness processes detect stalled workers and trigger automatic recovery. Completed work is routed to Refineries, which process code through a bisecting merge queue and verification gates rather than allowing direct pushes to the main branch. Persistent identities, Git-backed hooks, the Dolt runtime, and the Beads ledger ensure that work history survives ephemeral agent sessions.
Tradeoffs and limits
Gas Town’s persistence and merge queue require teams to operate several components. Native installation requires Git, Beads, sqlite3, and Dolt; tmux is optional for full-stack mode. Building from source also requires Go and ICU4C headers. Docker Compose supplies runtime dependencies inside its container. The dashboard operates as a trusted local-network surface rather than a hardened public control plane, and native installations must not share a host workspace with Docker environments.
Pricing
Gas Town is distributed under an MIT license. No standardized all-in operating price is established, as teams must supply their own agent runtimes, API models, and infrastructure.
Programmable coding-agent frameworks and environments
OpenHands: Programmable coding-agent environments
Best for
OpenHands fits programmable, event-driven architectures with replaceable execution environments and custom tool frameworks.
Overview
OpenHands provides a Software Agent SDK for building coding agents.
Capabilities that matter
The OpenHands SDK handles orchestration by implementing the reasoning and action loop across separate core, tools, workspace, and server packages. It supports flexible execution models through LocalWorkspace, DockerWorkspace, and RemoteAPIWorkspace, letting teams choose the appropriate trust model for their workload. Human controls are programmable, featuring AlwaysConfirm, NeverConfirm, and ConfirmRisky policies, alongside a security analyzer that classifies action risk before execution.
Tradeoffs and limits
OpenHands requires teams to manage several components, adding more setup than a simple CLI harness. The documentation explicitly states that the security analyzer and confirmation controls aren’t a complete prompt-injection solution and don’t replace the need for secure sandboxing. While container deployment is supported, operators remain responsible for configuring secure mounts, credential injection, and network egress boundaries.
Pricing
The OpenHands SDK is MIT licensed. Local and open-source usage is free. Provider usage incurs direct API costs, and managed enterprise deployments require custom pricing.
LangGraph: Custom state and recovery workflows
Best for
LangGraph fits complex, cyclical graph-based agent workflows in Python and TypeScript that require explicit, programmable state memory.
Overview
LangGraph is a low-level orchestration framework from LangChain that models agent workflows as graphs. It coordinates execution by letting developers define explicit nodes, edges, and state transitions, providing durable, application-defined control flow.
Capabilities that matter
LangGraph coordinates parallel work and dependencies through graph nodes and persistent application state. Checkpointers save thread state across sessions, while stores hold cross-thread data. Developers can configure retry policies with attempt counts and backoff factors. Human-in-the-loop controls are implemented via interrupts, which save state and pause execution until human input is received.
Tradeoffs and limits
Checkpoints provide resumability, but they don’t guarantee exactly-once execution for external systems. If an interrupt occurs, resuming restarts the interrupted node from the beginning. Any non-idempotent external write (like posting a Slack message) executed before the interrupt may be duplicated upon restart unless the application handles reconciliation. LangGraph is also a general-purpose framework, so teams must build the coding-specific execution environment and repository management layer from scratch.
Pricing
The framework is MIT licensed. Optional LangSmith observability offers a Developer tier at $0 per seat per month (with trace limits) and a Plus tier at $39 per seat per month, plus usage charges.
Deep Agents: Programmable subagent workflows
Best for
Deep Agents fits work that prioritizes custom orchestration logic, filesystem context management, and programmable subagent hierarchies.
Overview
Deep Agents is a general-purpose agent harness built on top of LangChain and LangGraph. It provides a complete CLI coding agent application alongside an SDK that simplifies creating durable, human-gated subagent workflows.
Capabilities that matter
Deep Agents combines subagent management and filesystem context in one harness. Task-specific subagents support isolated, multi-step work. Asynchronous workers run in parallel; synchronous workers block the supervisor until they finish. Context compaction summarizes older messages and offloads tool outputs to storage. Execution supports local, sandboxed, or remote filesystem backends, letting operators choose where filesystem operations run. Shell access must be assessed separately when determining whether execution is isolated from the local machine.
Tradeoffs and limits
The published package metadata classifies both the core Deep Agents library and Deep Agents Code as Beta. The cited public materials don’t establish an enterprise support or lifecycle guarantee. Filesystem access can inadvertently expose secrets, and virtual path restrictions within the backend don’t constitute true security isolation if shell access is simultaneously enabled. Human approvals within the harness pause execution for sensitive tool calls but don’t restrict previously issued credentials.
Pricing
The Deep Agents library and code CLI are distributed under an MIT license. Deployment incurs standard API model costs and related infrastructure expenses.
How to pilot coding-agent orchestration tools
Run the same representative task through each shortlisted setup using a test repository and test accounts. Keep the starting commit, task brief, acceptance tests, and external-system permissions consistent. Use the same model and settings where supported, and record differences.
Define what successful completion means before starting: the required change works, tests pass, external updates are correct, and a developer can review the result. Then introduce the following conditions.
| Evaluation | What to test | What to record |
|---|---|---|
| Task dependencies | Make one task depend on an interface or change produced by another. | Whether prerequisites are respected and how much manual sequencing is required. |
| Parallel changes and services | Run tasks that touch overlapping files or use the same local service. Introduce a conflicting Git push. | Checkout separation, service or port collisions, conflict handling, and manual reconciliation time. |
| Interrupted execution | Stop a run partway through the task, then resume it. | What state survives, which steps repeat, and what requires developer intervention. |
| External failures | Simulate a transient API error and an expired credential. | Retry attempts, authentication recovery, final outcome, and manual intervention. |
| Replayed external writes | Interrupt the workflow after a test message or other external write succeeds but before completion is recorded. | Whether resumption creates duplicates. Check the external system’s actual records. |
| Permission boundaries | Attempt an action outside the configured permissions. | Whether execution is blocked, approval is requested, or the action proceeds, and what evidence records that decision. |
| Human review | Include a failing test or a change that needs revision. | Whether the problem blocks progress or is merely reported, how reviewers intervene, and review time. |
Compare total cost alongside successful completion. Include model usage, allocated software or seat fees, compute and storage, and time spent configuring, maintaining, reviewing, and recovering the workflow. Record initial setup effort separately from recurring costs.
Use the results to identify which setup meets your requirements with an operating burden your team can sustain. These are suggested pilot conditions; they are not benchmark results for the products in this comparison.
Where Arcade.dev fits in the coding-agent stack
An agent reads a Linear issue, edits and tests code, creates a GitHub pull request, and posts an update to Slack. The coding agent and orchestration layer coordinate development. The calls to Linear, GitHub, and Slack introduce a separate production requirement: authenticating users, controlling actions, executing tools reliably, and recording what happened.
Arcade.dev provides the actions runtime for enterprise AI agents. It offers a reusable foundation for these external actions across coding agents and orchestrators, combining enforcement, execution, and AI agent governance. Teams can reuse that foundation as they change models, add agents, or expand workflows.
For each action Arcade executes, the runtime handles delegated user authentication, evaluates the intersection of the user’s existing permissions and the agent’s separately scoped permissions, and enforces applicable runtime policies. It manages the credential lifecycle while keeping credentials isolated from the agent and LLM. Configured Contextual Access hooks connect existing security and DLP controls to the action boundary.
Arcade combines this enforcement with tools optimized for natural-language intent and runtime capabilities, including parallelized execution, automatic failover, and intelligent retries. Teams can use prebuilt agent-optimized tools, build custom tools, or integrate existing MCP servers under the same runtime boundary. They can connect through an MCP gateway, REST API, or SDK. MCP remains optional.
Centralized AI agent governance gives teams control over agents, tools, access, and versions. Tool Executions record runtime calls and outcomes, while Audit Logs record administrative and configuration activity. Together, they give attributable visibility into governed actions and changes to the runtime.
For multi-user agents connecting to production systems and compliance-sensitive deployments, use Arcade alongside the chosen coding agent or orchestrator. Its controls apply to actions executed through Arcade. Direct shell commands and API calls that bypass Arcade remain outside that boundary, and applications still need to handle duplicate external writes when workflows replay.
Conclusion
Define your acceptance criteria before the pilot: acceptable review effort, completion cost, failure-recovery behavior, and execution boundaries. Run the same task through each shortlisted setup and introduce the same failures. Check what survives interruption, what repeats on replay, and where a developer must intervene.
For multi-user agents reaching production systems and compliance-sensitive deployments, evaluate the selected coordination tool alongside Arcade.dev’s actions runtime. Route the relevant external actions through Arcade to apply its enforcement, execution, and AI agent governance controls.
Frequently asked questions
What is the difference between a coding-agent harness and a multi-agent workspace?
A harness runs an agent’s coding workflow and may delegate to subagents. A multi-agent workspace organizes separate agent sessions, working directories, and review handoffs. Some products combine these capabilities, so compare the specific coordination and execution controls each provides.
Do Claude Code and Codex need a separate orchestration tool?
Not always. Built-in delegation may be sufficient when a parent agent can divide the work, coordinate subagents, and collect their results. Evaluate a separate tool when managing parallel sessions, dependencies, review, or recovery requires more coordination than your existing setup provides.
Can a multi-agent workspace use different coding agents?
Some can, but compatibility varies. Check support for your chosen agents and execution environments, then verify which coordination and review features work with each agent. Support for launching an agent does not necessarily establish support for every workspace feature.
When should I build coordination with a framework instead of using a workspace?
Choose a framework when you need application-defined workflow state, branching, task sequencing, or recovery behavior. Choose a workspace when the main requirement is organizing coding sessions, separate checkouts, and developer review. With a framework, your team takes responsibility for configuring and operating the workflow and execution environment.
Does a Git worktree sandbox a coding agent?
No. A worktree provides a separate checkout, but it does not sandbox processes, restrict network access, or protect host credentials. It also does not resolve semantic merge conflicts. Evaluate process isolation, permissions, and shared services separately.
How should I compare the total cost of coding-agent orchestration tools?
Include software or seat fees, model usage, compute and storage, and the time spent configuring, maintaining, reviewing, and recovering workflows. Compare those costs against successfully completed and reviewed tasks. Separate initial setup effort from recurring operating costs.
Do Arcade’s controls apply to every external action a coding agent takes?
No. They apply to actions executed through Arcade. Direct API calls and shell commands that bypass its actions runtime remain outside those controls. Identify which external actions will use Arcade and how the surrounding environment controls other execution paths.
