Modern Agent Harnesses

A Git working tree and its local development commands.

Aider combines files in the conversation with a repository map derived from code definitions and references. It parses the model's edit format, applies changes and uses feedback to revise them. The map supplies broader context without sending every file. Architect mode separates a model that proposes the solution from one that expresses concrete edits. Git records changes outside the conversation, allowing review and undo independently of the model's current context.

A local checkout or assigned remote runner/orb with repository tools and a shell.

A thread holds instructions and execution history while its host supplies files and tools. The agent alternates model decisions with tool results, and multiple client surfaces can observe the thread or send input. The oracle is a separate reasoning call, not a transfer of the whole task to another model. Prior threads can be searched and read selectively. Execution policy belongs to the host/harness setup; default automatic tool execution is not equivalent to per-action human review.

Development workspaces, including shared directories and separate Git worktrees.

The main agent can continue while workers execute independent model/tool loops. A worker starts from a scoped assignment rather than the full parent conversation, with its own model and tool configuration within the permitted authority. Workspace policy separately determines whether workers share files or use isolated worktrees. Workers remain addressable while running or idle, and lifecycle controls can terminate a subtree. Switching custom agents forks history rather than silently changing an existing run's identity.

A local repository, terminal processes and configured integrations.

The Context Engine retrieves relevant codebase material for the agent's file and command loop. Tool results and hook feedback inform later model calls. Subagents run parallel assignments in independent contexts with their own prompts and tool restrictions, reporting progress into the main thread. Input can be queued, queue processing paused and active execution interrupted; saved sessions can be resumed. Pre-tool hooks can deny actions, while Stop hooks can reject premature completion with corrective feedback. Hooks run sequentially with timeouts; retrieval, delegated reasoning and execution remain separate parts of the runtime.

A repository/filesystem, shell processes and configured external services.

The session runs model/tool turns under permission and hook policies, loading project instructions, selected skills and tool definitions as needed. Older outputs are cleared or summarized; transcripts support resume and fork, while editable memory files carry information across sessions. Subagents run separate model/tool loops and return results: ordinary workers start from scoped prompts, while forked workers inherit the conversation. They can run in the background, be steered or stopped, resume with retained context, and optionally use separate worktrees. Background shell processes also outlive individual tool calls. Experimental agent teams add independent sessions with mailboxes and shared tasks. Dynamic workflows execute generated JavaScript to coordinate batches of subagents while the main session stays responsive. Goal mode evaluates completion between turns and can continue working, deferring evaluation while background work remains. Interruption cancels active work; file checkpoints and transcript rewind do not undo arbitrary external effects.

A development workspace, terminal, editor diagnostics and configured services.

Planning and execution are explicit modes around the session: an approach is developed before tools change files and run commands. Diagnostics and execution results inform the next decision. Diffs and checkpoints expose changes for review or reversal independently of the generated explanation. Supported CLI team modes add workers with separate contexts and persisted coordination state. Schedules are stored outside the interactive terminal, allowing later runs without leaving the same foreground conversation open.

A local or remotely provisioned workspace, managed command processes and configured tools.

The core owns persisted threads, with each turn composed of streamed model and tool-execution items; terminal, app and other clients submit input and answer approval requests rather than implementing the loop. Project instructions, skills and tool results form model context, which can be compacted independently of stored rollouts. Commands execute under sandbox and approval policy and can return managed process handles for later input/output. Parallel subagents have separate thread state and configurable models or roles; the parent can collect results, steer or stop them, with inherited runtime permissions constraining execution. Turn steering adds input to active work, while interruption requests cancellation. Resume and fork reuse recorded history, not a snapshot of external side effects. Persisted goals track an objective and usage across continued turns.

A local directory with shell, language-server and MCP connections.

Clients attach to a backend for their resolved working directory and start or resume sessions. The backend owns model/tool turns, permissions and shared connections such as LSP and MCP. Sharing these workspace resources does not automatically join clients to one conversation. Process-wide options are established when the workspace starts rather than changed silently by later clients. Live resource lifetime follows connected event streams; persisted conversation history is distinct from a currently running backend.

A local repository and terminal, or a separately selected cloud workspace.

The harness assembles workspace instructions and retrieved context, exposes model-specific tools, and continues from file, shell and browser results. Explore, Bash and Browser subagents keep noisy intermediate work in separate contexts and return summaries; custom workers can choose different models and tool restrictions. Workers can block the parent or run in the background, persist their state and resume by agent ID. They share a checkout by default; requested isolation uses a separate worktree or cloud VM and branch, with results merged later. Cloud agents continue independently of the local client. In the CLI, new input can steer at an execution boundary, while interruption is a separate control. The same delegation mechanism is available across editor, CLI and cloud surfaces.

A configured filesystem backend, execution sandbox and external services.

The default agent runs a model/tool loop wrapped by planning and context middleware. Large results are written to files and referenced from the prompt, while history summarization handles accumulated conversation. Delegated work gets a separate context and returns a result to the parent. Filesystem operations are routed through a configured backend, which may represent session state, a local directory or a sandbox; this choice determines persistence and execution authority. Saved conversation state supports continuing the packaged CLI session.

A local workspace containing files, persistent shell processes, web-search results and tools supplied by installed plugins.

DeepSeek Harness is assembled on the Cordis plugin kernel: models, tools, skills, sessions, sandboxes, storage, loops, scheduling and the UI are mounted services rather than fixed subsystems. Services communicate through Cordis dependencies and events, allowing a configured mode to replace or recombine the execution machinery. Everything presented to the model is appended to one session event stream, including reasoning, tool activity, subagent scheduling and injected context; resume, fork, search, trajectory inspection and replay operate on that same log. Standard mode supplies the full coding-agent loop with planning, goals, subagents and workflows. Code mode exposes those capabilities through an SDK so the model can generate a TypeScript program that performs several rounds of tool use without returning every operation through the ordinary single-call interface. Minimal mode reduces the environment to persistent Bash and a file editor, while Creator mode can inspect and experiment with the live plugin composition. The project is runnable through its local Web UI or from source, but remains a compatibility-breaking developer preview.

A cloud VM containing a repository checkout, shell, browser and development tools.

A cloud session investigates, plans, edits and tests within its own development computer; files and processes remain outside model context while messages let the user redirect work. Knowledge and playbooks provide reusable guidance across sessions. A coordinating Devin can launch managed child sessions on isolated VMs, send follow-ups, monitor results and put workers to sleep or terminate them. Dynamic Workflows move larger orchestration into generated Python: agent calls produce structured results, and completed calls replay from recorded results when a deterministic workflow resumes. These workflows run in the background; stopping one cancels its script and sleeps unfinished children. Separate-VM workers exchange code through branches, while explicitly shared-VM workers share files. CLI handoff transfers conversation and repository changes to a fresh environment rather than migrating the local process.

A local repository and terminal, optionally handed off to a new Devin cloud VM.

The parent runs local model/tool turns and delegates focused tasks to independent conversation chains. Foreground workers can request approvals; background workers use pre-approved tools and return control to the parent before they finish. Their completion notification is not automatic insertion into the parent's current pipeline. Interrupting the parent parks workers with state retained for resumption. Cloud handoff packages conversation, repository/branch and uncommitted changes for a fresh VM rather than moving the local process intact.

Repositories, shell processes, connected services and mission worker workspaces.

Interactive work uses a coding tool loop. In mission execution, an orchestrator assigns scoped jobs to workers and routes completed work through separate validation. A worker's model can be selected for its assignment without changing the parent's model or replaying the entire parent context. Asynchronous task calls return handles for output retrieval and resumption. Validators report failures rather than implementing their own fixes, allowing the orchestrator to turn failed checks into new work instead of treating an implementer's completion claim as sufficient.

Git repositories/worktrees, Beads issues, worker sessions and a merge queue.

A Mayor decomposes work and assigns it to worker harnesses. Tasks and assignments live in Beads and persistent worktree-backed hooks, so they survive a worker's conversation or process ending. Witness and Deacon roles monitor liveness and stuck work independently of the workers' inference loops. Completed branches enter the Refinery's verification and merge processing. Coordination state and integration status are therefore external to individual worker transcripts; replacing a worker does not imply recreating the entire task.

A local filesystem and shell, with configured external tools.

The core assembles history, tool schemas and hierarchical GEMINI.md instructions, invokes the model and feeds tool results into further decisions. Context compression reduces accumulated history, and configured model fallback handles provider failures. Built-in or custom subagents are exposed as tools; each runs a separate prompt/tool loop and returns findings without filling the main history with intermediate work. The generalist can perform multi-step coding work, while the optional browser agent uses Chrome accessibility information. Shell execution can retain interactive PTYs or start background processes, so a running server need not block further reasoning. The terminal is a client of these execution and session mechanisms.

A local working directory, shell processes and connected tool servers.

The CLI runs permitted model/tool rounds in a saved session. Large tool results become file-backed previews. Background compaction summarizes a snapshot while work continues, retaining instructions, plan state and later messages; execution waits if context space runs short. Built-in and custom subagents run separate contexts, and fleet mode delegates independent parts of a plan concurrently. Background tasks remain inspectable and stoppable. New input during execution steers the active task in order rather than entering a separate future-turn queue. Plan mode separates investigation from implementation, while autopilot can continue without repeated prompts. These local sessions are distinct from GitHub-hosted cloud-agent jobs.

An ephemeral GitHub Actions development environment, repository branches and pull requests.

A delegated request, schedule or supported repository event starts a cloud session. The agent investigates, edits and tests in its provisioned development environment. Repository operations carry changes into branches and pull-request workflows for review; comments and follow-up messages can initiate further work. Execution and collaboration state belong to the cloud job and GitHub artifacts rather than a local terminal. The workspace is provisioned for the run, so this is not simply IDE agent mode continuing in the background.

A local computer and services exposed by configured extensions.

A session combines instructions with extension-provided tools and repeatedly invokes the model and executes its requests. Recipes supply reusable task instructions and tool configuration. In autonomous mode, internal subagents run independent goose instances with inherited or narrowed context and extensions, sequentially or in parallel, and return results; timeouts and turn limits bound their lifetime. Other harnesses can also be connected as external agents. Older tool results are reduced in the background and the active history is later compacted, while the saved conversation remains available to the user. This separates the retained session from the smaller context sent on each inference.

A local workspace, version control, shell processes and configured tools.

A runtime component owns model calls and action dispatch, while workspace/tool components perform edits and execution. TUI, headless and ACP clients consume the resulting events. Hooks can allow, deny or request approval around actions. Child sessions run delegated tasks independently. Transient inference failures can be retried, and truncated responses have continuation handling that can preserve complete tool calls. These recovery paths operate on the execution stream rather than requiring the client to restart the entire session.

A local repository and shell, optionally connected to a JetBrains IDE.

The agent runs a coding conversation using file, command and optionally IDE-provided tools. The IDE supplies semantic context and configured development operations instead of requiring all information to be reconstructed from raw source. Multiple sessions can remain live while another is foregrounded. Event logs and transcripts retain execution activity. Delegated workers use their own prompts and tool restrictions and return results to the parent; a worker's context is separate from the main session.

A local working directory, shell processes, language servers and MCP services.

The OpenCode-derived CLI executes model-selected tools in saved sessions, with agent profiles controlling prompts, models and permissions. Task delegation creates a child with separate history and returns its summary. Foreground tasks block; background tasks return immediately and deliver results later. Children cannot directly question the user, so clarification must flow through results, shared files or configured coordination. Context can be compacted and conversations resumed independently of the terminal. Configuration also has a trust boundary: environment interpolation is restricted to trusted sources and project file references are confined to the repository. These are CLI mechanisms, not assumptions imported from Kilo's older extension.

A local repository and terminal, with optional multimodal inputs and MCP services.

The runtime builds session context, requests model actions and applies the active permission mode before execution. Built-in coder, explore and plan subagents handle focused parallel work in separate contexts. Per-agent event streams retain messages and request traces for replay and recovery, while model context can be compacted independently. Commands can continue as background tasks, and input can be injected into an active turn or the turn interrupted without exiting the application. Saved goals provide continuation across turns; forking a conversation does not duplicate its active goal. Plan mode normally pauses before execution, while explicitly unattended mode approves plan exits and tool calls automatically.

A local checkout or cloud sandbox with filesystem, shell and connected tools.

A standalone process owns conversation state, model selection and tool execution. Local clients communicate over ACP; remote clients connect to a sandboxed instance. Tool calls pass permission and pre-tool-hook checks, with results and post-tool feedback feeding later decisions. Subagents handle delegated work, while MCP servers and Powers add tool interfaces without making the client own execution. Steering files provide project instructions, specs retain requirements and task state, and compaction reduces older history. Checkpoints support branching and rewind. Cloud sessions can continue without a connected local client, separating execution lifetime from the editor or terminal displaying it.

Local or connected remote computers, workspace files and messaging/tool integrations.

The runtime loads an agent's retained memory and conversation and executes tools on the connected computer. Identity and stored context can persist when that computer changes. MemFS tracks editable context files in Git, and the agent revises memory blocks and skills for later tasks. Background subagents can perform general work, fork context or retrieve history; agents can call other retained agents rather than only temporary role prompts. Recall workers retrieve old information without placing all prior messages in the main prompt. Scheduled dreaming performs further inference to update memory. These changes affect stored context and behavior, not foundation-model weights.

A local repository, shell and configured code/tool execution environment.

The agent starts with limited context and retrieves code structure before loading selected source ranges, nested instructions or full tool definitions. Task subagents use separate disposable contexts and return summaries, keeping exploration out of the parent transcript. Generated Python can call tools as asynchronous functions, retaining intermediate values in the executor and returning printed output; independent tools can also be batched. Interrupted or timed-out work returns available partial evidence instead of silently discarding it. Compaction replaces older live history with a summary, while bounded on-disk archives retain previous logs. The runtime controls both what each step exposes and how much prior execution reaches the next model call.

A local repository, shell, filesystem tools and connected MCP services.

AgentController selects a thread and mode and runs the configured agent/tool loop, recording activity in LibSQL. Observer and Reflector processes extract and condense interaction history into memory for subsequent model calls rather than replaying an unlimited transcript. Threads and memory are stored separately from the terminal UI. Follow-up input queues until the active run finishes. Optional goal mode evaluates whether to continue, finish or wait, with bounded attempts around the underlying coding loop.

A local or containerized command environment containing the target repository.

The agent renders its task prompt, requests a response, parses an action and sends it to an environment executor. Returned output is appended to the message list before the next call. The default loop keeps counters and limits for calls, cost, elapsed time and consecutive formatting errors. Malformed responses become feedback for another attempt until the configured limit ends the run. The trajectory records actions, observations and termination information; there is no separate planner/worker service in this basic execution path.

A local project, shell processes and configured external tools.

The runtime alternates model responses and tool results under an agent profile that defines instructions and authority. Planning, approval-required execution and broader automatic execution are configurations of the same loop. The app server queues input arriving during work as later turns. Interruption stops the active turn and pauses the remaining queue until explicitly resumed. Delegated tasks execute in separate contexts and return findings without copying all intermediate reads into the parent's conversation.

A local source workspace and its development tools.

A main model/tool loop works alongside specialized agents that remain active for the session. These collaborators choose further investigation and when to communicate findings, rather than being recreated for each narrow task. Model calls, tool runs, approvals and edits are appended to a local event log used for replay and recovery. Bundled planning and critique workflows can gate execution, while goal mode continues toward an objective. The log supports recovery of runtime state without implying that every external side effect is automatically reversible.

A local repository, shell/code kernels, language servers and debugger sessions.

The Pi-derived conversation loop dispatches tools through editing and execution helpers. Persistent Python and Bun kernels retain variables and can call agent tools, keeping intermediate computation outside the transcript. Hashline edits bind requested changes to content-derived line anchors so stale targets can be rejected. Delegated workers receive scoped tasks and can return schema-validated outputs; worktree isolation is an execution option rather than a consequence of separate prompts. Worker lifecycle controls operate independently of the parent's conversation.

A local computer workspace, with optional browser/native-app QA tools.

The local Rust runtime selects a provider and harness profile, assembles that profile's model-facing action interface and executes returned actions. Profiles reimplement different prompt/tool conventions; they do not launch the original vendor's agent underneath. Configuration and session state remain local, with shared instruction/skill formats and MCP integration. ACP and Codex exec interfaces allow existing clients to drive the runtime. The QA skill adds browser/native-app tools to this coding workflow rather than changing it back into the historical Python-only application.

A local project, shell, language servers and connected MCP tools.

A session processor consumes streamed model events and dispatches approved tool calls, recording each as pending, running, completed or failed. Results feed the next model request. Task delegation creates or resumes child sessions with derived permissions and separate histories. Background tasks return immediately, accept additional context and notify the parent on completion; foreground tasks wait for results. Cancellation marks unfinished work instead of reporting success. Tool-output pruning and history compaction are distinct context controls, with overflow transferring control to compaction before another request. A repeated identical call can require permission to continue rather than allowing an unbounded repetition loop.

A repository and tools attached to a local, containerized or remote backend.

The backend owns the native OpenHands conversation, invokes the agent and dispatches tools into its attached workspace, streaming activity to clients such as Agent Canvas. History, agent configuration and persistent state belong to that backend conversation; workspace files are a separate resource. A local backend acts on the host, while container or cloud execution has its own mounts and environment. Branching history does not itself move the workspace. Canvas can also connect to other agents, but those retain their own execution loops.

Worker Git worktrees, subprocess sessions, SQLite mail and a merge queue.

A coordinator creates scoped assignments and runtime adapters launch the corresponding worker harnesses. Role instructions and task overlays configure workers; adapter-specific guards can restrict actions. SQLite mail carries dispatch, completion, escalation and merge-ready messages independently of the workers' model contexts. Process checks, triage and monitoring detect failed or stalled work, while checkpoints and handoffs support replacement. Finished branches pass through a merge queue, separating worker completion from repository integration.

A local repository, filesystem and shell processes.

Pi constructs model context from the active session branch, streams a response, validates and executes tool requests and appends their results. The loop continues while tools or steering input remain. Follow-up messages enter when it would otherwise finish, whereas steering can affect ongoing work at continuation boundaries. JSONL sessions retain branches and compaction records separately from the reduced model context. Extensions can alter tools, context and event handling with host authority; subagent orchestration is not inherent in the minimal default tool set.

A local workspace, shell, built-in tools and MCP services.

qodercli owns prompt assembly, live history, compaction and tool execution. Clients exchange agent events and correlated control messages with that process, allowing approvals, interrupts and callbacks while a run is active. Calls are checked against permissions and hooks before execution; compatible calls can run concurrently. A denied action becomes explicit model feedback. Subagents receive their own prompts, contexts and narrower tool sets, returning results rather than their entire conversation to the parent.

Workspace files, shell processes, MCP services and optional computer-control tools.

The runtime executes model/tool rounds in a session and retains worker state across background execution. Workers can start from scoped tasks or selected parent history; messages reach them at tool-round boundaries, and completed workers can resume. After compaction, recently used files or images can be restored to model context. The service mode exposes sessions through HTTP/SSE and ACP processes, with writer ownership preventing competing processes from mutating the same loaded conversation. Parallel sessions therefore remain distinct from concurrent writers to one session.

A local project workspace, shell processes, configured model providers and tools contributed through MCP or Reasonix extensions.

One local Reasonix engine owns the workspace session and is exposed through the terminal UI, desktop application, browser surface or an editor over ACP. Providers, the agent, enabled tools and plugins come from configuration rather than a model-specific hard-coded loop. The runtime keeps the model-facing prefix stable for DeepSeek caching: it injects a compact environment summary, prunes or clips stale tool output, and performs summary compaction only after this cache-aware maintenance. MCP servers can add tools, prompts and resources; sidecar extensions can observe runtime events and contribute providers or structured UI. Plan mode places write operations behind a read-only boundary, while permissions and a workspace sandbox constrain execution. Per-turn file checkpoints support rewind of workspace edits. An optional two-model arrangement keeps planner and executor in separate cache-stable sessions rather than repeatedly replacing one shared context. The same engine can run interactively or continue a non-interactive task, so the client interface is separate from the agent and execution state.

A repository prepared in a SWE-ReX-managed execution environment.

The agent builds a prompt from the task and history, parses the model's action and sends it to the environment executor. The configured interface determines available commands and how their observations are rendered back to the model. SWE-ReX handles environment setup, command execution and container lifecycle separately from prompting. Actions and observations accumulate until submission or another termination condition, with the trajectory retained for inspection. This is an execution harness for software tasks, not the benchmark that may invoke it.

A terminal workspace and repository, with optional cloud execution through Oz.

The local agent uses terminal output and project context to choose commands or edits and continues from their results. Warp Drive supplies reusable context; input can queue during work and older history can be summarized without removing the saved conversation. Optional Oz execution adds tracked cloud jobs and coordination of parallel subagents, including agents running other harnesses. Job tracking and steering sit above each selected harness's own model/tool loop. The announced cross-harness Agent Memory research preview stores and retrieves organizational knowledge across jobs rather than making every worker share a single transcript.

A desktop operating system and its applications.

The current Agent S3 uses a worker loop rather than the manager/subtask hierarchy of earlier versions. The worker receives the task and screen trajectory; an optional reflection agent reviews progress before the next action. A separate grounding model resolves visually described targets to coordinates, and the computer interface executes the input before another screenshot is captured. The runtime bounds the image trajectory, with text retention depending on the configured context strategy. An optional code agent provides Python/Bash execution alongside GUI control. Separate reasoning and grounding models do not themselves isolate host execution.

A computer workspace with a browser, desktop applications, files and terminal processes.

The application maintains one task trajectory across browser, GUI and terminal operations. Each model response selects actions; executors perform them and return observations for subsequent reasoning. The browser path can use structured page information and DOM operations instead of always predicting coordinates, while visual control remains available. Interaction events are streamed to clients. Files and other tool effects remain in the workspace, so changing the action interface does not start an unrelated task.

A live browser session with pages, tabs and session state.

BrowserSession gathers DOM-derived page state and optional screenshots; a message manager combines these with task history and agent memory for inference. The model returns structured state and an action list. The controller executes actions sequentially but discards the remaining batch after navigation, a changed URL or focused target, completion or error, then observes again. Files hold extracted material and working notes outside the prompt. Step and failure limits bound retries, and pause/stop checks run at execution boundaries while the browser can remain open. Saved histories support inspection and replay with element re-identification, not transactional browser rollback. Explicit completion can pass through additional validation.

A connected mobile device and its installed applications.

MobileAgent selects between a reasoning strategy and a direct tool-calling strategy. In reasoning mode, a manager proposes work and an executor performs device actions, returning outcomes for further planning. FastAgent emits actions directly. Both use device integrations rather than manipulating a simulated text interface. Shared MobileAgentState retains the plan, action history and failures across component calls. Accessibility information and optional screenshots provide complementary observations; the visible screen need not be the only source of UI structure.

The user's Chromium tabs and their existing site sessions.

The executor repeatedly runs a navigator against the current browser state. It invokes a planner periodically or when the navigator reports completion, rather than planning again before every click. Both roles use shared task context to assess progress and choose subsequent work. Pause and stop state are checked at execution boundaries. The extension acts in the existing browser, including its authenticated sessions, rather than moving the task into a newly provisioned virtual computer.

Chromium sessions, websites and stored workflow artifacts.

A planner decomposes the request into subgoals, and a task agent repeatedly selects actions from current screenshots and DOM information. Playwright executes those actions; fresh observations and a validator determine whether to continue or retry. Tasks can form parts of stored workflows with separate run status, browser sessions and artifacts. Credentials are injected into the browser by the execution path rather than included as plain prompt content. This combines model-driven page interaction with workflow state outside the agent transcript.

Windows applications accessible through UI Automation, screenshots and application APIs.

A HostAgent selects applications and coordinates AppAgents through a global state machine. Each AppAgent runs its own observation/action loop, combining screenshots and UI Automation controls with retrieved documentation, demonstrations and prior execution traces. A Puppeteer executor selects GUI operations or native application APIs. Speculative multi-action execution batches likely actions and checks them against live UI state, reducing repeated inference without blindly executing a stale plan. Application-local reasoning and host-level task state remain separate. The device agent can run independently or accept Galaxy assignments; an isolated picture-in-picture desktop is described as planned, not an assumed execution boundary.

Connected computers and their device-agent sessions.

A ConstellationAgent decomposes a request into TaskStars and dependencies. A TaskOrchestrator schedules ready tasks on devices while downstream tasks wait for their prerequisites. Results can cause controlled changes to the remaining graph, making dependencies part of runtime state rather than a static plan shown to the user. Device agents retain responsibility for their local browser/application operations. The coordinator acts at the task level instead of predicting every input event on each machine.

A desktop or browser operated through the selected computer operator.

The agent captures a screenshot, combines it with the task and history, and asks a vision model for an action. A parser converts the response into the operator's executable representation. After execution, a new screenshot closes the feedback loop. The operator separates device control from model inference, while history retains the sequence needed to assess progress. Iteration limits and an abort signal stop execution rather than merely suppressing the interface's streamed text.

Configured terminal/browser backends, a workspace and connected messaging channels.

CLI input, gateway messages and scheduled jobs enter the same model/tool orchestration engine. It constructs context, executes tools, retries failures, compresses history and saves sessions. Delegated subagents run isolated workstreams, while generated Python can call tools through RPC and return selected results instead of every intermediate value. A process registry manages background commands beyond a single tool call. User input or signals can cancel model calls and tool execution mid-flight. SQLite session search, writable memory and learned skill documents supply later tasks without replaying every prior conversation. Terminal and browser actions dispatch to the configured local or isolated backend.

Messaging/web channels, a persistent workspace and configured execution backends.

Message handling enters an agent loop that coordinates work with a parallel-job scheduler; cron, event and webhook routines can also trigger execution. Docker-backed jobs run under separate worker credentials, keeping their lifetime outside the channel handler. Untrusted WASM tools receive restricted capabilities, and the host mediates endpoint access and credential injection. Built-in and MCP tools are separate execution paths, not automatically covered by that WASM boundary. Workspace search retrieves durable information for the active context.

Chat channels, a local workspace and configured tools/background jobs.

The message bus routes input to a session, whose loop assembles history, memory and skills before invoking the model and executing tools. A subagent manager runs delegated work separately and delivers its result back through the messaging machinery. The original foreground call need not stay open. Session history records interaction, while consolidation moves durable information into workspace memory as context grows. Task/session state and checkpoint handling support continuation outside the current model request.

Messaging channels and per-agent mounted container workspaces.

The host routes messages to an agent/session and launches its execution in a container, using Claude Code through the Claude Agent SDK by default. The container reads mounted workspace material, executes tools and returns output; channel delivery and scheduling remain host responsibilities. Several channels can share an agent's instructions and memory while retaining separate conversations, or be configured to share a session. Distinct workspaces establish a filesystem boundary beyond role prompts. Other execution providers can be configured per agent group.

Messaging channels, workspace files, configured services and scheduled tasks.

The gateway resolves messages or scheduled work to a session, loads workspace instructions and skills, and starts the selected agent runtime. Runs are serialized per session key, while other sessions proceed independently. Mid-run input follows steer, follow-up, collect or interrupt policy. Delegated subagents run background sessions with separate context, or an explicit fork, and announce results to the requester; configured nesting and tool restrictions bound their authority. Persistent visible child sessions can receive later messages, distinct from one-off subagent runs. Transcript writer claims prevent superseded runs from committing stale streaming or compaction updates. Run deadlines and cancellation govern execution even when a client is no longer displaying it.

Scheduled web/tool workflows and a persistent agent workspace.

Activating a Hand instantiates an agent from a manifest, playbook and skills rather than only supplying a free-form user prompt. The manifest declares tool access and operating requirements; the runtime manages recurring execution and pause/lifecycle state. Session storage and compaction preserve useful context between work units. Calls dispatch through built-in, MCP or metered WASM paths, whose isolation properties differ. The continuing operator's state is separate from any one model response or foreground chat.

Chat/desktop channels, workspace resources and configured tools or scheduled tasks.

An AgentScope-based model/tool loop runs inside an agent-specific resource, policy and sandbox configuration. Channels and schedules enter this execution machinery, and subagents can take delegated work with separate memory and skills. ScrollContext persists complete turns and indexes material removed from the live prompt for later recall. ReMe separately extracts linked Markdown knowledge from conversations and resources. Live context, verbatim history and derived knowledge therefore have different storage and retrieval paths. Tool and connector calls cross the configured policy boundary, while workspace checkpoints and retained conversations support continuation beyond one interaction.

The web and connected information sources.

A lead researcher plans and delegates scoped questions to workers, each searching iteratively in its own context. Their findings return to the lead, which can commission further investigation before synthesis. The plan is saved outside the current context to support continuation after history reduction. Workers filter evidence rather than transferring every search transcript to the lead, and independent searches can run concurrently. A citation stage identifies source locations supporting the resulting report.

Sandbox workspaces, uploaded files, web sources and stored research jobs.

A lead agent runs tools directly or delegates to workers with their own model/tool histories. The parent receives structured results rather than the workers' full transcripts. Ordinary delegation and durable batches are distinct: batch items are stored in SQL with concurrency limits and restart recovery, and results are exposed in bounded form. Optional goal evaluation can continue work after checkpoints, subject to attempt and no-progress limits. User input and concurrent thread changes can prevent that automatic continuation.

Web sources, code-execution facilities and optional supplied documents or MCP services.

The caller starts a background interaction; the service owns the research loop and exposes progress, completion or failure through the interaction ID. The agent iteratively searches and reads, uses the configured tools and synthesizes its findings. Optional collaborative planning returns a proposed plan before research executes, allowing follow-up interactions to refine or approve it. Conversation linkage preserves that planning context. The client polls or streams the long-running interaction rather than implementing its own model/tool dispatcher.

Search services, retrieved web pages and optional local documents.

The researcher prepares an outline and subqueries, then collects relevant context asynchronously. Shared visited-URL tracking avoids repeatedly fetching the same sources, and tool results can be cached. Web search, supplied URLs and local documents provide alternative evidence paths. Report generation consumes the collected research context as a separate stage. Parallel retrieval here is primarily concurrent evidence collection, not a requirement that every query spawn an independently persistent agent conversation.

Web/document sources and a configured code-execution sandbox.

Input preprocessing prepares task context for an iterative model/tool loop. The agent calls MCP tools or configured subagents, accumulates results and eventually summarizes its trajectory into an answer. Malformed arguments, truncation, refusals or repeated calls can cause a failed interaction turn to be removed and retried with feedback. Turn and rollback limits bound this recovery. Rollback refers to conversation state, not reversal of side effects already performed by tools; a retry must still account for the external environment.

Search/read tools and configured research data sources.

The workflow clarifies the request and creates a research brief before a supervisor dispatches research tasks. Each worker iterates over tools in its own context and compresses its findings before returning. The supervisor coordinates those notes rather than inheriting every raw search message, and can delegate further work before synthesis. Concurrency and iteration limits bound the loops. Report generation is a separate stage with its own handling of context-budget pressure.

Web search and optionally supplied document collections.

STORM discovers perspectives and simulates writer/expert interviews, using retrieval to ground answers and generate follow-up questions. The collected references inform an outline and a later writing stage. Co-STORM instead supports an ongoing discussion among experts, a moderator and the user. Its turn policy coordinates contributions, and a changing mind map retains organized knowledge outside the linear dialogue. The moderator can surface retrieved material not yet used, allowing discussion to change the investigation rather than merely summarize existing answers.

A research project containing papers, datasets, ML programs and report files.

The application passes work through literature, experimentation and reporting stages, with opportunities for human feedback. An experiment solver maintains the current program and proposes edits or replacements. Candidates are executed before acceptance; a failed replacement does not become the working program, and execution errors feed repair attempts. Retained code and experimental results then supply the reporting stage, rather than a conversational description standing in for the experiment.

A dataset and execution workspace for candidate ML solutions.

A search policy chooses a new draft, a failed leaf to debug or the best successful node to improve. The model generates code, an executor runs it and result analysis appends a child node to the journal. Nodes preserve code, parentage, output and scores, making the tree the working state. Exceptions and missing or invalid metrics mark a result as buggy. Drafting and debug-depth limits bound exploration; the metric's direction determines which valid solution is preferred.

A scientific environment containing biomedical datasets, APIs, installed software and analysis files.

Retrieval selects task-relevant tools, datasets and software descriptions before the model starts executing work. The model alternates executable code blocks with environment observations and eventually produces a solution. Generated code can compose several scientific operations without a model round trip for every intermediate value. Parsing failures generate corrective feedback. Installed resources and produced artifacts remain outside the prompt; execution uses the configured scientific environment rather than an implicitly guaranteed sandbox.

A project containing user datasets, analysis code, figures and LaTeX files.

The workflow progresses through data description, idea, method, analysis and paper stages. Intermediate products live in a project and can be replaced by the user before downstream work resumes. The analysis stage uses the configured research backend, including cmbagent, to perform calculations and produce results and figures. Manuscript generation consumes those outputs. This organization makes human intervention a change to explicit project state rather than an attempt to correct every later stage through one growing chat transcript.

Scientific datasets, literature, code sandboxes and a shared filesystem.

The scientist repeatedly proposes analyses, executes code and uses results to revise its investigation. A stored scientific world model records hypotheses, experiments and beliefs outside the current conversation. Delegated agents execute in separate sandboxes but share artifacts through a common filesystem, allowing compute to scale without copying every dataset through model context. Long-lived execution environments support continuing work and user steering. A service proxy mediates authenticated access rather than handing service credentials directly to generated code.

Literature sources, executable ML experiments, compute resources and paper artifacts.

An ideation stage produces a research proposal, then an experiment manager guides progressive tree search over executable candidates. Independent roots and parallel workers explore alternatives; nodes retain code and outcomes for improvement or debugging. Logs and the experiment tree live in a run directory outside model context. After the experimental stages, analysis and manuscript generation consume those artifacts. The application executes model-written code; deployment must provide the intended isolation rather than assuming the research workflow itself guarantees it.

A Linux container with a desktop, browser, terminal and workspace files.

An agent builds a prompt from instructions, history and additional context, streams a response and executes its requested tool until the current task returns a response. Subordinates run with separate contexts and return results to their superior. Intervention checks before inference and during streaming allow active work to be redirected. Extension hooks participate in prompt preparation and model/tool handling. The actual desktop and artifacts live in the container and can be inspected independently of the conversation.

A task workspace spanning supplied and connected files, application data, cloud or built-in browsers, and—on supported desktop configurations—local applications and computer interaction.

A Work conversation owns a continuing task rather than a single model response. The runtime selects among connected applications or plugins, file and artifact tools, and browser/computer interaction according to the available surface and permissions. Cloud-browser work runs on a separate remote computer with its own site sessions and can continue after the user leaves; it pauses when input, sign-in, takeover or confirmation is required. On desktop, built-in browser and computer-use paths can operate on visible web or local application environments under approval and workspace policies. Progress remains inspectable while the user answers questions, changes direction or approves consequential actions. Scheduled Tasks re-enter the runtime once, repeatedly, on a schedule or as monitors, so execution state and timing are not limited to the foreground conversation. This is the current successor to the earlier Operator, ChatGPT agent and Atlas product paths rather than another record for those retired interfaces.

Web pages, local documents, code files and a command-execution environment.

An orchestrator maintains a task ledger of facts and a plan, then directs WebSurfer, FileSurfer, Coder or ComputerTerminal. After worker responses, a structured progress ledger determines whether the goal is satisfied, whether execution is looping and which worker should act next. Repeated lack of progress causes the orchestrator to revise its ledger and restart coordination. The team has prescribed roles and explicit control state rather than letting every worker independently decide the global workflow.

A task workspace with browser, terminal, filesystem and external tools.

In the published design, the model repeatedly selects tools and continues from their outcomes within a persistent workspace. Intermediate material is saved to files so the prompt can retain references instead of all content. The runtime preserves a stable context prefix for caching and constrains permissible actions without repeatedly rebuilding tool definitions. Task notes bring current goals back into recent context, and failed attempts remain available as feedback. The filesystem holds recoverable working material beyond what the model currently sees.

A cloud workspace, web/browser tools, connected applications and scheduled jobs.

The service composes search, code, browser, document and connector operations inside a persistent cloud sandbox. Domain-specific assistants handle parts of a workflow and a coordinator routes work between them; wide research can search independent items in parallel. Workspace artifacts, preferences and memory persist across sessions. Tasks can continue asynchronously or run on schedules. Most scheduled runs start fresh isolated agents with no originating conversation context, while browser control, document creation or conversation-dependent work uses attended execution. Blocked jobs surface a needs-attention state; exhausted credits pause active work and resume when credits return. Public documentation does not expose the internal queue or context-compaction algorithm.

Configured games and desktop applications, including Red Dead Redemption 2.

Cradle gathers visual information, reflects on recent behavior and updates its task understanding before selecting actions or skills. A registry maps those decisions to atomic or composite input routines; the resulting screen supplies feedback for the next planning cycle. Memory and skill curation retain useful behavior above individual key presses. Timing depends on the environment adapter: the documented Red Dead Redemption 2 and Stardew implementations pause the game during model reasoning and unpause it for execution. They therefore do not require the model to deliberate continuously at game speed. Progress is inferred from screen effects rather than authoritative internal game state.

A live Minecraft server accessed through Mineflayer.

Chat and self-prompted goals drive model decisions that become commands or generated code. Mineflayer executes these while Minecraft continues evolving. The action manager records current and resumable behavior, stops movement, combat and collection when replacing work, applies timeouts and returns execution feedback. Idle handling can restart resumable actions; reactive modes respond alongside deliberation rather than waiting for a model call for every event. Other bots communicate through a conversation manager rather than one shared model context. Saved history, goals and memory restore task continuity after restart, but resumption may re-invoke behavior rather than restore a suspended JavaScript stack.

A live Minecraft server controlled through Mineflayer.

Events or heartbeats trigger context gathering and a repeated model/tool loop. A command queue serializes runs so simultaneous triggers do not compete to control the bot. Game integration and reconnection handling remain active outside an individual inference call; heartbeat behavior can depend on nearby players. JSONL history, memory notes and todos preserve continuity, while stored transcripts omit image payloads. Rendered views supplement structured game tools rather than replacing all programmatic observations.

Minecraft accessed through Mineflayer and an execution environment for generated behaviors.

A curriculum agent chooses a task from current world state and progress. The coding agent retrieves relevant skills, produces a JavaScript program and executes it through Mineflayer. Environment feedback and a critic drive iterative repair; only successful behavior enters the searchable skill library. Checkpoints preserve curriculum, events and learned skills for resumption after process restart. Learning therefore means accumulating reusable code and descriptions, not updating model weights. Generated programs perform temporally extended actions without a model call for every game tick, while the higher-level curriculum, coding and critic cycle remains sequential rather than a multi-bot controller.

A Unitree Go2 robot or its configured simulation/replay environment.

The blueprint launches robot connections, agent/MCP components and perception/control modules as a connected graph. Typed streams continue updating independently of language inference. At startup the agent discovers skill methods exposed by launched modules; it reads their descriptions, observes exposed images and state, and calls skills whose results inform further reasoning. Robot-side modules handle movement and control rather than asking the model to schedule every sensor update or motor command. Daemon execution keeps this graph running without a foreground terminal. Hardware, simulation and replay connections supply different inputs to the same configured module graph.

A ROS 2 robot or simulation with perception, world-state, skill and safety components.

A world-state aggregator supplies the slow reasoner with a bounded situation report, mission ledger and retained memory. Prioritized safety, execution and operator events can trigger decisions; idle heartbeat ticks skip inference, and perception updates need not trigger it. Each decision is a validated typed call drawn from installed, capability-matched skills or state/perception tools. Fast skill policies execute goals below the reasoner and return acceptance, completion, failure or timeout events while robot processes continue. An explicit task queue advances through critic and reward checks and can subdivide blocked work within limits. The model never directly publishes motor actions. A Python safety supervisor and stop forwarders are implemented; the certifiable C++ kernel and full replanning ladder remain incomplete.

A simulated Franka Panda arm connected to ROS 2 perception and control services.

A multimodal tool-calling agent interprets a natural-language task and plans a manipulation sequence. It invokes ROS 2 detection and segmentation services backed by Grounding DINO and Grounded SAM 2, then calls robot-control operations for arm and gripper motion. Service outcomes return to the agent for further decisions. Perception and control therefore run as separate components outside the model, and the language model does not generate high-frequency joint commands. The packaged demo uses a simulated Franka Panda; the documented loop is sequential tool use rather than a persistent multi-agent or real-time supervisory hierarchy.

A ROS TurtleSim simulation and its middleware interfaces.

The supplied demo configures a tool-using model with ROS inspection and turtle-control operations. A request becomes middleware calls, whose results return to the agent for continued execution. The robot-specific configuration and running simulation supply the concrete behavior beyond ROSA's generic library interface. Movement is mediated through ROS tools rather than pixel-level mouse control or model-generated motor torques. The Docker demo packages the environment needed to run this interaction.

Authorized targets, terminal security tools and saved assessment sessions.

The application wraps Claude Code or Codex with a staged assessment workflow. CTF work progresses through reconnaissance and exploitation; pentest workflows carry findings from asset discovery into vulnerability work and reporting. The backend performs the underlying model/tool execution, while PentestGPT contributes domain instructions, stage transitions and continuity of assessment state. Saved sessions and intermediate findings support resumption and report production instead of requiring each phase to reconstruct the investigation from scratch.

Application source code, an authorized running target and per-scan containers.

Reconnaissance and code analysis generate candidate findings. Reconciliation merges overlapping candidates into an exploitation workload, after which execution against the live target supplies validation evidence for reporting. Per-scan Docker environments contain tools and artifacts. The staged state separates a code-derived suspicion from an observed test result; it does not make a model's explanation alone proof that exploitation succeeded.

Authorized targets, application code, browser/proxy traffic and sandbox tools.

Each agent runs a streamed model/tool session under a coordinator that tracks running, waiting and terminal states. Waiting for other agents is represented explicitly rather than consuming an endless reasoning loop. If a response ends without the expected lifecycle transition, bounded recovery requests continuation. Image budgets and compaction constrain context, while runtime failures follow retry or parked-failure paths and can notify a parent. The security tools execute hypotheses against the target; narrative findings and observed test evidence remain different outputs.

A live phone or web-audio call and configured business services.

A per-call runtime coordinates transcription, model responses, function execution and speech synthesis. Audio keeps arriving during speech output and other work. Endpoint and pause-delay settings decide when an utterance is ready for inference; an interruption threshold determines when incoming speech cuts into output, with designated stop words pausing it immediately. Silence timers can initiate a presence check without another message. Conversation state and turn timing therefore surround the model rather than being delegated entirely to it.

A live RTC audio channel and a configured weather service.

The supplied graph routes Agora RTC audio to Deepgram recognition and connects a control extension to an OpenAI-compatible model, ElevenLabs synthesis and a weather tool. The controller queues finalized transcripts for the model and forwards partial model text to TTS, allowing playback before the response finishes. Incoming speech can interrupt this work: the controller flushes the model request, TTS generation and RTC playback buffers rather than merely hiding output. Audio transport continues independently of inference. Tool results return through the controller, while bounded dialogue history supplies later requests. This describes the packaged voice-assistant graph, not every pipeline TEN can assemble.

A live call and its connected business APIs.

A call session connects streaming transcription, model decisions, tools and synthesized speech. Speaking policies and interruption or silence hooks operate while model or API work is pending, determining when playback starts or stops. API Request tools block progression until a result or timeout, with retry and progress-speech handling; other tools may be asynchronous. A Squad can transfer the same call between assistants with different prompts and tools. Handoff configuration selects how much history and extracted information reaches the next assistant, rather than treating each specialist as a concurrent speaker. Call transport and tool lifecycle remain outside individual model requests.

Financial-data services, web sources and a working directory for analysis artifacts.

The agent combines conversation, workspace instructions and memory, then iterates over financial-data and computation tools. Safe read-only calls can run concurrently. Focused research can be delegated to workers using the same model but separate prompts, tool allowlists and iteration limits; they receive explicit task and context, not the parent conversation or memory, cannot delegate further, and return a final answer. Several worker calls can execute in parallel, with cancellation propagated from the parent. Large results are saved to files, older tool content is reduced, and broader compaction can first flush useful information into memory. Queued user messages enter after a tool round. CLI-only tools are omitted on non-interactive surfaces.

Market, news and fundamental-data services plus saved decision records.

Analyst reports feed bull/bear research debate, a research manager, a trader proposal, risk discussion and a final portfolio decision. Reports and debate histories are passed as graph state rather than each role freely choosing the overall workflow. Decision logs can later be evaluated against realized and benchmark-relative outcomes, supplying lessons to subsequent same-ticker decisions. Optional per-ticker SQLite checkpoints allow successful steps to resume. The workflow produces analysis and decisions; it does not by itself imply brokerage order execution.

A database-backed simulated social platform with posts, feeds and relationships.

Each simulation step activates selected agents, presents their social context and executes generated actions against shared platform state. Posts and relationships persist in the environment database, changing what other agents can subsequently encounter. Recommendation rules mediate observations rather than placing the entire network in each prompt. Activation probabilities and explicit steps control participation. Asynchronous agent execution supports a changing shared world, but the simulation clock is not a guarantee of real-time physical interaction.