senku.AI transition / owner seat
A business operated with AI

The owner stays accountable.

The owner sets the result, constraints and risk. AI agents run the work, leave evidence and stop when a rule fails. This is the operating model we use on our own work.

Incubating · no customer yet

One owner uses this system on real operations today. No outside company has bought it. There is no published price or client result. The page shows the working precedent and the offer we are building from it.

OWNERoutcome + priorityauthority · limitsphysical facts · judgment AI OPERATIONresearch · build · checkpublish · monitor · repairgate refusesrecord + owner + next action EVIDENCEreleased resultor named refusalwith escalation path
The owner delegates execution. Accountability and irreversible decisions remain with the owner.

What each side supplies

The owner

Names the outcome, ranks priorities, grants access, supplies facts only a person can know, and decides money, commitments and acceptable risk.

The AI operation

Turns the outcome into bounded work, researches, builds, checks, records evidence, publishes allowed results and monitors recurring jobs.

The cost to the owner

Tool and hosting bills, time for the decisions only the owner can make, and final accountability. This precedent has no isolated commercial cost yet, so none is claimed.

The buyer must sit above the organization being changed. A department head cannot sponsor an independent reading of a system when their authority depends on the current answer.

Four gates a stranger can copy

1. Evidence gate

Every factual claim points to the artifact or command that produced it. A missing source refuses publication.

2. Known-bad gate

Break the rule deliberately. The check counts only after it has rejected that broken fixture.

3. Authority gate

Money, commitments, identity and physical facts stop at the owner. Silence never expands authority.

4. Served-result gate

Check what a stranger actually receives after release. A clean source file cannot prove a live page.

The supporting audit specimen shows this discipline on one system we own. Its checker was repaired first, then each refusal was forced against a fixture.

What breaks

Agents can use stale facts, test the wrong bytes, pass a guard that never encountered its failure, lose work between systems, or report a release that never reached a reader. The response is mechanical: stop the affected output, preserve the failed evidence, assign one owner, choose the next safe action, and verify closure through a different route.

Who owns the 2 a.m. failure?

Detection
The monitor or gate records the failed subject and time. It must fail closed if the check itself cannot run.
Assignment
The operating agent owns diagnosis and every reversible repair inside the granted scope.
Escalation
The owner is paged only for a decision, physical action, money, commitment, identity risk or permission the agent does not hold.
Containment
The last verified state remains live. New output waits. A fallback is used only when it is already authorized and observable.
Closure
A separate probe checks the served result. The incident stays in the record, and the recurrence becomes a gate.

The map exercised on a real failure


The operations record confirmed that new pushes across the public projects had stopped creating deployments. The last successful senku release was 12:42 UTC. Existing pages remained live, so the safe state was preserved.


The agent owned diagnosis and monitoring. The owner supplied the one fact outside the agent's reach: the account still had quota. No direct production deployment was used because the operating rule permits releases only through the repository.


A new senku deployment completed. The agent then found that work pushed during the outage had not been replayed automatically.


A fresh repository push triggered the missed release. The served page was checked, and the repair was recorded. The proposed recurrence control changed the noisy scheduled publisher to deploy on change.

Evidence receipt

The dated incident is retained in the Assist operations record under Q[vercel-chat-deploy-stalled]. It records detection at 14:47 UTC, recovery at 16:49 UTC, the successful senku deployment, and the fresh trigger commit. This page omits account and deployment identifiers because they add no reusable value.

What this proves today

It proves one owner can run real research, software, publishing and monitoring through agents while keeping decisions and accountability explicit. It does not prove that another company will buy the model, that it will work unchanged inside a larger organization, or that it reduces headcount. The next honest proof is an outside owner choosing to test one bounded operation.