faq

Questions, answered

The ten questions everyone asks about self-maintaining software.

What is an autopoet?

A self-maintaining runtime actor: a single supervised worker that senses a live software system, proposes edits to the system's own agents and configuration, validates every change in an isolated scratch copy, and merges autonomously only within a capability ceiling it structurally cannot escape. The name comes from autopoiesis — Maturana and Varela's term for a system that continuously produces and maintains itself.

Can it escalate its own permissions?

No — and not because a rule forbids it. Ceilings live in ancestor index files above the autopoet's write scope, and effective capability is the intersection of every ancestor ceiling: capability only flows down. Widening a ceiling means editing a file the autopoet cannot reach. Self-escalation is impossible by construction, not by policy.

What can it change without asking?

Within ceiling, on managed agents: prompts, tools, wiring, schedules, logic. Never the structural triad — grant, ceiling, management — and never anything frozen, including itself.

How does it handle prompt injection?

Requests are typed. Decisions key on the structured change delta and verifiable telemetry evidence — never on free prose. Injected text rides in the why field, which is untrusted context for a human reviewer, not an instruction. And even a fully compromised request cannot cross the triad; that path always ends at a human.

What does it cost to run?

Model spend flows through a hard admission budget you set. The surprise gate keeps routine operation at reflex pricing — quality 1.000 at 1.3% of always-calling-the-model — so the marginal cost of self-maintenance trends toward zero as the system learns your workspace.

Is this an agent framework?

No. Frameworks help you build agents; the autopoet maintains the agents you already have. It ships inside the Workbooks runtime as the self-maintenance layer: one actor per workspace, off by default, bounded by ceilings you author in plain files.

Does it learn? Where does the learning live?

Three mechanisms, no gradients, no GPU: plasticity on the workspace graph, surprise-gated cognition that installs reflexes, and an economy that assigns credit by selection. All of it is inspectable data in your tree — weights, rules, lessons, ledgers. Nothing it knows is somewhere you can't read.

Can I turn it off?

It starts off. Nothing runs until an admin arms the heartbeat; disarm stops it instantly. For a gradual rollout, set postures to proposed — the autopoet prepares every change and humans merge each one.

What happens when it makes a mistake?

A bad candidate never reaches the live tree: every change is validated in a throwaway scratch copy first, and merges pass the same compile-and-check gate as human changes. Rejections and dismissals become lessons in the knowledge log — the same mistake isn't proposed twice.

How is this different from cron plus an LLM?

A scheduled LLM script has no constitution: nothing bounds what it edits, no scratch isolation, no typed intake, no authority model, no memory beyond its prompt. The autopoet is a governed loop — ceilings, postures, leases, eval-in-scratch, an injection firewall — with learning that compounds as data. The schedule is the least interesting part.