Modern Agent Harnesses

Paul Gauthier and contributors

A Git working tree and its local development commands.

• Selected file contents and a token-budgeted repository map
• User feedback and configured lint/test output

• Apply source edits and run configured validation
• Create or undo Git commits for agent changes

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.

• Aider repository map ↗
• Aider architect and editing modes ↗
• Primary source ↗

Amp

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

• Repository search results, files and command output
• Selected prior-thread content and oracle responses

• Inspect and edit code; run development commands
• Consult an oracle model

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.

• Tools and oracle ↗
• Threads and execution hosts ↗
• Primary source ↗

Google

Development workspaces, including shared directories and separate Git worktrees.

• Source files, command results and connected-tool responses
• Worker messages and results

• Edit code and execute development tools
• Launch and communicate with scoped workers

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.

• CLI features ↗
• Subagent runtime ↗
• Agent commands ↗
• Primary source ↗

Augment

A local repository, terminal processes and configured integrations.

• Repository context retrieved by the Context Engine
• File contents, command output and hook feedback

• Search, inspect and edit code
• Run commands and integration tools; delegate scoped work

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.

• Interactive agent ↗
• Hook execution contract ↗
• Auggie subagent contexts and execution ↗
• Primary source ↗

Anthropic

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

• File/search results, command output and tool responses
• Project instructions, selected skills and subagent findings

• Edit files and run commands or connected tools
• Delegate scoped work and start background tasks

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.

• How Claude Code works ↗
• Claude Code subagent execution and configuration ↗
• Agent execution loop ↗
• Claude Code persistent memory ↗
• Claude Code experimental agent teams ↗
• Claude Code dynamic workflow runtime ↗
• Claude Code goal-controlled continuation ↗
• Primary source ↗

Cline

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

• Source files, search results and compiler/linter diagnostics
• Command output, external-tool results and worker findings

• Edit files and run development commands under approval policy
• Delegate work through supported CLI team modes

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.

• cline/cline: README.md ↗
• Primary source ↗
• Repository ↗

OpenAI

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

• File/search results, tool responses and streamed command output
• Project instructions, steering messages and worker/review results

• Edit files and run commands under sandbox/approval policy
• Use running-process handles and delegate work or reviews

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.

• Codex app-server protocol and execution ↗
• Codex subagent execution and permissions ↗
• Primary source ↗

Charm

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

• Files, search results and language-server responses
• Command output and MCP tool results

• Inspect and edit the working tree
• Run shell commands and connected tools

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.

• Crush shared-workspace architecture ↗
• Primary source ↗
• Repository ↗

Cursor

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

• Codebase search results, files, command output and browser observations
• Workspace instructions, user steering and subagent results

• Search and modify source code; execute commands and inspect validation results
• Operate configured browser tools and delegate foreground, background or cloud work

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.

• Cursor Agent tools, checkpoints and steering ↗
• Cursor subagents, background execution and isolation ↗
• Primary source ↗

LangChain

A configured filesystem backend, execution sandbox and external services.

• File contents, tool results and execution output
• Summarized history and delegated-task results

• Read and write files; execute commands when the backend supports them
• Delegate tasks and invoke configured external tools

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.

• langchain-ai/deepagents: README.md ↗
• Default harness overview ↗
• Primary source ↗
• Repository ↗

DeepSeek AI

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

• File and search results, shell output and responses from configured tools or skills
• Session events recording prompts, reasoning, tool calls, results, subagent scheduling and context injection

• Inspect and edit files, run shell commands, search files or the web, and invoke plugin-provided tools and skills
• Plan goals, launch subagents and workflows, or generate TypeScript programs that coordinate multiple tool calls

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.

• DeepSeek Harness architecture, runtime modes and session log ↗
• DeepSeek Harness repository and local execution ↗
• Primary source ↗
• Repository ↗
• Documentation ↗

Cognition

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

• Source code, command output, browser/desktop observations and reusable project knowledge
• User feedback, child-session progress and recorded workflow results

• Edit and test code, run development processes and operate browser/desktop interfaces
• Coordinate managed Devin sessions and execute resumable agent workflows

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.

• Devin environments and operational feedback loops ↗
• CLI-to-cloud handoff ↗
• Devin managed sessions and persistent guidance ↗
• Devin deterministic workflow execution and resumption ↗
• Devin desktop observation and control ↗
• Primary source ↗

Cognition

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

• Files, command output and worker results
• User feedback and permission decisions

• Inspect, edit and test local code
• Delegate work or transfer the task and repository changes to cloud Devin

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.

• Subagents ↗
• Cloud handoff ↗
• Primary source ↗

Factory

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

• Source code, command/test output and service responses
• Worker findings and independent validation results

• Modify and test code; invoke connected tools
• Assign implementation or validation work and resume workers

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.

• Factory: model routing belongs in the harness ↗
• Missions architecture ↗
• Custom droids ↗
• Primary source ↗

Steve Yegge and contributors

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

• Issue and assignment state, worker messages and liveness information
• Verification results and merge outcomes

• Dispatch work to coding harnesses and recover or replace workers
• Queue, verify and integrate completed branches

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.

• Gas Town architecture ↗
• Primary source ↗
• Repository ↗

Google

A local filesystem and shell, with configured external tools.

• Files, search results and command output
• Hierarchical workspace instructions and external-tool responses

• Inspect and edit files; execute foreground, interactive or background shell commands
• Delegate scoped work and use configured browser or 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.

• google-gemini/gemini-cli: docs/core/index.md ↗
• Gemini CLI subagent runtime ↗
• Gemini CLI shell process execution ↗
• Primary source ↗
• Repository ↗

GitHub

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

• Read/search results, command output and MCP responses
• Worker results and retained session summaries

• Edit files and execute development commands
• Delegate to built-in or custom subagents, including parallel fleet tasks

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.

• Context management ↗
• Fleet and parallel execution ↗
• Copilot CLI custom agents and separate contexts ↗
• Copilot CLI steering semantics ↗
• Copilot CLI fleet execution ↗
• Primary source ↗

GitHub

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

• Repository files and build/test results
• Delegated task instructions, comments and follow-up messages

• Modify and test code in the cloud workspace
• Create commits, push branches and prepare pull-request changes through the service

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.

• GitHub Copilot cloud execution environment ↗
• Primary source ↗

Agentic AI Foundation / goose contributors

A local computer and services exposed by configured extensions.

• File and command results from enabled tools
• Extension responses and retained conversation context

• Perform filesystem and terminal operations through enabled tools
• Execute recipes and delegate work to configured internal or external agents

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.

• aaif-goose/goose: README.md ↗
• Goose layered context management ↗
• Goose recipes and subrecipes ↗
• goose subagent execution and lifecycle ↗
• Primary source ↗
• Repository ↗

xAI

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

• Files, command output and tool responses
• Worker results and approval feedback

• Inspect and edit code; run commands
• Delegate work to child sessions

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.

• Runtime repository ↗
• Grok Build overview ↗
• Execution changes ↗
• Subagents and extensions ↗
• Primary source ↗

JetBrains

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

• Source files and command output
• IDE indexing, semantic analysis and build/test information when connected
• Delegated-worker results

• Inspect and edit code and execute development commands
• Launch scoped workers and use connected IDE tooling

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.

• CLI sessions ↗
• IDE integration ↗
• Subagent contracts ↗
• Primary source ↗

Kilo Code

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

• File/search results, diagnostics and command output
• Configured tool responses and permission decisions

• Edit files and run development commands or connected tools
• Delegate foreground or background tasks to scoped subagents

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.

• Kilo Code repository ↗
• CLI configuration and execution ↗
• Kilo CLI subagent sessions and background behavior ↗
• Primary source ↗
• Repository ↗

Moonshot AI

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

• File contents, command output and MCP responses
• Supplied image/video inputs and per-session history

• Edit files, execute commands and invoke configured tools
• Delegate focused work and move commands into background tasks

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.

• Kimi Code permissions and turn control ↗
• Kimi Code session and request traces ↗
• Current Kimi Code CLI ↗
• Primary source ↗
• Repository ↗

AWS

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

• Files, tool results and command output
• Steering instructions, specs and hook feedback

• Inspect and modify code; run development and connected tools
• Maintain requirements, designs and task specifications and delegate work to subagents

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.

• How Kiro works ↗
• Primary source ↗

Letta

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

• File and command results from the connected computer
• Retrieved conversation history, memory blocks and skills

• Inspect and modify files; execute configured tools
• Delegate background work and edit persistent memory or reusable skills

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.

• letta-ai/letta-code: README.md ↗
• Primary source ↗
• Repository ↗

tontinton

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

• Indexed definitions, signatures and requested source spans
• Printed execution output, tool results and partial results from interrupted work

• Read and edit code and run commands
• Delegate scoped work, compose tool calls in Python or batch independent operations

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.

• Token economy ↗
• Context handling ↗
• Primary source ↗

Mastra

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

• Code and tool/command results
• Observations and summaries produced from prior interaction history

• Read and edit code; execute development commands
• Invoke connected tools and work toward a saved goal

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.

• Mastra Code ↗
• Packaged controller and storage ↗
• Architecture introduction ↗
• Primary source ↗
• Repository ↗

SWE-agent team

A local or containerized command environment containing the target repository.

• Command output and exit/error information
• The accumulated task and action/observation history

• Execute shell actions to inspect, modify and test the repository
• Submit the task result

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.

• SWE-agent/mini-swe-agent: src/minisweagent/agents/default.py ↗
• Primary source ↗
• Repository ↗

Mistral AI

A local project, shell processes and configured external tools.

• Source files, command results and external-tool responses
• Findings from scoped subagents

• Inspect and modify code; run commands under the active profile
• Delegate tasks such as read-only repository exploration

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.

• mistralai/mistral-vibe: README.md ↗
• Primary source ↗
• Repository ↗

Meta

A local source workspace and its development tools.

• Repository content, execution results and user inputs
• Reports from background collaborators and retained event history

• Write, compile, test and revise code
• Coordinate background investigation and goal-directed work

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.

• Muse Code architecture and release ↗
• Primary source ↗

can1357 and contributors

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

• Source files, code/kernel results and development-tool responses
• Worker results and schema-validation feedback

• Apply anchored edits, execute commands or code and use development tools
• Launch scoped workers, including separate-worktree tasks

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.

• Oh My Pi README ↗
• Primary source ↗
• Repository ↗

Open Interpreter

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

• Files, command output and configured tool responses
• Browser or native-app observations when the QA skill is used

• Edit code and run commands under configured sandbox/permission controls
• Test browser or native interfaces through 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.

• Current Open Interpreter Codex-derived runtime ↗
• Primary source ↗

Anomaly

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

• File/search results, command output and tool responses
• Recorded tool status and permission feedback

• Inspect and edit project files; execute shell, language-server and external tools
• Create, resume and coordinate foreground or background subagent tasks

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.

• anomalyco/opencode: packages/opencode/src/session/processor.ts ↗
• OpenCode delegated and background task execution ↗
• Primary source ↗
• Repository ↗

OpenHands

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

• Source files, command output and other workspace-tool observations
• Retained conversation context and user feedback

• Modify source files and run development commands
• Inspect results and continue repository tasks

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.

• OpenHands Agent Canvas execution boundaries ↗
• OpenHands/software-agent-sdk: README.md ↗
• Primary source ↗
• Repository ↗

jayminwest and contributors

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

• Worker messages, process status and checkpoint information
• Verification, failure and merge results

• Assign work and launch or replace coding workers
• Send coordination messages and queue branches for integration

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.

• Overstory architecture ↗
• Primary source ↗
• Repository ↗

Mario Zechner / Earendil Works

A local repository, filesystem and shell processes.

• File contents and tool/command results
• The active session branch, loaded instructions and queued steering messages

• Read, write and edit files and execute Bash commands
• Invoke additional tools supplied by extensions

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.

• earendil-works/pi: packages/coding-agent/README.md ↗
• earendil-works/pi: packages/agent/src/agent-loop.ts ↗
• Primary source ↗
• Repository ↗

Qoder

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

• Files, command output and tool responses
• Permission denials, hook feedback and subagent results

• Inspect and modify code; execute commands
• Invoke connected tools and delegate scoped tasks

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.

• SDK/runtime architecture ↗
• Primary source ↗

Qwen / Alibaba

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

• File/search results, command output and external-tool responses
• Recent images and worker results when those tools are used

• Edit code, execute commands and invoke configured tools
• Launch fresh or forked workers and send follow-up work

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.

• Agent tool ↗
• Context configuration ↗
• Conversation writer locks ↗
• Daemon ↗
• Primary source ↗
• Repository ↗

Reasonix contributors / futureflowtech

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

• Workspace files, command output and MCP or extension-provided tool results
• Stable environment summaries, retained conversation state and checkpoint information

• Inspect and edit project files, execute shell commands and invoke configured MCP or extension tools
• Run interactive or headless coding tasks, enter read-only planning, use planner/executor sessions, and restore per-turn file checkpoints

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.

• Reasonix runtime, clients, context maintenance and execution controls ↗
• DeepSeek Reasonix integration and terminal launch ↗
• Primary source ↗
• Documentation ↗

SWE-agent team

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

• Formatted file/search observations and command results
• Execution errors and prior trajectory entries

• Navigate, search and edit repository files
• Execute commands, run tests and submit changes

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.

• SWE-agent ACI, SWE-ReX and history processing ↗
• Primary source ↗

Warp

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

• Terminal output, files and project context
• Retrieved Warp Drive workflows, notebooks, rules and connected-tool information

• Run commands and edit files
• Execute development tasks using configured workspace tools

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.

• Agent interaction ↗
• Warp Drive context ↗
• Oz multi-harness orchestration ↗
• Primary source ↗

Simular

A desktop operating system and its applications.

• Desktop screenshots and recent action history
• Output from optional host-side code execution

• Click, type, scroll and issue keyboard commands
• Run Python or Bash through the optional code agent

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.

• Agent S3 repository and execution setup ↗
• Agent S3 execution structure ↗
• Agent S3 worker and reflection/context handling ↗
• Primary source ↗

ByteDance

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

• Structured browser-page information and screenshots
• File contents and terminal/tool results

• Navigate pages and interact with DOM elements or GUI targets
• Read and write files and execute terminal commands

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.

• bytedance/UI-TARS-desktop: README.md ↗
• Primary source ↗
• Repository ↗

Browser Use

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

• DOM-derived page/element state and optional screenshots
• Action results, extracted content and errors

• Navigate, click, type, scroll and extract content
• Read or write working files and submit an explicit completion result

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.

• browser-use/browser-use: browser_use/agent/service.py ↗
• Primary source ↗
• Repository ↗

Mobilerun contributors

A connected mobile device and its installed applications.

• Accessibility/UI state supplied by device adapters
• Optional screenshots and action/error results

• Tap, enter text, navigate and perform supported device UI actions

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.

• Mobilerun Manager/Executor and FastAgent architecture ↗
• droidrun/mobilerun: README.md ↗
• Primary source ↗
• Repository ↗

Nanobrowser contributors

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

• DOM-derived page state and optional screenshots
• Navigation/action outcomes and shared task history

• Navigate tabs, click controls, enter text and perform browser interactions

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.

• Executor implementation ↗
• Application setup ↗
• Primary source ↗
• Repository ↗

Skyvern

Chromium sessions, websites and stored workflow artifacts.

• Screenshots and DOM-derived element information
• Browser-action outcomes, extracted data and validation feedback

• Navigate websites, fill forms and interact with page controls
• Extract data, download artifacts and execute configured workflow blocks

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.

• Runtime introduction ↗
• Skyvern-AI/skyvern: README.md ↗
• Primary source ↗
• Repository ↗

Microsoft

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

• Application/window state, UI Automation controls and screenshots
• Results of application operations

• Select or switch applications
• Operate UI controls or available 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.

• microsoft/UFO: README.md ↗
• UFO2 device-agent architecture ↗
• Primary source ↗
• Repository ↗

Microsoft

Connected computers and their device-agent sessions.

• Device-agent results and execution status
• Task dependencies and feedback affecting the remaining workflow

• Assign tasks to connected device agents
• Schedule independent work concurrently and revise future task dependencies

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.

• microsoft/UFO: README.md ↗
• Galaxy runtime documentation ↗
• Primary source ↗
• Repository ↗

ByteDance

A desktop or browser operated through the selected computer operator.

• Screenshots and the previous action/observation trajectory

• Click, type, scroll and issue keyboard input through the 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.

• bytedance/UI-TARS-desktop: docs/sdk.md ↗
• bytedance/UI-TARS-desktop: README.md ↗
• Primary source ↗
• Repository ↗

Nous Research

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

• Tool output, browser content and channel messages
• Retrieved prior sessions, memory files and skill documents

• Run terminal/browser tasks, background commands and scheduled work
• Delegate parallel work, compose tool calls in Python, and write durable memory or skills

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.

• Architecture ↗
• NousResearch/hermes-agent: README.md ↗
• Primary source ↗
• Repository ↗

NEAR AI

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

• Incoming messages and routine triggers
• Retrieved workspace information and tool/job results

• Search and update workspace notes, logs and context
• Run delegated jobs and routines through built-in, MCP or capability-limited WASM tools

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.

• Architecture and security boundaries ↗
• Primary source ↗

HKUDS and contributors

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

• Incoming messages and tool results
• Retrieved session history, workspace memory and completed-job messages

• Respond through connected channels and execute configured tools
• Delegate background work and update workspace memory

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.

• HKUDS/nanobot: nanobot/agent/loop.py ↗
• HKUDS/nanobot: nanobot/agent/memory.py ↗
• Primary source ↗
• Repository ↗

NanoClaw contributors

Messaging channels and per-agent mounted container workspaces.

• Messages routed to the selected session
• Files and tool output accessible within the agent's container

• Read and modify mounted files and run the configured coding agent's tools
• Return replies or scheduled-task output for host-side channel delivery

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.

• nanocoai/nanoclaw: README.md ↗
• nanocoai/nanoclaw: docs/architecture.md ↗
• Primary source ↗
• Repository ↗

OpenClaw contributors

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

• Incoming channel messages, tool results and workspace context
• Follow-up or steering input arriving during execution

• Execute configured tools, scheduled work and channel responses
• Spawn background subagents and coordinate their returned results

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.

• openclaw/openclaw: docs/concepts/agent-loop.md ↗
• OpenClaw subagent sessions and lifecycle ↗
• Primary source ↗
• Repository ↗

RightNow AI

Scheduled web/tool workflows and a persistent agent workspace.

• Retrieved sources, browser state or other tool results required by the active Hand
• Retained session state and scheduled activation inputs

• Research topics and write reports, or monitor and collect information through the selected Hand
• For the Browser Hand, navigate sites and fill forms under its approval policy

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.

• Bundled Hands and runtime components ↗
• Primary source ↗

AgentScope team

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

• Messages, file contents and browser/search results from configured tools
• Recalled conversation turns and extracted Markdown knowledge

• Read, edit and test workspace code or documents; operate configured browser/search tools
• Delegate work, run scheduled tasks and maintain personal knowledge

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.

• Current QwenPaw architecture ↗
• Primary source ↗

Anthropic

The web and connected information sources.

• Search results and retrieved documents
• Worker findings and citation source locations

• Search and read sources
• Delegate research questions and synthesize a cited report

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.

• Research system architecture ↗
• Primary source ↗

ByteDance

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

• Web/tool results, uploaded-file contents and workspace artifacts
• Worker results and durable-batch status

• Search, analyze files and create outputs in a sandbox
• Delegate tasks or submit independently executable batch items

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.

• Current runtime and durable execution ↗
• Primary source ↗

Google

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

• Search results, fetched page content and document inputs
• Code-execution and configured external-tool results

• Search, read and analyze information
• Execute research code and produce cited reports or visualizations

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.

• Deep Research agent runtime guide ↗
• Primary source ↗

GPT Researcher contributors

Search services, retrieved web pages and optional local documents.

• Search results, fetched source text and supplied documents
• Collected research context and cached tool results

• Plan search subqueries and retrieve evidence
• Write a report based on the collected material

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.

• assafelovic/gpt-researcher: README.md ↗
• assafelovic/gpt-researcher: gpt_researcher/skills/researcher.py ↗
• Primary source ↗
• Repository ↗

MiroMind

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

• Search results, document contents and execution output
• Feedback from tool-format failures and delegated agents

• Search and read sources; execute research code
• Call configured subagents and synthesize a final answer

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.

• Agent execution core ↗
• Packaged quickstart ↗
• Primary source ↗
• Repository ↗

LangChain contributors

Search/read tools and configured research data sources.

• Retrieved source text and tool results
• Compressed findings returned by researcher workers

• Clarify a request, search and read evidence
• Delegate research tasks and write a final report

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.

• langchain-ai/open_deep_research: src/open_deep_research/deep_researcher.py ↗
• Primary source ↗
• Repository ↗

Stanford OVAL

Web search and optionally supplied document collections.

• Retrieved source passages and related-topic material
• Simulated expert discussion and, in Co-STORM, human contributions

• Generate and investigate research questions
• Organize findings into an outline, mind map or cited article

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.

• STORM and Co-STORM concrete runners ↗
• Primary source ↗

Samuel Schmidgall and contributors

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

• Retrieved literature and dataset information
• Program output, execution errors and experimental results

• Search literature and prepare experiments
• Write, test and revise analysis code; generate research reports

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.

• Workflow and human feedback ↗
• ML solver implementation ↗
• Primary source ↗

Weco AI

A dataset and execution workspace for candidate ML solutions.

• Dataset previews and candidate source code
• Execution output, exceptions and evaluation metrics

• Generate, execute, debug and improve candidate programs
• Retain and compare scored 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.

• Search and execution implementation ↗
• Standalone reference application ↗
• Primary source ↗
• Repository ↗

Stanford SNAP / Biomni contributors

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

• Retrieved tool/software descriptions and dataset information
• Execution output, errors and analysis results

• Execute Python, R and shell-based analyses
• Call biomedical tools and produce analysis artifacts

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.

• Biomni application ↗
• A1 execution loop ↗
• Primary source ↗

AstroPilot-AI / Denario contributors

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

• Dataset descriptions, analysis output and generated figures
• Intermediate ideas, methods and results supplied or revised by the user

• Develop a research method and execute analysis code
• Generate figures and manuscript 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.

• Runnable scientific workflow and stage controls ↗
• Primary source ↗

Edison Scientific

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

• Retrieved scientific material and dataset contents
• Execution results and artifacts produced by its workers
• Retained hypotheses and experiment records

• Write and execute analysis code
• Delegate investigations and update the scientific working state

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.

• Current Kosmos architecture ↗
• Primary source ↗

Sakana AI

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

• Literature search results and experimental code
• Execution logs, evaluation results and generated analysis artifacts

• Propose and execute experiment variants
• Analyze results and generate a scientific manuscript

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.

• SakanaAI/AI-Scientist-v2: README.md ↗
• Primary source ↗
• Repository ↗

Agent Zero contributors

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

• Browser observations, files and command output
• Subordinate results and user interventions

• Operate the browser and terminal; create or modify files
• Delegate scoped work and consume its result

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.

• agent0ai/agent-zero: README.md ↗
• Agent loop implementation ↗
• Primary source ↗
• Repository ↗

OpenAI

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.

• Web pages, browser state and results from connected applications or site-provided tools
• Files, application content, task progress and outputs produced during the continuing work session

• Research and analyze information; create and revise documents, spreadsheets, presentations, reports and Sites
• Use connected applications and browser tools, perform supported computer actions, and run one-time, scheduled or monitoring tasks

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.

• ChatGPT Work and Codex ↗
• ChatGPT Work cloud-browser execution and continuation ↗
• ChatGPT Work tools, steering, scheduling and desktop execution ↗
• ChatGPT Work release notes ↗
• Primary source ↗
• Documentation ↗

Microsoft Research

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

• Worker observations from the browser, files and terminal
• Worker responses and task-progress assessments

• Browse websites and inspect documents
• Generate and execute code through assigned workers

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.

• microsoft/autogen: python/packages/autogen-agentchat/src/autogen_agentchat/teams/_group_chat/_magentic_one/_magentic_one_orchestrator.py ↗
• Magentic-One packaged five-agent team ↗
• Primary source ↗
• Repository ↗

Manus

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

• Browser content, file contents and command/tool results
• Current task notes and retained execution history

• Browse and retrieve information
• Run commands and create or transform workspace artifacts

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.

• Manus context-engineering architecture ↗
• Primary source ↗

Perplexity

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

• Web results, connected-application responses and workspace artifacts
• Specialist findings, stored preferences and task status

• Research, create applications or documents, and act through connected services
• Run parallel specialist work and recurring tasks in a persistent cloud workspace

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.

• Computer runtime overview ↗
• Scheduled task execution ↗
• Primary source ↗

BAAI Agents contributors

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

• Screenshots and visual changes after executed behaviors

• Perform keyboard/mouse operations
• Invoke atomic and composite environment-specific skills

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.

• BAAI-Agents/Cradle: README.md ↗
• Cradle architecture paper ↗
• Primary source ↗
• Repository ↗

Mindcraft contributors

A live Minecraft server accessed through Mineflayer.

• Visible game state, inventory/world information and chat exposed by the bot
• Action outcomes and game events

• Navigate, gather, craft and interact through bot commands
• Chat and execute generated behaviors through the configured code path

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.

• mindcraft-bots/mindcraft: src/agent/agent.js ↗
• mindcraft-bots/mindcraft: src/agent/action_manager.js ↗
• Primary source ↗
• Repository ↗

finettt and contributors

A live Minecraft server controlled through Mineflayer.

• Game/chat events and structured bot observations
• Rendered game views and tool outcomes

• Perform configured Mineflayer game actions and chat
• Update persistent notes and todos

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.

• OpenPlayer execution architecture ↗
• Primary source ↗

MineDojo research team

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

• Bot/world state and execution feedback
• Critic assessments and retrieved skill implementations

• Generate and execute JavaScript game behaviors
• Choose new exploration tasks and store successful skills

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.

• MineDojo/Voyager: voyager/voyager.py ↗
• Primary source ↗
• Repository ↗

Dimensional

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

• Images and robot-state information exposed by the configured modules
• Robot-skill results

• Request movement to a target or relative position through robot skills
• Carry out exploration tasks using the configured skill set

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.

• dimensionalOS/dimos: README.md ↗
• Blueprint composition and module connections ↗
• Primary source ↗
• Repository ↗

OpenRAL contributors

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

• A rendered situation report from world-state topics, failures and operator prompts
• Perception-tool results and informational perception events; not direct pixel input to the reasoner
• Skill acceptance, completion, failure and timeout feedback

• Query perception, maintain memory and dispatch installed robot skills
• Decompose missions and manage task progression through typed reasoner tools

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.

• OpenRAL/openral: docs/architecture/overview.md ↗
• OpenRAL/openral: docs/reference/reasoner.md ↗
• OpenRAL/openral: cpp/openral_safety_kernel/CMakeLists.txt ↗
• Primary source ↗
• Repository ↗

Robotec.ai

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

• Camera/perception results from object detection and segmentation services
• Robot-control service outcomes

• Locate objects using perception tools
• Request arm movements and gripper operations for manipulation

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.

• Runnable manipulation agent ↗
• Simulation and robot control ↗
• Primary source ↗
• Repository ↗

NASA JPL

A ROS TurtleSim simulation and its middleware interfaces.

• ROS topic/service inspection results
• Feedback returned by turtle-control tools

• Inspect the ROS system
• Execute configured turtle movements and drawing tasks

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.

• nasa-jpl/rosa: README.md ↗
• Runnable TurtleSim demo ↗
• Primary source ↗
• Repository ↗

GreyDGL and contributors

Authorized targets, terminal security tools and saved assessment sessions.

• Target responses and security-tool output
• Findings and evidence retained from earlier assessment stages

• Perform authorized reconnaissance and vulnerability testing
• Execute exploit-validation steps and produce an assessment report

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.

• GreyDGL/PentestGPT: README.md ↗
• Primary source ↗
• Repository ↗

Keygraph

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

• Source-analysis and reconnaissance results
• Responses and evidence from exploitation attempts

• Analyze code and probe the target
• Test candidate vulnerabilities and generate a findings report

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.

• Current scan pipeline ↗
• Primary source ↗

Strix contributors

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

• Target responses, captured traffic and tool output
• Worker messages, lifecycle status and retained session context

• Inspect code and exercise targets through browser, proxy and command tools
• Delegate assessment work and record findings

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.

• Execution and lifecycle implementation ↗
• usestrix/strix: README.md ↗
• Primary source ↗
• Repository ↗

Bolna

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

• Transcribed caller speech and call/silence events
• Results of configured function calls

• Speak synthesized responses
• Invoke configured business functions

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.

• Runnable conversational agent ↗
• Deployed engine timing and interruptions ↗
• Primary source ↗

TEN Framework contributors

A live RTC audio channel and a configured weather service.

• Caller audio handled by the speech-recognition component
• Transcripts, speech-playback events and weather-tool results

• Generate and stream spoken responses
• Invoke the registered weather tool

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.

• TEN-framework/ten-framework: ai_agents/agents/examples/voice-assistant/tenapp/property.json ↗
• TEN voice-assistant controller and interruption handling ↗
• Primary source ↗
• Repository ↗

Vapi

A live call and its connected business APIs.

• Transcribed speech and call events
• Tool responses, interruption signals and silence events

• Speak responses, invoke configured APIs and perform call-control actions
• Hand a call to another configured assistant while transferring selected context

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.

• Assistant session configuration ↗
• Assistant event hooks ↗
• API Request execution semantics ↗
• Vapi multi-assistant call handoffs ↗
• Primary source ↗

Virat Singh and contributors

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

• Financial-data responses, retrieved sources and calculation results
• Tool errors, saved evidence files and delegated research answers

• Query financial information, retrieve sources and execute analyses
• Delegate focused research to parallel read-only workers and write research 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.

• virattt/dexter: src/agent/agent.ts ↗
• virattt/dexter: README.md ↗
• Dexter isolated research worker implementation ↗
• Primary source ↗
• Repository ↗

Tauric Research

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

• Analyst data and reports
• Debate history, prior decisions and subsequent realized outcomes

• Query data and develop investment/risk assessments
• Produce and record a proposed trading decision

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.

• TauricResearch/TradingAgents: tradingagents/graph/trading_graph.py ↗
• Current decision memory and checkpoint changes ↗
• Primary source ↗
• Repository ↗

CAMEL-AI contributors

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

• Content presented through simulated feeds and recommendation policies
• Participant context and results of previous social actions

• Create posts and comments; follow, repost and perform configured social actions

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.

• camel-ai/oasis: README.md ↗
• Primary source ↗
• Repository ↗