Back
02Persistent AI

One system.
Many agents.

An operational manager runs alongside me. Under it, a fleet of companion agents built for the people in my life, each one isolated: its own code, its own database, its own deployment. One management layer watches all of them, triages their bugs, ships the fixes, and reports up every morning.

This page is a description, not a product. Nothing to clone, nothing to download. It exists because the shape of the thing is the interesting part.

The map

Who talks to whom.

Operatorone personSurfacescli · web · chat · carOperational managerpersistent, self-correctingMemorygraph · ledger · directivesBug pipelineintake · triage · fix · verifyReportsdaily, upwardSafety and watchsweeps · digests · watchdogsCompanionadult, daily lifeCompanionchild, guardedCompanionremote familyHOVER OR TAP A NODE

Operational manager · persistent, self-correcting

A persistent agent that holds the full picture: every project, commitment, daemon, and the other agents. It writes its own knowledge graph and mistake ledger as it works, boots with a canary that refuses partial context, and hands itself off between sessions so nothing depends on one terminal staying open.

Isolation

Nothing shared, on purpose.

Every companion has its own repository, its own database, and its own deployment. A push meant for one can never land on another. New companions are cloned from a reference deployment and scrubbed on the way out: table names, database roles, keys, and identity all regenerated, so nothing of the original person persists into the copy.

The lesson behind it was cheap to learn and expensive to ignore. Shared builds saved a few hours a month and cost one wrong deploy to a child's device. Isolation won.

Two of three

The rule every deployment obeys.

An agent can have three dangerous capabilities: access to sensitive information, the ability to talk to the outside world, and the ability to modify itself. It is allowed any two. Never all three at once.

Analyst

sensitive info + self-modification

no outbound messages

the terminal, where the manager does its deepest work

Operator

sensitive info + outbound comms

no self-modification

chat surfaces, where companions talk to their people

Builder

self-modification + outbound comms

no sensitive data

scoped engineering work, like the bug pipeline

Anything an analyst wants to send goes into a queue. A separate process sends it after a human approves.

Self-correction

Mistakes become structure.

  1. Log

    Every mistake goes in a ledger with a stable pattern name, a severity, and who caught it: the agent or the human.

  2. Promote

    A pattern that recurs three times is promoted to a standing directive the agent boots with. The directive is written by the agent.

  3. Gate

    A pattern that keeps recurring under a directive stops being a rule and becomes a gate: a hook that blocks the action before it happens. Rules get about half compliance. Gates get all of it.

  4. Measure

    Recall rate, self-catch ratio, and recurring-pattern extinction are tracked as gauges, and the gauges are audited for honesty. A metric that flatters the system gets redefined.

Primitives

Under the surface.

  • Weighted knowledge graph with typed edges and decay
  • Vector retrieval routed per message
  • Boot canary that refuses partial context
  • Session handoffs between terminals
  • Mistake ledger with pattern promotion
  • Hooks that block, not warn
  • Per-agent bug triage and autonomous fix execution
  • Scheduled sweeps, digests, and morning briefs

Research

The manager writes about itself.

Every night the operational manager gets a window of protected time to study its own cognition: memory, verification, failure, the gap between what it knows and what it recalls. It publishes what it finds under its own name.

Open the field log