useAgent puts Claude Code, Codex, OpenCode and Pi behind one event contract

Every channel enters through the same run door

The integration table is the design document. There are four ways in, and the row underneath them is the point: the web app, Slack, the REST API and schedules all enter through the same run door.

That is a smaller claim than it sounds and a more useful one. A task scheduled for 3am and a task typed into Slack go through identical orchestration, identical event recording and identical approval handling, because there is one door rather than four entry points that have to be kept in agreement.

Above that, native integrations are Slack itself, with mentions, threads and delivery, and GitHub, with app authentication, clones and pull requests. Then the connector tier: Gmail, Linear, Notion and HubSpot, where OAuth is handled by the broker and tokens are sealed server-side. The workspace surfaces sit alongside as knowledge base, team memory, skills and playbooks, and scheduled automations.

Sealing OAuth tokens on the server side is the part worth noting for anyone putting company mail into it. A connector's credential does not travel to the agent or to the sandbox; the broker holds it and the agent asks through the gateway.

Inside the workspace there are also artifacts: documents, spreadsheets, presentations, PDFs, images and videos, with revisioned edits and native exports for the supported types. That is what turns a run into a deliverable rather than a transcript.

Gated tools pause and resume with a one-shot capability

Approval controls are described in one sentence, and it is the most interesting sentence in the project: gated tools pause for a decision and resume with a one-shot, argument-bound capability.

Read that as a capability system rather than a confirmation dialog. When an agent reaches a gated tool, the run suspends, a human decides, and the run continues holding a token that is valid once and only for the arguments it was approved with. The agent cannot reuse that approval for a different call, and it cannot re-request the same approval silently.

That is the difference between a prompt that says are you sure and a mechanism that binds a decision to one invocation. It is also why the Slack surface can carry a decision: a gated run paused in a sandbox is still a run with an event timeline, so the approval happens in the thread where the request was made.

Recurring work sits on the same foundation. Tasks can be scheduled, their history inspected, or one run immediately on demand, so an approval-gated automation has somewhere to show what it did and what it was waiting for.

The cost of the design is latency you cannot avoid: a gated task is not a background job, it is a run that can sit idle until somebody looks at it.

Skills are versioned so a run records what it used

The team-procedure feature is skills, and the design decision is versioning.

Skills can be imported from GitHub, a playbook can be pinned to a task, and procedures that work get reused. The line that matters is that skills are versioned, so a run records exactly what it used.

That single property turns an agent workspace from a demo into something you can audit. When a task produced a specific result three months ago, the question is whether the procedure has since been edited. With versioned skills the answer is in the run record rather than in your memory, and a playbook pinned to a task is pinned for that task rather than for whatever the file says today.

The adjacent feature is memory, and it is deliberately split. Knowledge, wiki pages and optional team memory sit beside the work, recalled facts can be inspected and corrected, and personal memory is kept separate from organisation memory. That separation is what stops one person's notes from becoming the team's institutional knowledge without anyone deciding it should.

Together these are the parts of useAgent that are not just an agent in a box. An agent with a terminal is a commodity. An agent with versioned procedures, correctable memory and a recorded timeline is infrastructure, and it is where the engineering effort in this repository appears to be concentrated.

Durable sessions are a Postgres timeline, and it wants pgvector

Durability has one implementation and one dependency: Postgres stores the event timeline, and recovery re-probes live sessions after a restart.

Storing events rather than snapshots means the run can be reconstructed, and re-probing live sessions is the pragmatic half, since a sandbox that was running before the restart may or may not still be. Anything the timeline cannot reattach is surfaced rather than silently dropped.

The dependency is the part that bites on a first setup. Postgres 16 or newer with the pgvector extension is required, and the README notes that stock Postgres images do not include it. The one-container example makes that explicit:

docker run -d --name useagent-pg -p 127.0.0.1:5432:5432 \
  -e POSTGRES_HOST_AUTH_METHOD=trust pgvector/pgvector:pg16
export DATABASE_URL=postgres://postgres@localhost:5432/postgres

That command trusts authentication and binds to loopback only, which is right for local development and would be wrong on a shared host. The README says so as well, calling the database example a local development convenience and pointing at the setup guide for provider credentials and sandbox configuration before you run a real agent task.

pgvector is not incidental either. Search over knowledge, wiki pages and team memory is vector retrieval, and putting the event timeline and the memory index in the same database is the simplest thing that works.

Four engines, one session UI, and interchangeable sandboxes

The supported engines are Claude Code, Codex, OpenCode and Pi, and the claim is one session UI and one event contract across all of them.

That claim is hedged in the same paragraph, which is fair. You connect a provider account or an API key, and the available models, login methods and tools depend on the adapter and on your self-hosted configuration. In other words, the uniformity is in the interface and the timeline, not in the capabilities, and the README does not pretend otherwise.

The runtime side is where the isolation happens. Each thread gets a computer: a real browser, a terminal, your repositories, and a desktop or terminal view you can open and take control of when the agent is doing something you want to watch or interrupt. Daytona and CubeSandbox provide the isolated Linux workstations, with screen recording on both.

Swapping providers is a workspace concern rather than an architectural one. The typecheck script in the repository root runs a separate compiler pass over packages/sandbox-daytona, packages/sandbox-cube and packages/sandbox-box, which is the clearest evidence that more than one sandbox backend is real rather than aspirational.

Running on your own subscription rather than a metered API is the commercial observation here. The agents are the ones you already pay for, so the cost of this project is infrastructure, not inference.

Eleven compiler passes, three Dockerfiles, and a dual licence

The repository root is a TypeScript monorepo that resolves with bun, and the scripts are few enough to read in one sitting.

git clone https://github.com/useagenthq/useagent.git
cd useagent

Dependencies are installed per workspace rather than once at the root, because the install loop covers packages and the two applications separately:

for workspace in \
  packages/agent-harness packages/artifact-workspace \
  packages/agent-client packages/artifact-formats packages/sandbox-contract \
  packages/conformance packages/cli \
  backend frontend; do
  (cd "$workspace" && bun install --frozen-lockfile)
done

bun run dev:backend    # API + orchestration on :3201
bun run dev:frontend   # UI on :3400 (proxies /api/* to the backend)

Two ports, a proxied API path, and frozen lockfiles per workspace. The one script worth noting is typecheck, which is not a single project-references build but a chain of separate compiler invocations across the frontend, the backend, the sandbox contract, the three sandbox providers, the artifact packages, the agent harness and client, conformance and the CLI. It is slow, and it is also the check that stops a contract change in one package from landing in another.

Deployment has three Dockerfiles, one each for the backend, the frontend and the gateway, plus compose.local.yaml and compose.prod.yaml, a .kamal/ directory for Kamal deploys, and an infra/self-host/ directory containing a Terraform reference host and a provider-agnostic deploy-app.sh. Self-hosting is documented for any Linux host, including AWS, Google Cloud, Azure and bare metal.

The licensing is worth reading twice. The package manifest says AGPL-3.0-only, and the root holds both COMMERCIAL-LICENSE.md and TRADEMARKS.md next to the LICENSE and NOTICE files.

Alpha, and one release tagged with a commit hash

The stability notice is at the top of the README and it is unusually direct: alpha software, under active development, expect rough edges, and APIs and schemas may change between releases. It adds that the project already runs real daily workloads, but advises pinning a tag if you need stability.

The release list is the evidence for taking that seriously. There are two recent tags, and one of them is not a version number at all: native-runtime-90dc3ebbb74b, named Native runtime 90dc3ebb, published 2026-09-12. The other is v0.0.3, published 2026-08-31.

A raw commit hash as a release tag tells you something about how the sandbox runtime ships, and a version of 0.0.3 tells you where the project is in its own reckoning. Neither is a criticism on its own; combined with the alpha notice they mean you should treat the tag you deploy as the contract, not the main branch.

The last push on the repository was on 2026-09-15 and it is not archived.

Two other signals worth noting. The demo is described as real product footage with a caveat that the recorded interface may differ from your release, and the feature table carries hidden comments about demo clips and edited footage, which is a reasonable thing to disclose about marketing material.

Against running one agent CLI yourself

The alternative is the thing useAgent is built on top of. Install Claude Code or Codex, point it at your repository, and run it in a terminal. You get the same engine, on the same subscription, with none of the orchestration.

What you do not get is the part that requires a server: isolated sandboxes per thread with a desktop you can take over, versioned skills pinned to a task, correctable memory split between personal and organisation scope, artifact files with revisioned edits and native exports, Slack delivery, scheduled runs with inspectable history, gated tools that resume with argument-bound one-shot capabilities, and a Postgres event timeline that survives a restart.

None of that is hard to fake for one person and one task. All of it is hard to fake for a team, which is the stated audience.

The cost of the other side is the cost of the other side: you run Postgres 16 with pgvector, two long-running services, at least one sandbox provider, and an AGPL-licensed codebase whose schemas are declared unstable, on infrastructure you pay for. Self-hosting is documented for any Linux host, so the hosting is not the problem; the operational surface is.

The honest summary is that this buys you a supervision layer over agents rather than better agents. If your work is one agent and one terminal, it is more than you need. If your work is several agents, several people approving their actions, and results that have to be traceable weeks later, that layer is the product.

Editorial conclusion

useAgent suits a team already paying for Claude Code or Codex who wants agents running unattended in sandboxes with an audit trail and a human approval step, and who is prepared to run Postgres with pgvector themselves. It does not suit anyone who needs a stable API today, because the project says so itself: alpha, schemas may change, and one release tag is a commit hash. Verify two things before building on it: that the licence arrangement works for you, since the repository is AGPL-3.0-only with a separate COMMERCIAL-LICENSE.md and a TRADEMARKS.md beside it, and that your Postgres has pgvector, which stock images do not ship. The OSS release is v0.0.3 and the last push on the repository was on 2026-09-15.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. useagenthq/useagent on GitHub