AGPL-3.0 · self-hosted · public release soon
The governed-execution layer for AI agent fleets.
Any model, any harness, one governed door. AiOverload runs agents as deterministic, event-sourced workflows on your infrastructure — behind an agentgateway with just-in-time credentials and deny-by-default boundaries, scored step by step by a small reflex gate, with every decision replayable from the event log.
New, small, and auditable. One maintainer, no traction claims, no “enterprise-grade” adjectives — judge it by the code and by the log.
$ aioctl run registry/workflows/dev-review-loop.yaml
run.started 9c4e71a8f2b64d1e8a5c3f7b2d1904e dev-review-loop 8 steps
step.held review_2
risk=0.81 reason=review-approves-a-push-the-gate-cannot-vouch-for
$ aioctl approve 9c4e71a8f2b64d1e8a5c3f7b2d1904e review_2 --input "review ok — do not push"
run.running review_2 re-dispatched with operator input on the log
step.completed report verdict: PASS (machine-readable, on the log)
run.completed 8/8 steps · 1 human approval recorded · 0 silent fallbackstool.decide
Every tool call gets the same treatment.
The terminal above shows a step held at dispatch. The gate also sits on the tool path: every tool call, external or internal, is judged before it happens — and the decision lands on the same log.
tool.decided server=github tool=create_pull_request
action=hold risk=0.62
reason=unattributed-write-to-protected-branchEvery tool call gets the same treatment: scored, logged, replayable. Deny is a refusal at the wire — the call never happens; it is not a warning after it.
The gate learns. Every decision is paired with the observed outcome —
an allow is later marked confirmed or negated, a hold justified or
a false_positive — and the labels are the fine-tuning data. Static
allowlists judge tools; the reflex gate judges intent. The loop is
built and allow/hold precision is measured per tool; the data
accumulates from release, and the published calibration stays
re-measurable on your own decision log.
The short version
Four ideas, no magic.
The event log is the runtime
A gate, not a chatbot
Boundaries are rendered, not promised
Agents are addressable peers
Risky steps park for humans
Operator console
Built. Shipping with the release.
Reading the log alone, you would think AiOverload is CLI-only. It is not: the operator console is built. An approvals queue that parks steps and tool calls, approve/reject with your reason on the log, run detail with the gate-decisions panel, a gate-quality page measuring allow/hold precision per tool, and fleet and project views over the directory read model.
| run | what is parked | risk | |
|---|---|---|---|
9c4e71a8 |
step review_2 |
hold · 0.81 | approve · reject |
f207bbc1 |
tool github/create_pull_request |
hold · 0.62 | approve · reject |
reason=unattributed-write-to-protected-branch
Your words land on the log with the decision —
aioctl replay re-verifies the whole run later.
Operator console: built, shipping with the release. The preview above is a static mock of the real screens — no live data, no embellishment; screenshots publish with the source.
In the open
Designed in public, not marketed.
The roadmap isn’t slideware: architecture decisions land as published ADRs before the code. The latest — a resident agent runtime (an always-on manager that watches drift and proposes tasks, plus a console assistant — initiative is resident, execution stays governed) — was decided in the open, with rejected alternatives on the record. It’s the first item on the roadmap.
Meanwhile the engine is measured, not asserted: 74 Go packages, 166 reflex tests, and a hermetic CI ladder — build, vet, contract schemas, dead-code, secrets, and smoke against a live NATS stack — on every single PR.
Honest by design
What we do not claim.
One battle-tested harness — so far
The gate is not the sandbox
Not for every job
Built mainly with AI — disclosed
Why not X?
The honest map.
No single tool does all four of these: judge intent, execute governed, hold a human door on an event log, replay every decision. The neighbors, honestly:
| What it does | What it does not | |
|---|---|---|
| Sandboxes · micro-VMs (E2B, Firecracker) | isolate execution | judge intent |
| Workflow engines (Temporal) | replayable orchestration | write your guardrails for you |
| LLM gateways · proxies | filter the network | hold a human door on an event log |
| Frameworks (LangGraph, CrewAI) | orchestrate agents | govern beyond configuration |
None of them is bad at its job. AiOverload exists because the four jobs meet at one door — and someone has to keep the log.
Keep reading
The overview is the trailer. The pages are the film.
How it works
The event-sourced pipeline, the reflex gate, just-in-time credentials, the sidecar boundary — every claim drawn, every step on the log.
Platform
Agent manifests and personas, A2A-native agents, the governed task plane, GitOps fleet directory, knowledge plane, forge integration.
Vision
Agents are about to hold the keys — who governs them? The case for a governed-execution layer, stated as principles, not marketing.
About
One senior platform engineer from Normandy, building in the open with AI pair-programmers and a hermetic CI ladder. No team, no pitch deck.
Public release soon.
Self-hosted, AGPL-3.0 — and developed in the open from the first public commit. Source and docs publish with the release. Leave your address: one email at release. That’s it.