Liveplatform
Keel
Autonomous coding that lands as pull requests, never as merges.
A single-operator autonomous-coding and gated-deploy system. A Temporal orchestrator drains a cross-repo plan graph and runs each phase with a coding agent in an ephemeral worker. The work lands as a pull request, and infrastructure changes pass a human-approved airlock.
- Never auto-merge
- PR-only output
- IAM-enforced airlock
- Temporal orchestrated
- Agentic orchestration
- Cloud infrastructure
- Architecture & developer experience
- Data science & evaluation
- test files in the orchestrator
- 577
- test files across the Keel apps
- 314
- Terraform files
- 89
- of 35 use cases demoable today
- 16
The problem
Autonomous coding agents are easy to demo and hard to trust. The gap is the discipline around the model, not the model’s capability. That discipline means dependency ordering across repositories, an ephemeral execution boundary and a review gate that cannot be skipped. It also means an infrastructure path where the agent structurally cannot apply its own changes.
The approach
Keel never auto-merges: the agent’s output is a pull request. IAM enforces the deploy airlock, not convention. The executor role cannot apply, so the control is structural instead of procedural. Status mirrors to the issue tracker as writer-of-record, so the plan and the work cannot drift apart.
How Keel fits together
Plan files
A cross-repo dependency graph
Orchestrator
Temporal drains the graph
Worker
One ephemeral Fargate task per phase
Coding agent
A pluggable harness
Pull request (a person decides)
Never auto-merged
Deploy airlock (a person decides)
Approved in the Keel app with a push notification and biometric step-up; the executor role cannot apply
What Keel does
Never auto-merge
Every change lands as a pull request; a person merges it, always.
An airlock enforced by IAM
The executor role cannot apply infrastructure changes. The control is structural, so no convention can skip it.
A plan graph drains across repos
A Temporal workflow walks a cross-repo dependency graph, authored as plan and phase files.
Status mirrors to the tracker
The issue tracker stays writer-of-record for status, so the plan and the work cannot drift apart.
What’s inside Keel
- A Temporal workflow draining a cross-repo dependency graph authored as plan and phase files
- An ephemeral Fargate worker per phase, cloning the target repository
- A pluggable coding-agent arm, so the model harness is a choice rather than a dependency
- Pull request as the only output path, with no auto-merge
- An in-app deploy airlock for infrastructure: a push notification, a biometric step-up, and IAM-enforced no-apply on the executor role
- The issue tracker as writer-of-record for status
- A backend API with its own Terraform module
- An operator console in Next.js that ships as a native iOS app from the same codebase
- Benchmarking and measurement: A/B runs, gates, scorers, drain pass-rate and lag
Where Keel stands today
- 577 test files in the orchestrator, plus 314 more across the Keel apps
- Sixteen of thirty-five use cases are demoable today, by the project’s own internal audit. That audited count is the number we publish, rather than the roadmap
The Keel tech stack
- Python
- self-hosted Temporal
- ECS Fargate
- Amazon RDS PostgreSQL
- AWS Bedrock
- 89 Terraform files
- Playwright end-to-end
- Next.js
- TypeScript
- CSS Modules
- design tokens
- Supabase Auth
- Capacitor
- Swift
See Keel working
Want to see gated autonomous coding against your own repositories? Ask for a walkthrough.