SEED
Governed incident remediation for AI agents near production
SEED lets an AI agent take over the first hour of a production incident without taking over production. The agent investigates read-only, proposes one bounded fix, waits for a human to approve exactly that action, applies it, verifies recovery, and leaves a receipt for every step.
Status: Built solo by Hamid Jafari-Zadeh, 2026. Working end-to-end demo in a sandbox environment; private repository. Not yet running against a real production system.
Example: A checkout service goes down
In the demo, a service is broken on purpose: checkout is disabled and the API returns HTTP 503. The operator tells SEED: “The API endpoint is down, can you check and fix it?”
- Investigate, read-only. SEED opens a case and does what an on-call engineer does half awake: it reads the configuration, metrics, health checks, the runbook, and 50 log records. Nothing changes.
- Propose one bounded fix. It finds the cause and proposes a single change: one configuration key.
- Stop at the gate. It cannot apply the change on its own. A human approves it, and the approval is scoped to this case and this action only.
- Apply and verify. After approval, SEED applies the patch, checks that checkout works again, and closes the case.
- Leave the evidence. Every step produces a receipt: 26 for this case, from the first request to the final check.
The Problem: The first hour belongs to a tired human
When a production system fails at 3 a.m., someone is paged. Half awake, they open dashboards, connect to one server and then another, dig through logs, and follow a long recovery document line by line, because one wrong step makes things worse. Most of the time the fix is small. Finding it takes the hour.
An AI agent could do most of that work. The blocker is trust: nobody wants an agent improvising on production, with access nobody can bound and actions nobody can reconstruct afterwards.
The Outcome: Agents that show their work
SEED is designed around one idea: an agent near production does not need blind trust. It needs limits it cannot cross and evidence anyone can check.
- Bounded authority: Investigation is read-only. Changes are limited to explicitly proposed, narrowly scoped actions.
- Human approval where it matters: No mutation happens without an approval tied to one case and one action.
- Complete evidence: Every request, observation, decision, approval, change, and check is recorded as a receipt, so an incident can be reviewed step by step afterwards.
Governance
Separation of reasoning and permission
- What the model suggests and what the system permits are kept apart.
- Scoped approvals: an approval covers one action in one case, never a blanket permission.
- Bounded fixes: the agent proposes the smallest change that resolves the problem.
Evidence
A receipt for every step
- End-to-end trail: from the first request to the final verification.
- Reviewable incidents: the receipts read as a timeline a team can audit or learn from.
- Verification built in: a case closes only after recovery is checked.
Operations
Built from on-call experience
- Mirrors real incident work: config, metrics, health, runbook, logs, in the order an engineer would check them.
- Control center UI: cases, approvals, and receipts in one place.
- Sandbox first: the full loop is proven in a controlled environment before touching real systems.
What a receipt looks like
A simplified example of one receipt from the approval step. Real receipts carry more detail.
{
"case": "checkout-503",
"step": 18,
"type": "approval",
"action": "set one config key in the checkout service",
"scope": "this case, this action only",
"approved_by": "operator",
"next": "apply patch, then verify checkout"
}What comes next: graded autonomy
One of the first engineers who saw the demo put it simply: “I don’t want to wake up in the middle of the night. I want to wake up in the morning and see it fixed.”
The next step is graded autonomy. Pre-approved, bounded classes of action, such as a restart, a rollback to the last known good version, or scaling, can run on their own within set limits. Anything outside those limits still waits at the gate. In the morning, the team gets a report with every receipt.
The thesis stays the same: bounded, auditable, and reversible. What changes is who has to be awake.