Product
What was it supposed to do, did it, who said so, and what did we learn?
KeelAI answers those four questions for every change, in objects with owners, versions, and hashes rather than in a chat log or a reviewer's memory.
The factory, with and without KeelAI
Same stations. Different guarantees.
The software factory is model- and harness-agnostic, parallel by construction, and replaces reading code with reviewing proof. KeelAI keeps all three properties and makes each station enforceable.
| Station | Factory practice today | With KeelAI |
|---|---|---|
| Spec | A prompt, or a ticket the agent reads | The spec is an Anchor (for example a Jira issue of type Anchor) with a named owner, acceptance criteria as assertions, and a risk class. The workflow will not start unanchored. |
| Isolate | agents.md asks the agent to open a worktree from main | Behaviors run in a worktree KeelAI creates; the Anchor's declared file scope becomes a boundary a state-diff Guardian enforces. |
| Build | A code-structure skill shapes the code | Unchanged for the builder. KeelAI records which model, prompts, and extensions produced each change. |
| Prove | The agent captures before and after, and judges itself | Deterministic Guardians judge instead: tests pass, coverage held, diff stayed in scope, dependencies and license unchanged, size within bounds. A pass that diverges from the criteria is a DriftEvent, not a green check. |
| Ship | A review agent scores the PR; a human merges at 5 of 5 | Risk routing decides whether a named Authority must approve, asynchronously or before the step continues. The approval and its evidence are sealed in the packet and linked from the PR. |
| Learn | Nothing; the fix is retried | DriftEvents queue to the Anchor owner with five resolutions: change the automation, the Guardian, or the Anchor; accept as the new norm; or reject. |
Guardians
Inspection without a model in the loop.
An LLM grading LLM output rebuilds the problem one level up. KeelAI's launch library is deliberately deterministic, so the same input always produces the same verdict, and a replay months later produces it again.
Every verdict is one of pass, drift, block, or error, and every verdict is itself recorded as evidence.
Schema
Structural validation of every artifact a step produces.
Assertion
Acceptance criteria as machine-checkable CEL expressions.
Policy
Policy-as-code with embedded OPA/Rego, defined by the people who own risk.
State-diff
One question: did only what we meant to change actually change?
Gates
The right person signs, and only when it matters.
Routing rules map an Anchor's risk class and the Guardian outcome to the authority required:
- None. Low risk and passing: the run continues untouched.
- Asynchronous review. The work proceeds; a named reviewer signs off after the fact.
- Synchronous approval. The engine pauses, assembles the evidence, and asks a named person in Slack or GitHub before continuing.
Timeouts and escalation are built in, and every decision is recorded with the approver's identity. Owners and approvers are always people, never team aliases, because one shared account signing everything is itself an audit finding.
Evidence
A batch record your auditor will accept.
Every run produces a sealed evidence packet containing:
- Inputs and the exact Anchor version
- Behaviors and extensions used
- Model calls with prompts and outputs
- Guardian results and Gate decisions with the authorizing identity
- Timing for every step
Packets are canonically serialized and SHA-256 hash-chained per workflow. keel guardian replay reproduces the verdicts and keel verify proves the chain is intact. Chain heads are published to storage you control, so verification never depends on KeelAI.
Architecture
Two planes, one strict contract.
The execution plane runs your factory's work from any harness. The authority plane decides whether it may run, judges what it produced, and records who signed.
A workflow is deployable only when its anchors, behaviors, guardians, gates, required evidence, and risk routing are all populated. There is no side door: work started from the CLI, Slack, a webhook, or the API passes the same Guardian and Gate evaluation.
That is why KeelAI owns its execution engine rather than wrapping another. Pausing for a human decision and refusing unanchored work both require an engine that honors the authority plane. A bolt-on can't guarantee that.
- A single Go binary with durable run state and crash recovery
- SQLite for solo use, PostgreSQL for teams
- Installs on a laptop in one line
- Secrets injected at run time from your existing vaults and redacted from output
Execution plane The engine
Your harness Unchanged
What you see
The authority dashboard.
One screen answers what was built, against which spec, who approved what, and where drift is accumulating.
Anchors & Projects
Every product or codebase is a Project with its own Anchors and owners, sharing one Gate routing policy and evidence store.
Gate inbox
Pending approvals with the evidence already assembled, so approvers decide in seconds instead of reconstructing context.
Drift queue
A per-owner inbox of runs that passed but diverged, with the delta and a suggested resolution.
Runs & workflows
Every run, its Guardian verdicts, and its route through the stations.
Evidence viewer
Open any packet, replay it, and export it to file or OTLP for your SIEM and GRC tools.
Re-verification
When an Anchor changes, every dependent workflow is marked for re-verification and its owner is notified.
Beyond code
The same keel for regulated operations.
The model isn't specific to software. KeelAI's second workflow is cloud configuration-drift remediation on AWS.
In financial services remediation and operational compliance, every run already has an obvious Anchor (the control), an obvious Guardian (the control test), and an obvious Gate (the approver of record). KeelAI makes that structure executable and leaves an evidence trail behind every fix.
- Native S3 and Secrets Manager extensions
- A starter Guardian library for AWS
- Evidence that lands in the tools auditors already read
Roadmap
Built in the open, milestone by milestone.
The MVP exists to prove one claim by using KeelAI to build real software: that agent work can be bound to human-owned intent, verified without a model in the loop, paused for a named person when risk demands, and evidenced in a form a reviewer accepts.
- Milestone 1
Runs a manifest
End-to-end execution with schema Guardians. Refuses an unanchored run. Survives a mid-step kill.
- Milestone 2
Packets replay
All four Guardian tiers evaluate. Packets seal, chain, and replay with identical verdicts; tampering fails verification.
- Milestone 3
Gates in Slack
A high-risk run suspends, a named approver decides from Slack, the run resumes, and drift lands in the owner's queue.
- Milestone 4
Acceptance
Real features of a real project delivered end to end, plus AWS remediation, with the evidence chain published.
See it on your own factory.
We're working with a small group of teams who already run agents and have been asked for an audit trail they can't produce.