Actor Registry: Humans, AI Operators, Knowledge Personas

Ask a CEO who makes which decisions in their company, and you mostly get a list of people, plus a few tools. Ask more specifically about a recurring decision that was made yesterday, and the answer turns vague. Who approved the price on the last quote? Who corrected the forecast? Who decided that lead wasn't actually a lead? In most companies, that's not cleanly documented. It's just felt.

The moment AI enters the picture, the question gets blurrier. An AI operator produced an output, a human signed it off, and a shared background assumption shaped the whole flow. Who was actually accountable?

A company that doesn't know who works inside it doesn't know where its quality comes from.

Rocket Routine OS has a clean mechanism for this: the Actor Registry. It recognizes exactly three kinds of actors, and each plays a different role in the system.

The three kinds of actors

1. Human Actors. People with decision rights, accountability, and judgment. They hold every Decision Right that hasn't been explicitly delegated to an AI operator. They are the only actors who are sovereign in the sense of the Constitution.

1. AI Operators. AI actors provisioned through a Role Contract. They run routines, produce standardized outputs, and respect explicit decision rights, tool access policies, and escalation triggers. They carry the execution load for defined routines, not the decision accountability behind them.

1. Knowledge Personas. Specialized AI actors with an advisory-only Role Contract. They have read access to assigned knowledge sources, no write access, no decision rights, no routine ownership. They can be invoked only by the Decision Moderator, and only when a decision needs an outside, domain-specific perspective.

These three categories are mandatory entries in the Actor Registry. Every actor has a record with its category, its Role Contract, and the domains it operates in. If an actor isn't in the Registry, it isn't working in the system.

Why the distinction matters

The three categories aren't just an inventory. They are three different distributions of accountability.

A Human Actor carries decisions. An AI operator carries execution. A Knowledge Persona carries a perspective that can feed into a decision but is never the decision itself. Companies that don't separate these three types blur advice into execution and execution into decision. That is where most of the dangerous confusions happen, where an AI output is treated as "the decision" because nobody can trace anymore who contributed what.

The clean separation in the Registry makes two things possible. First, full traceability of every decision back to an accountable actor. Second, sharp levers for improvement. A bad output belongs to a specific AI operator whose Role Contract gets tightened. A bad decision belongs to a specific Human Actor whose decision rights or decision method gets reviewed.

Knowledge Personas in detail

A Knowledge Persona is not a second chatbot. It is not an "AI expert" called in alongside the AI operator. It is an architecturally distinct construct.

A Knowledge Persona consists of a read-only Role Contract that defines exactly one thing: which published knowledge source forms the basis of its perspective. That can be the work of a specific author, a methodology, a standard. The boundary matters. A Knowledge Persona speaks only from the corpus it was assigned. It does not improvise. It has no access to operational company data. It cannot write. It cannot trigger anything.

And it isn't freely callable. It is invoked only by the Decision Moderator, the mechanism that formally selects the decision method for an open question. When the Decision Moderator determines that a decision needs external perspective, it invokes one or more Knowledge Personas and receives a synthesized statement back.

A Knowledge Persona speaks. It does not decide.

This invocation gate isn't bureaucratic, it's hygienic. It prevents a Human Actor from pulling an arbitrary AI opinion into a serious decision and then citing "the AI," when the underlying knowledge corpus was never vetted, never assigned, never methodologically embedded.

Domain Advisory Boards

Multiple Knowledge Personas in the same domain form a Domain Advisory Board. For the Product domain, that might be a board of three Personas, each carrying the work of a different thinker. For the Sales domain, it might be a different board entirely.

When the Decision Moderator poses a domain question, it doesn't get a single voice back. It gets a synthesized view from the board, with the differences between Personas surfaced rather than smoothed over. That is the point: a board exposes tensions between schools of thought instead of hiding them.

Company 0

At Rocket Routine, we currently have three Knowledge Personas in the Registry. One is based on the published principles of Donald Reinertsen on product development flow. It gets invoked by the Decision Moderator when WIP limits in a domain are being re-set. It returns a statement from the corpus, the Decision Moderator records it as input, and the final call sits with the Human Actor who owns that domain.

Last week, the open question was whether the WIP limit for the content production domain should be raised from three parallel articles to five. The Reinertsen Persona returned a clear statement: the current variability in quality confirmation suggests that raising WIP would not relieve the bottleneck, only shift it. The decision wasn't made by the Persona. It was better informed. In the end, I decided to leave the limit unchanged and to analyze the distribution of rework instead.

The Knowledge Persona didn't produce an output. It produced a better question.

That is its function. Not deciding. Not executing. Bringing in a perspective that a Human Actor would otherwise overlook.

What comes next

The Actor Registry answers a simple, often-overlooked question: who is actually working in your company? In Rocket Routine OS, that question stops being felt. It is explicitly answered, per actor, per role, per domain.

In the coming weeks, I'll look at how FTT, Verification, and Poka Yoke together form the quality mechanism that makes these actors steerable in the first place. Quality confirmation is not a judgment call. It is a structural precondition.

If you run a founder-led B2B company with 15 to 50 employees and want clean accountability between humans, AI operators, and external knowledge: rocket-routine.com