Overview
A multi-harness agent platform. An event-sourced control plane drives replaceable coding engines in isolated sandboxes and renders every run from one canonical event log.
UseAgent is a control plane for coding agents. It turns a prompt into a durable, replayable run: a coding engine works inside an isolated Linux sandbox, streams what it does as an ordered event log, and the product UI renders that log live and on reload. The same run can arrive from the web app, from Slack, or from a scheduled automation, and it flows through one durable command lane.
New here and wondering why any of that matters? Explore the features: seven deep dives into the agent contract, the trust lane, the reliability story, the engines, the workspace, self-improvement, and the product experience, every claim grounded in the shipped code.
The core idea
UseAgent is built on three architectural commitments: verification is an evidence discipline, all state is event-sourced in Postgres, and engines are replaceable adapters behind one canonical contract.
Harness outside the sandbox
The backend is the harness. The run and step event log in Postgres is the source of truth. The UI renders the log, never a live process.
Engines are rented, not built
The inner agent loop is Codex, Claude, or OpenCode behind a neutral adapter. UseAgent owns orchestration, history, approvals, and rendering.
One canonical event contract
Every engine’s output is translated into provider-neutral canonical events, so three different engines render through a single UI grammar.
Because history lives in the event log rather than in a running process, a run survives a backend restart, reconnects with a fresh durable snapshot, and never loses work that actually completed.
Start here
Features
Why UseAgent: the contract, trust lane, reliability story, engines, workspace, and self-improvement, each as a deep dive.
Getting started
Install the apps, run the two dev servers, and learn the repository layout.
Concepts
Runs and threads, engines and adapters, sandboxes, the gateway, and the self-improvement lane, each in one page.
Architecture
The architecture end to end: how a turn flows, how realtime works, and what the shared packages contract.
Operations
Deployment lanes, the verification arsenal, and the operational invariants production depends on.
Product
Every product surface: the session view, task composer, skills and playbooks, knowledge and wiki, memory hub, dashboard, and settings.
Platform
Auth and orgs, provider connections and models, the GitHub integration, and fleet usage.
Channels
Slack as a first-class entry point into the same durable command lane.
API
The HTTP surface: runs and realtime, artifacts, knowledge, memory, skills, automations, and platform.