Inside OpenPond's Source-First Agent Runtime

A model request is not an agent runtime.

Once a workflow can edit files, call tools, delegate to subagents, wait for approval, or run longer than one process, the surrounding system becomes part of the agent. That system needs explicit state, an execution boundary, source that can be reviewed, and evidence that survives the final response.

OpenPond is our attempt to make those pieces ordinary developer-facing primitives instead of hidden product behavior. It is open source, local-first, and designed so the same agent can move from one developer's conversation to a shared team interface without being rewritten.

This post describes the current architecture and the constraints behind it.

OpenPond keeps the conversation, project source, execution state, and review surface in one workspace.

The runtime graph

At a high level, OpenPond separates the interface that starts work from the executor that performs it:

The model is deliberately behind a routing boundary. A run can use Codex, a provider key, a hosted model, an open model, or supported subscription-backed access without changing the agent package. Model choice matters, but it is not allowed to become the storage format for the workflow.

The same rule applies to execution. Local source and a hosted sandbox are two executors for the same work, not two unrelated products.

Agents are packages, not saved prompts

OpenPond agents live in a git-backed profile repository. A package can contain instructions, TypeScript, actions, workflows, setup requirements, and evals:

This structure creates a useful boundary:

• the conversation can propose or edit behavior;
• the package is the durable implementation;
• git records what changed;
• generated manifests describe what the runtime may load;
• evals remain beside the code they constrain.

An agent can still begin as a chat. The important part is that useful behavior does not have to remain trapped in the transcript.

Long-running work needs a state machine

Agent execution is not well represented by loading: boolean.

OpenPond models work as items with an identity, status, owner, sandbox context, budget, artifacts, and completion evidence. Goal loops can continue across turns while preserving why the run exists and what would count as completion. Create, edit, and improve workflows operate against source and leave a reviewable result.

That state is also what makes handoff possible. A person or another agent should be able to resume a run from the source, logs, artifacts, and goal—not reconstruct it from a half-finished chat response.

Local control and sandbox execution are separate concerns

The desktop app can own the conversation, model settings, approvals, local files, and source review while execution happens somewhere else.

A hosted sandbox provides an isolated filesystem and process boundary for shell commands, dependency installation, browser work, snapshots, schedules, and long-running jobs. The local workspace remains the place where the developer reviews the result. Moving execution to the cloud does not require moving the agent definition into an opaque database object.

This split is why OpenPond can support both a local-first workflow and a hosted team workflow:

OpenPond Cloud currently provides the hosted control and sandbox path. Customer-owned AWS sandbox data planes are an Enterprise direction; we are not describing that as full self-hosting today.

Multiplayer is an identity and policy problem

Putting several users in the same chat is the easy part. A shared agent system also needs to answer:

• Which Team owns the agent and its projects?
• Which member started this run?
• Which credentials and integrations may the executor lease?
• Whose limit applies, and which shared usage pool funds the work?
• What remains accessible after a member leaves?

OpenPond Teams attach Team Chat, agents, projects, sandboxes, and usage to one Team account. Execution remains attributable to a member, while owners can apply member limits and review usage. Members do not share a Personal login or fund the Team through separate Personal subscriptions.

This lets a developer publish one source-backed agent and expose it through Team Chat, OpenPond Web, Slack, Microsoft Teams, or another machine. The teammate uses the agent; they do not need the original developer's clone, environment, or provider session.

Training starts with task authoring

Chat logs are useful evidence, but they are usually poor training data. They contain exploratory turns, dead ends, private context, and outcomes that cannot be graded.

OpenPond's training workbench starts with explicit selection. A developer chooses consented conversations or traces and uses them to author a Taskset. The materialized Taskset includes typed tasks, validation and frozen-evaluation splits, source references, environment requirements, graders, and a content hash.

The pipeline is intentionally reviewable:

1. Select conversations that demonstrate a repeated capability.
2. Transform them into explicit task inputs and expected outcomes.
3. Add deterministic verifiers or calibrated model judges.
4. Run a baseline and inspect attempt-level grading evidence.
5. Produce a readiness report and exportable training bundle.

The open-source build can validate Tasksets, run local baselines, audit graders, and prepare portable bundles. Managed training providers are integration points, not a claim that every chat automatically launches an RL job.

That distinction matters. The useful product loop is not “collect chat history and train.” It is:

Why open source is an architectural requirement

The harness contains operating policy: prompts, tool access, model routing, approval rules, agent source, environment contracts, graders, and training provenance. Those pieces should be inspectable when they determine what an agent can do.

The main repository contains the Desktop app, CLI, TUI, local server, runtime packages, and training workbench. The Agent SDK and TypeScript client are public as well. Agents and Tasksets remain portable source rather than exports reconstructed from private platform state.

Run it locally

OpenPond requires Bun and a supported Node.js release. Clone the repository, then run:

No OpenPond account is required for local work. Bring the model path and credentials you want to use. When the workflow needs clean compute or a team interface, the same source can move to OpenPond Cloud.

The code and current architecture live at github.com/openpond/openpond.