An autonomous engineer your team actually owns

Assign a task in plain English. An agent reads the repo, writes a plan, makes the changes, runs the tests, fixes what breaks, reviews its own diff, and opens a pull request for you. That’s the promise of Devin and of Cursor’s background agents — and it’s real, it works, and it’s genuinely useful.

It’s also somebody else’s cloud. Your source code is cloned onto their machines, the work is metered per task, and the agent’s behavior is a black box you configure but don’t control. For a lot of teams that trade is fine. For teams with private codebases, a fixed budget, and opinions about how their code gets written, it isn’t.

So we build the same capability a different way: self-hosted, on your infrastructure, on a Claude subscription you already pay for. This is the complete architecture behind the one we run internally, called Origin — and it’s more buildable than it looks.

The realization: most of it is plumbing you already have

An autonomous engineer sounds like a moonshot. It isn’t — it’s an orchestration layer over parts that already exist and are boring in the best way. Here’s the whole system on one page:

flowchart LR
  U["Team member"] -->|"assign · or label an issue"| O["Origin surface"]
  O --> ORC["Orchestrator"]
  ORC --> BR["Agent SDK executor"]
  BR --> WS["Isolated repo worktree"]
  WS -->|"push branch + PR"| GH["GitHub"]
  ORC -->|"repo test suite"| TST["Tests"]
  ORC -->|"verify the diff"| RV["Auto-review"]
  BR -.->|"plan · tool · diff · test · pr events"| O
  GH -.->|"issue label / PR comment"| ORC

Look at what each box actually is:

• The executor is an agent SDK. The Claude Agent SDK gives you an autonomous loop with real tools — a shell, a file editor, git, web access, MCP servers. Point it at a working directory and it will read, edit, and run commands until the job is done. This is the hard part, and it’s a library.
• The git lifecycle is deterministic. Clone → branch → commit → push → open a PR. That’s a shell script, not an AI problem. You want it deterministic anyway, so a wrong turn from the model can never push to main.
• GitHub is already an API. The gh CLI, authenticated once, opens the PR. Tests run with the repo’s own command. Review runs with whatever reviewer you trust.

The agent supplies the judgment; everything around it — where it runs, what it’s allowed to touch, when a human signs off — is ordinary software you control. When we mapped our own build, roughly 70% was infrastructure we already ran:

Capability	Status	What it is
Autonomous executor (shell · edit · git · web · MCP)	Have	Claude Agent SDK
Clone → branch → commit → push → PR	Have	a shell wrapper
GitHub identity, per user (OAuth)	Have	gh + token
Run the repo’s test suite	Have	the repo’s own command
Claim-verifying PR review	Have	a reviewer agent
Live streaming of the agent’s work	Have	SDK event stream
Kill switch & approval gate	Have	stop flag + gate
Run state machine & event log	New	two DB tables
Isolated workspace + limits + queue	New	worker + worktrees
The plan→build→test→review→PR loop	New	the orchestrator
The surface (board · session · diff)	New	the UI

The new work is a run record, an orchestration loop, and a UI. That’s the whole delta.

The loop that makes it trustworthy

A single agent call that “does the thing” is a demo. A colleague you’d let near a real repo is a state machine with checkpoints:

flowchart LR
  Q([task]) --> P[Plan]
  P -->|"⚑ approve plan"| B[Build]
  B --> T[Test]
  T -->|fail| B
  T -->|pass| R[Review]
  R --> S[Ship]
  S -->|"⚑ approve push"| PR([Pull request])

1. Plan — reads the repo, breaks the goal into a checklist with acceptance criteria.
2. Build — edits files in an isolated worktree with a shell, editor and git — streaming every step.
3. Test — runs the repo’s suite. On failure, feeds the output back and fixes — up to N loops.
4. Review — runs a claim-verifying reviewer over its own diff before it asks you.
5. Ship — pushes the branch, opens an idempotent PR with a summary. It never merges to main.

Two of those stages carry an optional human gate — approve the plan before any code is written, approve before anything is pushed. The default posture is the important design decision:

Origin is a colleague who opens pull requests, not a bot with commit access to main.

Autonomy without handing over the keys.

The build, in six phases

We ship this the way we ship anything — in dependency order, where each stage is independently useful. The first two phases are the MVP (assign a task → it opens a PR); the safety phase is the bar for real team use.

Phase	What it delivers	Effort
P0 Data model & surface	Run record, event log, an empty board wired to real endpoints	≈ 1–2 days
P1 Repo execution	Clone → the agent edits in the repo → push branch → open a PR	≈ 2–3 days
P2 The loop & gates	Plan → test-fix → review, plan/push approval, steering, blocked-needs-input	≈ 3–4 days
P3 Live session UI	Board + plan, streaming activity, diff, tests, PR	≈ 3–5 days
P4 Hardening	Isolation, secrets, guardrails, budget, audit, concurrency	≈ 1–2 weeks
P5 Team integration	Issue-label & PR-comment triggers, per-project config, team skills	≈ 3–5 days

What “production-ready” actually means

The gap between an impressive demo and something a team uses every day is entirely in the boring safety work — and it’s the part worth paying attention to:

Control	What it does
Isolation	Each run gets its own workspace under an unprivileged user, in CPU/memory/time limits
Scoped secrets	The launcher’s git token is injected into that run only — never persisted or logged
Guardrails	Work-branch only, no force-push, no destructive shell, a path allowlist
Secret-leak scan	The diff is scanned for keys before any push; .env never rides along
Hard budget	A per-run token/dollar cap that stops at the ceiling, cost streaming live
Human gates	Plan- and push-approval, configurable per project; PR-only by default
Audit trail	Every shell command, tool call and git op logged immutably

None of that is glamorous. All of it is the difference between a party trick and something you’d point at your revenue-generating codebase.

Why own it

Running it yourself buys three things the hosted products can’t: your code never leaves your machines; the cost is your existing subscription instead of a per-task meter that scales with usage exactly when you want to use it most; and the agent works to your standards — your conventions, your review checklist, your definition of done — because you wrote the harness.

It plugs into the rest of your stack, too. Label an issue and a run spawns itself. A pull-request comment kicks off a fix. The same agents, budgets and knowledge base your team already uses are right there.

An autonomous engineer isn’t a product you have to buy. It’s an orchestration layer over tools you can run — and owning it is very much the point.

---

This is the approach we build for teams: autonomous engineering on your own infrastructure, wired into the tools you already run. If that’s a fit for how your team ships, start a project.