Choose how agents run
Agents move an initiative, bug, or todo from planned work into an execution tool while keeping the result tied to that work. They work best when the work item is already a useful spec.
Choose the setup by where the work should run and who should be able to use it. A simple launch opens one item in an app. A local worker runs on your machine. A cloud agent stays online for a team.
Pick the setup
Start with the lightest setup that matches the work.
| Choice | Best for |
|---|---|
| Send to app | You want to open one work item in Codex, Cursor, Claude Code, Windsurf, OpenCode, or Terminal with context already included. |
| Local Workers | You want Codex or Claude Code to pick up queued work from your machine through Desktop or the CLI. |
| Build a Local Agent | You are building a private worker that runs on one user's machine. |
| Build a Cloud Agent | You are building a shared service that stays online and wakes from webhooks. |
Agent model
The same agent model applies to local workers, cloud workers, and agent endpoints.
| Concept | What it means |
|---|---|
| Agent | The capability users can send work to, such as Codex local, Claude Code local, or a custom agent app. |
| Worker | The runtime that can execute sessions for an agent. Local workers run on one user's machine. Cloud workers run as a service that stays online. |
| Session | One visible unit of queued agent work, usually tied to an initiative, bug, or todo. Creating a session queues work. |
| Claim | The lease that lets one worker run one session. Work starts only after the claim succeeds. |
| Activity | A progress, plan, URL, completion, failure, release, cancellation, or policy event emitted by the worker. |
Workflows add a saved execution plan on top of this model for agent-driven handoffs, human gates, shared branches, and workflow-produced documents. Open Workflows from the main menu to monitor runs, manage agents, and edit definitions.
How agent work flows
Agent work starts when someone sends an initiative, bug, or todo to a tool or agent profile. Direct launches open the target app immediately. Queued launches create an Agent Session that an eligible worker can claim and run.
The original initiative, bug, or todo remains the place to review status, comments, recaps, taxonomy, and analytics.
Ways to run
Send to app is for one item at a time. It builds a prompt from the initiative, bug, or todo and opens a configured coding tool or terminal flow while a person stays in control of the next step.
Local agents run on your machine and belong to the signed-in owner. Only you can delegate work to them. They can use local tools, repositories, and secrets that you explicitly make available through your workflow.
Cloud agents stay online as shared services. Team members can send work to them when they have access, and the agent keeps running without depending on anyone's laptop.
Trust boundary
Initiatives, bugs, todos, comments, documents, and prompts are execution context. They are not runtime policy.
Trusted instructions come from platform policy, the agent profile, the worker configuration, and the local workflow file. Workers must enforce policy before filesystem access, shell execution, network access, workspace writes, or external side effects.