I Asked the Operating System What It Does

TL;DR

I asked OrgOS, the system I am building with AI agents for my company, to say what it does using only its own records, and to say "not recorded" wherever the records were silent. The answer showed three places where the work of an organization can live: in a system, in agents following rules, and in one person's memory. Most of it lives in the second place today, and some of it only in the third. The most valuable part of the answer was not what the system does but what it admitted it does not know. Building it means moving what an organization depends on out of one person's memory, one function at a time, without pretending it has moved before it has.

In the first and second essays I used organizational operating system as a working name. Sooner or later a name has to earn its place, so on 6 October I did something simple: I asked the system.

By OrgOS I mean the whole arrangement I am building for Lucimark, the company I founded: AI agents with roles, such as CEO, CTO or chief of staff, who keep the company’s state in files under rules I have set, and a small piece of software, still in testing, meant one day to hold that state on its own.

I asked the question I would ask a new colleague: what do you actually do? I added two conditions. Answer only from what is recorded, and say where each claim comes from. When something is not in the records, say not recorded instead of filling the gap.

Its summary began: “Alone, I do one thing.”

I expected a list of capabilities. What I received was closer to a confession.

What an operating system is for

A computer’s operating system does not do the applications’ work. It does the quiet things without which they could not coexist. It remembers what must outlive a single program, keeps a journal of what happened, decides who may touch what, and wakes a program when what it was waiting for arrives.

An organization of people and agents needs the same quiet things. This is the list I am using:

State: what the organization currently believes to be true.
Provenance: who said so, when, and on what evidence.
Authority: who may decide what, set in advance.
Continuity: work that resumes when its moment comes, without someone having to remember it.
Feedback: what is learned returns to whoever can decide what to change.

In my company, until recently, almost all of these lived in one place: my head. That was the subject of the first essay. When I gave the system a name, I was claiming that something else had begun to perform them. The honest question was what, and where.

Three places a function can live

The answer sorted every claim into one of three places, a distinction I had not drawn so sharply myself.

The first is the system itself: the small piece of software we are building so that the company’s memory outlives any one agent or conversation. Alone, it does the one thing of the opening line. It records, with source and time, each change accepted into our code. Little else. It holds no purposes, no initiatives and no outcomes yet. It says so plainly, and it declares that it is not yet the source of truth.

The second is the agents and their rules. They keep the company’s state in files, along with a log of decisions and a short operating constitution adopted on 1 October. The constitution sets four levels of autonomy: observe, propose, act on what can be undone, and, for anything material or irreversible, act only with approval. One agent alone may write the company’s state; the others propose. Today, this is where most of the operating system actually lives.

The third is memory and conversation: whatever was said to an agent or to me and never written down. The instruction was explicit: for the system, that counts as not recorded.

That third place is the uncomfortable one. It is me.

What the records show

The interesting part of the answer was not what the system does. It was how precisely it could say where things had gone wrong, and for how long.

Two versions of reality. A change to the company’s public website stayed invisible to the company’s own state for 21 hours and 57 minutes. Nothing was broken. The website had changed; the record of what the company believed had not. Two versions of reality simply coexisted for most of a day, and nobody noticed until I asked for a fresh picture.

Work that waited for me. An agent told me I did not need to act: the next step would start on its own when an automated check finished. The check finished late that evening. The signal never came, nothing else was watching, and the work resumed only when I picked it up by hand. It is exactly the failure the first essay described: knowing what comes next is not the same as continuing. This time it was on record.

Refusing the shortcut. One afternoon, during a small experiment, an agent lost access to the one source it was allowed to read. There was an easy shortcut: look the answer up somewhere else. The experiment’s rules forbade it. The agent wrote unknown, stopped, and asked the agent responsible for that access, which was restored the same afternoon. A fast answer from the wrong place would have looked better. An honest unknown was worth more.

The first thing to drift. The system carries a short description of itself: nothing writes to it in the course of business, and no one depends on it. On 5 October an agent noted that this was no longer true; by then the system was receiving facts on its own. More than thirty hours later, when I asked my question, the description had not changed.

Hand-drawn illustration of a workbench. On the left, a framed drawing covered in dust and cobwebs, marked with a small red flag, shows a brass box with five paper slips and nothing connected to it. Beside it stands the real box with the same five slips; a red thread enters it through a slot on one side and leaves from the other toward a small robot-like agent, who sits on a stack of books reading a sheet of paper. — Figure 1 **The first thing to drift.** The system’s description of itself said that nothing wrote to it. By then something did, and the description had been flagged as out of date for more than a day.

I recognized myself in that. The first thing to drift away from reality was the system’s description of itself. Founders drift the same way: the story we tell about our company is often the last thing to learn what the company has become.

What still lives in me

My last question was the hardest one to ask: based only on your records, what still depends on Paulo remembering?

The answer named three things. Replies from prospective customers, because they arrive on my phone and the organization cannot see them. Decisions I make in conversation, which exist only if an agent writes them down; the answer listed at least four that never were. And whether what I approved actually reached the world: the website change from 3 October was still marked visibility unknown the next evening. The company did not know whether its own visitors could see it.

Then came a line I have not stopped thinking about. The system’s list of things it is unsure of was empty, and the answer explained why: not because there are none, but because nobody writes them into it.

Hand-drawn panorama. On the left, a large ledger lies open on a wooden table; on several of its lines a small empty square is outlined in red, and a red thread runs from the ledger to the right and stops in mid-air. On the right, Paulo walks away along a country path toward a distant town, looking at a phone. — Figure 2 **Not recorded.** What the system admits it does not know, and what it cannot know because it still travels with one person.

That changed how I read the first essay. The founder as operating system is not a single dependency to be removed. It is a set of functions, and each of them can live somewhere else. Some have already moved to agents working under explicit rules. A few are beginning to move into the system. Some have not moved at all.

And each of those functions has a person on the other end. A reply that depends on my memory is someone waiting. A decision that lives only in a conversation is a colleague acting on something they were never told. Moving a function out of memory is not only engineering. It is a form of loyalty to the people who depend on it.

What I am really building

So I no longer think the name is earned by what the code contains. An operating system is not where the code is. It is where the functions are performed. Asked honestly, ours says that agents following rules perform most of them, a small system performs a few, and I still perform some.

What I am building, I now see, is not a machine that knows everything. It is an organization that can tell the truth about itself: what it knows, how it knows it, and where it does not know yet. Most systems are judged by what they can do. I have started to judge this one by what it is willing to admit.

I do not do this work as someone who believes he creates from nothing. I believe we are co-creators with God: what we make is a response to what we have been given, and it should carry what we owe one another, which is truth, loyalty and love for the people it touches. A system that says not recorded instead of inventing is a small thing. For me, it is where that faithfulness begins.

The work now has a clear shape: move functions out of memory one at a time, record where each one lives, and never claim it has moved before it has.

The answer itself is a reasonable first test. A system that can say not recorded, measure how long it was wrong and name what still depends on one person is not yet an operating system. But it already knows where it is not one.