Agent Execution

Agent Execution

Agent Execution is the backend-owned boundary that turns a durable Studio run into provider processes in a Daytona execution workspace. There is no internal LangGraph Agent Server, harness graph, or second execution queue in this path.

flowchart LR
  api["Studio command"] --> temporal["Temporal StudioRunWorkflow"]
  temporal --> studio["Studio execute_run"]
  studio --> daytona["Daytona workspace"]
  daytona --> process["Codex / Claude / Antigravity process"]
  process --> mailbox["Studio mailbox and evidence"]
  mailbox --> temporal

Ownership

• Temporal owns durable scheduling, activity retry, timers, and wakeups.
• Studio owns run/session lifecycle, first-tool policy, mailbox delivery, closure, and the operator projection.
• Agent Execution owns provider selection, process launch contracts, profile continuity, and execution-workspace admission.
• Daytona supplies the workspace and toolbox. It does not choose providers or own durable run state.
• Armory compiles the profile’s skill and MCP capability manifest.
• ContextForge provides authenticated MCP/A2A routing and telemetry. It does not own profile, mailbox, lease, or continuity state.
• SpiceDB decides whether the stable profile subject may use an MCP server.

Direct execution path

StudioRunWorkflow calls the Studio activity. The activity selects a pending run and calls Studio execute_run directly. Studio then observes existing processes, applies walls and mailbox events, launches eligible attempts through the Daytona adapter, and closes terminal runs.

Do not add an HTTP queue, polling gateway, graph checkpoint store, or deployment between Temporal and Studio. External langgraph-http remains a CodexGate adapter option; it is not the AgentSquad lifecycle engine.

Agent identity and provider processes

The durable identity is a project agent profile, not a provider process or session. Its worktree, mailbox cursor, context reference, Armory loadout, and generation remain stable when the provider changes. Codex may be preferred and Claude may take over, but the replacement process must acquire the next fenced generation.

One project execution workspace is the target invariant. Eight profiles may exist while at most four provider processes are active. A profile does not own a sandbox. See ADR-0011 for the remaining migration and proof gates.

Process adapters

Provider-specific CLI arguments, authentication variables, status events, and readiness checks stay behind process adapters. Shared lifecycle code uses provider-neutral names:

• autonomyProfile
• launchArgs
• observationEventMap
• boardControlVerbs

CLIProxy is a credential and routing gateway, not an execution engine. Armory is a capability compiler, not a process launcher. Bubblewrap and cgroup v2 contain a generation; they do not establish identity or authorization.

Safety invariants

• Never rebuild a workspace for a process-only failure.
• Never run two writable generations for one profile.
• Never mutate Git metadata without the matching lease generation.
• Never relay lifecycle noise such as waiting for first tool as handoff content.
• Never launch when required Armory capabilities or SpiceDB proof are unavailable.
• Never build OCI images on the host; use the Kubernetes BuildKit plane.