Who Governs a Company When the Agents Start Executing?

In short

On 14 October 2026, Lucimark changed, in a staging environment, where part of the company’s state lives: from files to a canonical runtime. Before the switch, the system recommended waiting. I decided to go ahead that same day, with a condition I had set myself still unmet. The decision was authorized and recorded, and the switch worked. That is not enough to say it was well governed. The episode shows the difference between authority, which says who may decide, and governance, which says under what conditions, and it shows that our architecture is still better at recommending and recording than at telling a legitimate exception apart from a protection suspended without care.

On the morning of 14 October, a routine in the system I am building for Lucimark recorded a short sentence: the condition for the change scheduled that day had not been met. There would be no change. The proposal was to postpone it to Friday, and the decision was left pending with me.

The change was to move where part of the company’s state lives: the intentions and initiatives that say what we are trying to do. For a few days, every change was written in two places: in the files the agents kept and in a new runtime, the future canonical source. The condition, which I had set myself in a recorded decision, was simple: switch only after two consecutive working days with no difference between the two. The 13th had closed with two differences. Two of my decisions had reached the files and not the runtime.

Early on, both were rewritten in the runtime and the difference disappeared. Even so, that morning’s readiness analysis recommended not going ahead: correcting it afterwards does not erase the fact that, at the close of the day, the two sources disagreed.

Hours later, I decided to go ahead anyway, knowing I was giving up that observation window. The decision was recorded, the switch ran and the checks found no divergences. A decision can be authorized, recorded and technically successful and still leave open whether it was well governed. The question is no longer only who decides when an agent may act. It becomes under what conditions, and who checks that they were respected.

Executing is not governing

In earlier essays, I described Lucimark OrgOS as a set of agents with roles, the rules they work under and a structured record of the company. One agent coordinates and records decisions; another takes care of engineering; others take care of operations, revenue and strategy. The titles are operational metaphors. None of them holds the company’s sovereignty. The routing principle we adopted says that I talk to the organization, and the organization finds who is responsible.

Automation executes tasks; an agent chooses actions within limits; an organizational operating system should preserve decisions, enforce limits of authority, observe consequences and keep continuity. The problem is more organizational than technological: no better model answers on its own who authorized what.

The 14th forced me to separate two words I had been using almost as synonyms. By sovereignty I mean the legitimate origin of authority: at Lucimark, today, that is me. By governance I mean the rules and mechanisms that say how that authority is exercised, delegated, limited and verified. Authority says who may decide. Governance says under what conditions. And execution should be able to show that it respected those conditions. I treat this as a hypothesis, not a doctrine.

There are also three different capabilities. Recommending, the system did. Authorizing, I did. Preventing is something else. The available records do not show that the operation was subject to an independent check of the governance conditions. A recommendation to wait, plus a human authorization, is not the same as a control capable of preventing.

Watercolour illustration in three panels, in a garden, titled "Recommend, authorize and prevent". In the first, labelled Recommend, a small robot-like agent shows the founder a sheet with a tick, a chart and a warning sign, while he thinks, hand on chin, in front of an open book. In the second, labelled Authorize, the founder writes in the book while another agent waits by the gate. In the third, labelled Prevent, an agent raises its hands in front of a box resting on the gate, whose latch is tied by a red thread running from the book. — Figure 1 **Three different capabilities.** On the 14th, there were the first and the second. The records do not show the third.

A decision has to survive the conversation

The decision log exists because a conversation is a bad place to keep authority. In our design, a single agent writes decisions; the others propose. My decisions are recorded with their origin, and corrections become new entries, without erasing the old ones.

That morning, the readiness analysis cited a deadline rule I had already replaced. An erratum in the document itself corrected the reason, and the error stayed visible instead of being quietly fixed.

Having a single writer of decisions does not guarantee a single truth. The recorded decision, the authorization of an action, the execution event and the resulting state are different things, and they can diverge. The divergence on the 13th was exactly that. The text that now describes the canonical source says something I consider central: a signature proves which key wrote a record, not what the founder said.

Watercolour illustration in four panels, in a garden, titled "The four layers of organizational truth". In Decision, the founder writes in an open book. In Authorization, he opens the latch of a gate with a bell. In Execution, a robot-like agent waters raised beds while another holds a clipboard. In Resulting state, the beds have grown beside the swimming pool. A red thread runs through all four panels, from the book to a stake among the beds. — Figure 2 **Four layers, not one.** What was decided, what was authorized, what was executed and the state that resulted can diverge.

The problem of human awareness

A week ago, I set a rule for myself and for the system: a decision of mine should only count when there is evidence that I understood what I was deciding. That means a prior explanation in plain language, the consequences, whether it can be undone, and a reply from me that shows I read it. Silence does not count, nor does a bare “ok”. The rule has already been applied to me: once, tired, I authorized a plan without having read it, and the authorization stayed pending until I had studied it. The section of the constitution that would formalize this is still a draft; for now, it is a practice.

The decision to go ahead on the 14th shows the layers of that evidence. I read the consequences presented to me before authorizing the execution, but that does not mean the record proves what went on in my head. The documentation preserved the decision, the listed consequences and a note that I had read them. Part of that evidence reached the record through an intermediary’s report. What the files show directly is that the decision and the consequences were recorded before the execution. My reading, which I confirm, and its documentary provenance are separate questions.

A report of understanding is not proof of understanding, and passing through an intermediary does not invalidate the decision either. They are different levels of confidence, and the record should say which one supports each material decision. No system proves a state of mind.

There is also the opposite risk. If every decision demands this rigour, I trade manual work for approval requests and remain the bottleneck. On 14 October, small, reversible decisions were recorded with light confirmation, and the switch as material. In the records I consulted, that classification appears as an annotation made in the decision record itself; I found no mechanism that applies it independently. And an irreversible decision can be legitimate, if there is understanding of the consequences, appropriate authority and proportionate control.

Where an organization’s state lives

In the second essay, I wrote “state, not memory”. In the third, I told how the agents kept the company’s state in files. On 14 October, part of that state, the existence and status of intentions and initiatives and the links between them, came to have the runtime as its canonical source. The corresponding files became read-only copies.

Reliable state has to say, with provenance, what is decided, who authorized it and what is still pending. The switch was partial: objectives, risks and limits of authorization remain in the files. And there was a finer gap. After the switch, the company’s state still said that the condition for the switch had not been met. The exception existed in the decision log, not in the governed state.

Changing without losing the way back

There are four facts. There were divergences, and the system recommended waiting. I went ahead with the observation condition unmet. The decision and its consequences were recorded before the execution. The change ran in a staging environment, with checks and a rehearsed way back. None of it was in production.

What these facts do not say is what kind of act I performed. I did not rewrite the two-day rule, nor mark it as superseded. The new decision superseded the one to wait until Friday and recorded that I was giving up that window. From what the records show, it looks more like a one-off exception, opened by the same authority that had created the condition, than a formal change. One of the earlier records anticipated that, if a condition failed, the date came back to me. But the architecture does not define what procedure an exception of this kind requires. So it cannot say whether that was the legitimate exercise of authority or a protection suspended with too little care. Nor can I, from what is written alone.

That the switch worked says something about the technique, not about the quality of the process, the legitimacy of the authorization or compliance with governance. A rehearsed way back that worked does not make everything recoverable. That same day, a tool ran twice and contaminated a backup that was part of the recovery; it was redone from a clean copy. Not having observed any loss is not the same as guaranteeing integrity.

One hypothesis I want to test is to separate classes of rules. Some are operational and can change in the course of work. Others are delegable, within limits. And some would be governance constraints: protections the sovereign creates for himself, which should only be changed, suspended or given an exception through a procedure of their own, one that names the rule affected, appears in the state and is checked by someone other than whoever executes. I do not know whether the classification holds, but on the 14th it would have made visible the difference between changing my mind and switching off a protection.

The question remains: who protects the organization when the sovereign suspends a protection he created himself? Saying he can do anything empties the protection. Making it immutable trades authority for rigidity. A hypothesis for future investigation, not yet decided: suspending a protection should be more explicit and observable than creating the rule in the first place, not necessarily harder.

The organization has to continue without me

The first essay ended by saying that the operating system was still a person. The architecture I am describing tries to take that person out of daily execution without taking away his ability to define intention, limits and authority, and to assess consequences.

The 14th shows mechanisms for state, authorization, verification, migration and recovery. It does not show business autonomy, better decisions, commercial results, or the organization operating for days within authority already delegated. I was still at the centre of almost every relevant decision, including the one that gave up a protection of my own.

I note one consequence in passing: if OrgOS ever serves other organizations, it cannot depend on a single sovereign founder. Many distribute authority among partners, directors, boards, heads of area and approval policies. That is a future subject, not something that exists today.

I am left with a question I cannot answer. If the organization preserves the founder’s intention, executes within known limits, acknowledges its own mistakes and keeps continuity, at what point does it stop needing him as an operator and start needing him only as an authority?