Skip to content

README.md

Latest commit

 

History

History
119 lines (92 loc) · 3.71 KB

README.md

File metadata and controls

119 lines (92 loc) · 3.71 KB
Raw

Open Work Agent

Open Work Agent

Open Work Agent is an application template and harness for building domain-specific AI teammates.

It gives you the solid scaffolding most work agents need: orchestration, LLM calls, evals, knowledge management, skills, sandboxing, a web UI, approvals, saved runs, and deployment wiring.

Instead of rebuilding the same boilerplate, you focus on the knowledge, operations, and approval rules that matter in your domain. Then you deploy the agent where your team already works (Slack, Linear for starters).

Note

This is a work in progress. The full agent scope hasn't yet been completed. Broad roadmap can be found in docs/ROADMAP.md while the progress is tracked via GitHub issues.

The product direction lives in docs/MANIFEST.md, the architecture notes live in docs/ARCHITECTURE.md, and TODO.md tracks the implementation path.

Package Shape

The repo is split so the deployable app stays minimal:

  • packages/harness owns the agent runtime contract: agent config, trigger decisions, context and prompt assembly, run lifecycle, capability and approval contracts, and saved-run types. It should not know about Next.js, Fetch routes, filesystem layout, or process.env.
  • packages/runtime-node owns Node server bindings for the harness. It turns a workspace root, environment, and app-provided services into a harness-compatible runtime. Sandbox execution follows the same rule as other external SDKs: the harness owns Open Work Agent types, while runtime-node keeps the Vercel SDK contained.
  • apps/web is the Next.js integration shell. It owns pages, API routes, webhooks, cron entry points, database schema, app persistence implementations, and deployment shape. It should mostly select the active agent, choose runtime bindings, and adapt HTTP or webhook input into calls to the harness.

In code, the app should compose the packages rather than reimplement their plumbing:

createWorkAgent({
  agent: defaultAgent,
  runtime: nodeRuntime({
    workspaceRoot,
    environment,
    runRepository: createAppRunRepository({ db }),
    sandboxRuntime: createVercelSandboxRuntime({ env: environment }),
  }),
});

Run It Locally

Use pnpm:

pnpm install
pnpm db:up
cp .env.example .env.local
pnpm dev

pnpm db:up starts the local Postgres service used by the app on 127.0.0.1:55432, away from the default Postgres port. The DATABASE_URL in .env.example points at that service. Set the required AI_GATEWAY_API_KEY in .env.local, then link a Vercel project and pull sandbox credentials:

vercel link
vercel env pull

Vercel Sandbox does not run through a local emulator in this MVP; accepted local work runs create non-persistent cloud sandboxes. After the environment is ready, open http://localhost:3000.

Saved local work runs are available at http://localhost:3000/runs. The app requires DATABASE_URL; accepted work runs also require Vercel Sandbox credentials. Missing required configuration fails clearly instead of silently switching modes.

To stage a real local run from the command line:

pnpm smoke:run

Pass a custom request by appending it after the script name:

pnpm smoke:run "Draft an investigation plan for a failed invoice sync."

Stop local Postgres with:

pnpm db:down

If you need to wipe the local database volume, run docker compose down -v.

Before handing work over, run:

pnpm check