KeelAn event-ledger core with a Harness on top

What Keel is ​

Keel is a general-purpose, stateless, multi-tenant agent runtime. It exists to answer one engineering question: what should execution, storage, streaming and backpressure look like when you run a thousand long-lived sessions — each possibly carrying images, tool calls and long contexts — without letting process memory grow with the session count and without losing sessions across restarts.

The repository ships both main lines:

Keel is a Go re-implementation of PI: interfaces, event semantics and ecosystem artifacts (SKILL.md, MCP, compaction, telemetry) follow PI as the single reference; only the runtime is replaced (PostgreSQL, SSE, multi-tenancy, a 2GB budget). The runtime loop itself is assembled from the minimal necessary code moved from pigo (MIT), with the original copyright headers kept.

30-second quickstart ​

The commands below were run against the repository at the revision this site documents; the response shapes shown are the actual ones.

# 1. a PostgreSQL 18 instance for the ledger
docker run -d --name keel-pg \
  -e POSTGRES_PASSWORD=runtime -e POSTGRES_DB=runtime \
  -p 13741:5432 postgres:18

# 2. build and start the Harness (product shell + API + worker)
git clone https://github.com/jixoai/keel.git && cd keel
go build -o keel ./cmd/keel
export KEEL_DSN='postgres://postgres:runtime@127.0.0.1:13741/runtime?sslmode=disable'
./keel serve --addr 127.0.0.1:13750 \
  --tenant 11111111-2222-3333-4444-555555555555 \
  --password devpass

# 3. talk to it (second terminal; the passphrase is the bearer token)
T=http://127.0.0.1:13750
TENANT=11111111-2222-3333-4444-555555555555
SID=$(curl -s -X POST -H "Authorization: Bearer devpass" -H "X-Tenant-ID: $TENANT" \
  -H 'Content-Type: application/json' -d '{}' $T/v1/sessions | cut -d'"' -f4)

curl -s -X POST -H "Authorization: Bearer devpass" -H "X-Tenant-ID: $TENANT" \
  -H 'Content-Type: application/json' -d '{"text":"hello keel"}' \
  $T/v1/sessions/$SID/input
# {"created":true,"requestId":"…","seq":1,"status":"committed","submissionId":"…"}

curl -s -H "Authorization: Bearer devpass" -H "X-Tenant-ID: $TENANT" \
  "$T/v1/sessions/$SID/events" | head -c 400
# {"events":[{"seq":1,"kind":"user.message",…},{"seq":2,"kind":"assistant.message",…},
#            {"seq":3,"kind":"run.finished","payload":{"status":"done",…}}]}

With no model configured, the runtime uses its deterministic fake provider, so the reply is canned and the whole path — edge commit, claim, loop, commit, projection — still runs. Point KEEL_MODEL (plus KEEL_BASE_URL/KEEL_API_KEY) at a real provider when you want real answers. The complete runbook, including tests, load tests and the 2GB cgroup replay, is in docs/RUNBOOK.md.

Where to go next ​

• Core — what Keel is, then architecture, events and protocol, AgentAPI, storage and runtime, and the extension map.
• Harness — what the Harness is and its plugin standard, starting at plugins.
• Glossary — one place for the vocabulary both lines share: glossary.

Repository and license ​

• Source: https://github.com/jixoai/keel (Go module github.com/jixoai/keel, Go 1.27.3 per go.mod:3)
• License: Apache-2.0 (LICENSE); files moved from pigo keep their MIT copyright notice (third_party/pigo-LICENSE, attribution in NOTICE).
• Maturity: every capability is graded G0–G5 in docs/MATURITY.md; GA means all capabilities reach G5.