§ 00 / INDEX v0.1.0 · open source

The autonomous
engineering team
you control.

Autonomous Engine turns a written request ("fix the basemap error", "add an export button") into a reviewed pull request. It researches your code through a knowledge index called the codex, plans the work, implements it, and has an independent verifier check every acceptance criterion. No pull request exists until verification approves. It runs on your infrastructure, with a local or hosted LLM, and it is free and open source under Apache-2.0.

Get started View on GitHub

Apache-2.0 · self-hosted with Docker Compose · Ollama or hosted LLMs · verification before every PR · multi-repo products

The Autonomous Engine dashboard's pipeline board: work items for a sample product in columns for intake, PRD, PRD approval, research, planning and development, each card showing its type, priority, product and the codex version and modules it was planned against. — Sample data The pipeline board. Each card shows the codex version and modules the item was planned against.

pipeline stages

codex section types

engine services

Apache-2.0 licence

§ 01 / PRINCIPLES

Three rules, not features.
Written into the source.

AI coding tools tend to overpromise. AE is explicit about what it can and can't do. The rules live in PRINCIPLES.md in the repository, and the gates that apply them are in the code, where you can read them.

Transparency

Agent activity streams to your dashboard while it happens: tool calls, file reads, commands. Every stage records its evidence on the work item, so you can see what ran and what it found.

Fail honestly

When the system cannot do something, it stops and says so. A repository with no executable checks blocks by default. "I can't do this" is always a valid answer.

Trust through honesty

No synthetic research, no claimed commits that never happened, no "tests pass" without a test run. Only fully verified work passes the automated gate.

Read the full principles →

§ 02 / PIPELINE

A request in. A verified pull request out.
Everything visible in between.

┌─ intake         ──────────▶  dashboard chat · request portal · Jira · webhook
│
├─ prd            ──────────▶  product agent writes the requirements · human approval gate
│
├─ research       ──────────▶  parallel tasks read the code through the codex + vector index
│
├─ planning       ──────────▶  tasks with acceptance criteria and the checks that prove them
│
├─ implementation ──────────▶  pinned worktree · per-edit syntax check · pre-commit test gate
│
├─ verification   ──────────▶  independent verifier in a scratch clone · no PR until it approves
│
├─ pr gate        ──────────▶  PR opened, or held for a person to release
│
├─ review         ──────────▶  code review of the pull request
│
└─ qa             ──────────▶  checks the change against its acceptance criteria

Every stage is a separate service on a Kafka bus, and every handoff is explicit. If an agent can't do its job, the work item stops and says why. It doesn't invent a result to keep moving.

State machine: Explicit work-item states, recorded transitions
Budgets: Tokens and time, per work item
Retries: Bounded (default 3), then escalate to a person
LLMs: Ollama · vLLM · OpenAI · Anthropic · OpenAI-compatible

Read the architecture →

A work item's independent verification panel: the verdict 'Approved, every criterion met; no critical or major defect', a table of three acceptance criteria marked met with the file and test evidence for each, and one minor defect. — Sample data Independent verification before the PR: a verdict per acceptance criterion, with evidence.

The verification evidence of a work item: outcome verified, a zone-review notice for the payments zone, base and head commit SHAs, the branch, changed files, and five checks (build, unit tests, integration tests, lint, API compatibility) that all passed with their durations. — Sample data The evidence record: exact commits, changed files and every check. A human_review zone sends even verified work to a person.

§ 03 / CODEX

A knowledge index
of your code.
Plus the tools to query it.

When you onboard a repository, the knowledge indexer builds the codex: a structured description of the codebase stored in PostgreSQL, alongside a vector index in Qdrant. Agents query it through tools instead of guessing what your repository "probably" looks like.

When a lookup comes back empty, the engine logs it and counts it in its metrics, so a run without grounding shows up instead of passing quietly.

§ 01 codex

Architecture

System shape, languages and frameworks, data stores, integrations, deployment model.

§ 02 codex

Modules

Purpose, public interface, dependencies and dependents of each module.

§ 03 codex

Patterns

How things are done in this codebase, with reference implementations to copy from.

§ 04 codex

Anti-patterns

What to avoid in this codebase, and why.

§ 05 codex

Testing

How tests are structured, what gets mocked, how the suite runs.

§ 06 codex

Style

Naming, error messages, logging, configuration: what the linter does not enforce.

§ 07 codex

Process

Branch names, commit format, PR conventions, release process.

§ 08 codex

Domain

Business vocabulary, rules enforced in code, constraints.

Kept coherent

The plan follows the code it was made for.

Versioned

Every codex change is a numbered version per product and branch, and each work item records the version and modules it was planned against.

Re-planned

When the modules an item was planned against change while it is in planning or implementation, it is planned again against the new codex. An automatic re-plan never discards verified work and leaves items in verification, review or QA, or with an open PR, alone.

Zoned

Per-repository zones say where agents may work alone, where a person must approve, and where work stops. A frozen zone stops new work outright.

Grounded

No planning or implementation on an empty codex. The item stops with Re-index, Retry or Cancel instead of guessing.

The codex graph of a sample product with two repositories: fourteen modules such as src/cart, src/api-client, api, internal/payments and internal/ledger, coloured by risk level and connected by their dependencies. — Sample data The codex graph: modules of both repositories, coloured by risk, with their dependencies.

The codex zones editor for a repository: a frozen billing-ledger zone with its reason, the default guarded zone (migrations, CI workflows, Dockerfiles, deploy, infra, auth, security) set to human_review, a payments zone set to human_review, and the default restricted zone for secrets set to escalate. — Sample data Codex zones per repository, including a frozen zone and the generic defaults.

Tools, not a prompt dump

Agents ask exactly what the task needs.

Research, planning and implementation agents get codex tools: look up a module and its dependents, fetch the patterns for an area, search for similar code, and use language-server lookups such as go-to-definition and find-references. The codex is linked to commits on the branches you watch.

 // a few of the codex tools agents can call codex_find_module codex_dependents_of codex_patterns_for codex_anti_patterns codex_similar_code codex_grep · codex_read_file codex_goto_definition codex_find_references 

One request.
Every affected repo.

A product in AE is a set of repositories. During onboarding you record how they relate (one consumes another's API, imports a shared library, must deploy first, or reads data another writes), and when the work is done the engine opens one pull request per repository.

// illustrative example
product:  "Payments platform"
│
├─ repo  payments-api        Go · REST API
├─ repo  payments-worker     Go · async jobs · consumes payments-api
└─ repo  payments-web        TypeScript · consumes payments-api

// request: "Add an idempotency key to /v1/charges"
├─ payments-api    → verified · PR
├─ payments-worker → verified · PR
└─ payments-web    → verified · PR

Scenario · 01

Shared library

A change to a shared interface touches the library and the repositories that import it. The product knows how its repositories relate, so the plan covers each one and every repository gets its own pull request.

Scenario · 02

Cross-service feature

A feature spans an API, a worker and a web client. Research reads each repository, the planner produces tasks per repository with the checks that prove them, and each change is verified before its PR is opened.

Verification policy

Each repository has a test command and required checks. With no executable checks, work is blocked by default; a product can opt in to sending such work to human review instead.

Evidence trail

Every change records its base and head commits, the files it touched and each check's result, and the dashboard shows that evidence on the work item.

Change reconciler

Commits made outside the pipeline arrive through webhooks, get classified, and are folded back into the codex. In-flight work picks the change up through a codex re-plan instead of being blocked.

§ 05 / YOUR INFRASTRUCTURE

Run it. On your terms.

The whole stack runs from one docker compose file on a machine you control. There is no licence key and no hosted service. The engine talks to the services you configure: your Git host, your tracker, and your LLM provider. Point it at a local Ollama and your code doesn't leave your network.

What runs where

▸Your infra: engine services, PostgreSQL, Kafka, Qdrant, dashboard, repository clones
▸Your LLM: Ollama (default), vLLM, OpenAI, Anthropic, or any OpenAI-compatible endpoint
▸Optional: Redis, only to run more than one dashboard replica (shared WebSocket fan-out and rate limits)
▸Our infra: none. The engine has no licence check and nothing that reports back to the project.

§ 06 / OPEN SOURCE

Free to use.
Open to change.

Autonomous Engine is licensed under Apache-2.0: use it, modify it, run it commercially. Issues and pull requests are welcome on GitHub. For anything larger than a small fix, open an issue first, sign off your commits (DCO), and include tests.

01 · Source

GitHub

Go services, the React dashboard, migrations, the Helm chart and the benchmark corpus.

View repository →

02 · Contribute

Contributing

Workflow, the rules the codebase relies on, migration rules and how to run the tests.

Read the guide →

03 · License

Apache-2.0

The terms for the software are the LICENSE, NOTICE and third-party notices in the repository.

Read the license →