Why
Automations should not have to know the repository before they start.
Some automations are simple: fixed repo, fixed branch, run on a schedule. Others start from operational context. The incident.io flow is the clearest example. An alert/incident notification comes in, but the system does not know the repo yet. The first agent should inspect the incident, use incident.io MCP and catalog context to understand the affected service, then decide whether code work is needed.
If code work is needed, that should happen in a separate repo-bound session with the normal access checks and scoped credentials. The no-repository run is the coordinator. It should not be a session with broad repo access.
The same shape applies to team and platform work. A weekly automation to update AGENTS.md across selected repos should resolve a repo set, then create separate repo-bound runs per repo. It should not become one session with access to everything.
Product context
This matches the direction Cursor has already taken in the Agent window. Agents can start from Home, with no repository selected, or from a workspace that groups several repositories. Automations could follow the same mental model.
The useful product shape is:
Home: run an automation without a repository. Good for incident triage, Slack or Linear routing, operational checks, reporting, and MCP-driven investigation.Single repository: current behavior. Good for a known codebase and branch.Workspace or repo set: run against multiple repositories that belong to the same product, team, or service boundary.
Target model
Automation creation stores the intended target mode. Each run resolves that mode into an execution target before execution starts.
Current target modes:
fixed_single_repo: existing behavior. Resolve one repo and branch before creating the session.no_repository: coordinator mode. No clone, no SCM credentials, no PR tool. It can investigate external context and request repo-bound work later.
Future target modes should fit the same model:
webhook_payload_single_repo: resolve the repo from the trigger payload.repo_set: expand a selected repo set or workspace into separate repo-bound runs.- parent or child automation runs: coordinate multi-step work without mixing credential scopes.
The unit of product behavior should be the automation run. A sandbox is one execution backend, not the definition of an automation.
Architecture note
The current PR slice can reasonably reuse the existing session and sandbox pipeline. That gets the feature in users' hands with the existing LLM runtime, MCP injection, logs, cancellation, callbacks, and UI.
However, a sandbox-backed no-repository session could be a good MVP, but probably not the final infrastructure shape. For many no-repo jobs, the work is mostly API and MCP calls. Spinning up Modal and OpenCode for every run may be heavier than needed once volume grows.
The long-term shape should be:
trigger -> automation run -> target resolution -> executor -> optional sandbox -> result
For short no-repo jobs, the executor can run the LLM and tools directly. For code work, shell work, browser work, file generation, or risky execution, it can spawn a sandbox. That keeps the product model stable while letting the backend evolve.
Current slice
#836 implements the first slice: fixed_single_repo and no_repository automation targets, plus the no-repository coordinator boundary.
This does not close the whole issue. The remaining work is the broader resolved-target model, especially run-level resolved target snapshots, payload-resolved repo targets, repo-set fan-out, workspace targets, and later a lighter no-repo executor if usage shows the sandbox path is too heavy.
Why
Automations should not have to know the repository before they start.
Some automations are simple: fixed repo, fixed branch, run on a schedule. Others start from operational context. The incident.io flow is the clearest example. An alert/incident notification comes in, but the system does not know the repo yet. The first agent should inspect the incident, use incident.io MCP and catalog context to understand the affected service, then decide whether code work is needed.
If code work is needed, that should happen in a separate repo-bound session with the normal access checks and scoped credentials. The no-repository run is the coordinator. It should not be a session with broad repo access.
The same shape applies to team and platform work. A weekly automation to update
AGENTS.mdacross selected repos should resolve a repo set, then create separate repo-bound runs per repo. It should not become one session with access to everything.Product context
This matches the direction Cursor has already taken in the Agent window. Agents can start from
Home, with no repository selected, or from a workspace that groups several repositories. Automations could follow the same mental model.The useful product shape is:
Home: run an automation without a repository. Good for incident triage, Slack or Linear routing, operational checks, reporting, and MCP-driven investigation.Single repository: current behavior. Good for a known codebase and branch.Workspaceor repo set: run against multiple repositories that belong to the same product, team, or service boundary.Target model
Automation creation stores the intended target mode. Each run resolves that mode into an execution target before execution starts.
Current target modes:
fixed_single_repo: existing behavior. Resolve one repo and branch before creating the session.no_repository: coordinator mode. No clone, no SCM credentials, no PR tool. It can investigate external context and request repo-bound work later.Future target modes should fit the same model:
webhook_payload_single_repo: resolve the repo from the trigger payload.repo_set: expand a selected repo set or workspace into separate repo-bound runs.The unit of product behavior should be the automation run. A sandbox is one execution backend, not the definition of an automation.
Architecture note
The current PR slice can reasonably reuse the existing session and sandbox pipeline. That gets the feature in users' hands with the existing LLM runtime, MCP injection, logs, cancellation, callbacks, and UI.
However, a sandbox-backed no-repository session could be a good MVP, but probably not the final infrastructure shape. For many no-repo jobs, the work is mostly API and MCP calls. Spinning up Modal and OpenCode for every run may be heavier than needed once volume grows.
The long-term shape should be:
trigger -> automation run -> target resolution -> executor -> optional sandbox -> resultFor short no-repo jobs, the executor can run the LLM and tools directly. For code work, shell work, browser work, file generation, or risky execution, it can spawn a sandbox. That keeps the product model stable while letting the backend evolve.
Current slice
#836 implements the first slice:
fixed_single_repoandno_repositoryautomation targets, plus the no-repository coordinator boundary.This does not close the whole issue. The remaining work is the broader resolved-target model, especially run-level resolved target snapshots, payload-resolved repo targets, repo-set fan-out, workspace targets, and later a lighter no-repo executor if usage shows the sandbox path is too heavy.