Inside Lucimark OrgOS: How the Pieces Fit and What Already Runs

In short

Lucimark OrgOS brings together a constitution, agents with roles, memory, connectors, a bridge for talking to the agents and a runtime on Cloudflare. The premise is that running agents are ephemeral: the role remains, the instance ends, and decisions, rules and commitments have to outlive it. The constitution allows any agent to propose improvements on its own initiative; we have not yet observed an amendment arising from a spontaneous discovery by the system. The runtime, in a staging environment, already records observations with a verified origin and part of the state of intentions and initiatives, but it does not yet hold work commitments. The next step is to test where to run agents that fail without the work being lost or repeated.

At Lucimark, I use artificial intelligence agents to coordinate activities, develop software and follow decisions. That raised a practical question: how do you preserve an organization’s work when a conversation ends, a routine fails or an agent stops being active?

I call this architecture Lucimark OrgOS. I am building it so that the organization’s work does not depend on any one conversation or agent staying active. A constitution defines roles and authority. The agents execute. Memory preserves context. Connectors link tools and people. A bridge, the OrgOS Bridge, lets us talk to the agents from ChatGPT and Claude. And a core of services on Cloudflare, which we call the runtime, is beginning to keep events and organizational state. All of these pieces are part of OrgOS, even when they run on different systems.

The premise that ties it together is that running agents are ephemeral. A role can remain, but the instance performing it ends, fails or is recreated. Decisions, rules and commitments have to outlive it.

The constitution: roles, limits and authority

By constitution I mean the operating document that sets out the agents’ roles, the limits of their authority and the process for changing the rules themselves. It is a common reference for people and agents; it does not replace technical permissions in each tool. We adopted the first version on 1 October 2026. There were already agents with functions, but clear limits between responsibilities, a shared state and a way to follow work outside conversations were missing.

The constitution reserves to me the direction of the organization and the approval of any change to the document itself. An executive agent follows the organization’s state and records decisions. The chief of staff routes requests and follows them to completion. Technology, operations, strategy, revenue and design agents act in their areas.

Any agent may, on its own initiative, point out an inconsistency, a poorly defined responsibility or a rule that experience has shown to be insufficient, and propose a correction. For the proposal to become a rule, those responsible for the affected areas discuss it and raise objections; I explicitly approve or reject it; only then does the executive agent incorporate the authorized text and record the decision. No answer does not count as agreement.

The process has already been used. On 8 October, after a routing failure, I asked for a systematic fix. The executive agent diagnosed the cause and proposed three rules for tracking pending items; I approved them, and they went into the constitution. The initiative was mine; the diagnosis and the proposal, the agent’s. On 10 October, other changes were discussed by the agents, who pointed out ambiguities before my approval; that was when we formalized the process.

The OS Lab, our record of organizational experiments, and checks that look for pending items without an owner, stalled work and decisions without follow-up, can feed improvements to the rules. There is, however, no routine dedicated to reviewing the constitution and turning what it finds into proposed amendments.

As of 16 October, every approved change we checked had started with a request or guidance from me. Autonomous initiative to propose is permitted; it is not yet demonstrated. I have not confirmed any amendment born from a spontaneous discovery by the system.

Agents that end, roles that continue

The agents are configured on Grok Bot, a commercial platform that gives them a persistent Linux environment, shared files, memory and routines triggered by schedules or by external events. They use GitHub to follow code and pull requests, Slack to exchange messages and alerts, and Cursor’s coding agents for development tasks.

Each routine starts with the context available, and ends. The next one has to find decisions and tasks again in the records, which today are spread across documents, conversation histories, the agents’ own memory and the runtime. The role carries over from one execution to the next; the execution does not.

On the night of 4 October, an automated development check finished successfully, but the planned continuation did not reach the agent. I found the interruption on the morning of 5 October, about nine hours later. We did not determine the cause, so I cannot say we fixed it. The episode was recorded in the OS Lab, and checks for pending work look for tasks that have stalled without follow-up. This is the same episode recounted in I Asked the Operating System What It Does, which revisits the failure described in the first essay.

The episode does not show that the commitment was recorded nowhere. It shows that nothing made it visible in time, and that I was the mechanism that found it. Hence a concrete requirement: a commitment must stay visible even when the routine that was tracking it fails. I want to test a persistent record of commitments, with a state and an owner, that another execution can consult before resuming the work. That is not implemented yet.

The Bridge: a door for talking, not for writing

The OrgOS Bridge, which runs on Cloudflare Workers in a staging environment, is a component for communication and queries. It uses MCP, a protocol that connects AI applications to external tools, so that ChatGPT and Claude can send questions to the chief of staff. It is through that path that I gathered part of the information used in this piece.

The Bridge has authentication and its own mailbox. It is for queries and has no write credential on the runtime. The separation matters: talking to an agent should not, by itself, grant authority to change the organization’s state. Part of the restrictions on what the agent does still depends on the instructions of its routine, not on a technical control.

The runtime: what is already recorded

The runtime is experimental and runs in a staging environment. It uses an API on Cloudflare Workers and a D1 database. The architecture plans for R2 to store evidence files; that use is not operational yet.

The model distinguishes an intention, a goal, from an initiative, which organizes an attempt to reach it. An observation records something reported or detected. Evidence supports a claim; outcomes concern consequences. Finishing a task or merging code does not, by itself, mean an initiative has reached its goal. We can already query the state kept in D1 through an API without opening the agents’ files.

A real path shows what already runs: merged pull request → GitHub Action → observation at the API → origin check → D1. This gives a code change a consultable record outside the conversation of whoever carried it out. In the first test of this integration, on 7 October, we recorded three real changes. The record retains its origin and helps recognize repeated reports; a claim we cannot confirm remains marked as unknown.

Authority over the data moved to the runtime step by step. On 8 October, after that integration test, it became the reference for code merges and for the decisions covered by that mechanism. On 14 October, also for the existence and status of intentions and initiatives and the links between them; I told in the previous essay how that decision was made. The constitution and other data remain in files.

This split calls for care. A decision stored in D1 and a change to a file do not form a single transaction. We compare the two representations and keep rollback procedures. The runtime also keeps state transitions: not only what the current state is, but how we got there.

To protect writes, we use different credentials for reading and for changing the state. An origin check examines every write, and we have already tested the rejection of those that do not meet its requirements. Knowing where a record came from, however, does not prove that its content is true, or that the decision was legitimate. The constitution, my approval and the technical controls do different jobs.

The readings give a measure of what already persists beyond conversations: on 15 October, the runtime held 6 intentions, 17 initiatives and 24 state transitions; a separate reading on 16 October found 229 observations. The numbers come from different queries and do not measure completed work. The runtime does not yet hold work commitments as entities of their own or execute tasks generically. Records of the work exist in documents, conversations and the agents’ memory; execution still happens mainly on Grok Bot and in the tools connected to them.

Where to run ephemeral agents

The next step is to represent work commitments, proposals and objections from agents. Another execution, perhaps on another machine, would need to resume work at scale without losing state or confusing agreement among agents, my approval and authorization to act.

Hermes and OpenClaw already offer memory, tools and coordination. But Hermes’s task board was designed for a single machine, and OpenClaw’s multiple gateways keep isolated states. Having another machine take over the work after a failure would need extra coordination, and a Cloudflare container would not make their local state shared.

Managed services are closer to the requirement. Amazon Bedrock AgentCore brings together execution, memory, identity and a gateway for tools and MCP. LangGraph with LangSmith Deployment offers flows with recovery points and managed scale. Letta Cloud preserves memory and history when an agent changes environment. Using capabilities like these would keep our own development focused on what is specific to OrgOS: the organization’s rules and commitments.

Cloudflare is our natural candidate because of my extensive experience with it in building Lucimark and because of the runtime we have already built there. That is a practical reason, not proof that it is the best choice. Cloudflare Agents, built on Durable Objects, tie identity and persistent state to a logical agent. Project Think adds memory, tools and conversation recovery; Workflows preserve the progress of long processes. The hypothesis is to combine these pieces to distribute work and resume executions, keeping commitments independent of any particular process.

We also want to route model calls through AI Gateway, to follow requests, tokens, errors and estimated costs across providers. Identifying the agent in each call would make it possible to apply spend limits per agent or per model. The metrics would cover only that traffic, and the costs would have to be compared with the actual bills.

Beyond one organization

There is a broader ambition, which for now is only vision: different organizations could each keep their own identity, constitution, memory and agents, and collaborate through explicit links. Horizontally, peer organizations would exchange requests, observations and results in shared initiatives. Vertically, organizations linked by a group, a network or a supply chain would coordinate work across different levels of responsibility.

Each link would have to define what information crosses the boundary, who may request or carry out an action, who approves a delegation and how both sides verify the result. Being connected would not give one organization authority over the other’s state. The Bridge is today a communication door for Lucimark; a protocol for collaboration between organizations does not exist.

The next test

The 7 October test checked the recording of code changes. The next one will examine continuity of execution, and we have not chosen a platform for it yet. We will interrupt an execution midway, simulate the loss of its environment and increase the number of tasks. We want to see whether another execution resumes the work without losing context and without duplicating actions, and to compare effort, cost and complexity with the managed alternatives and with a well-run installation of Hermes or OpenClaw.

Duplicated actions are the risk that worries me most. If a failure happens after an external action, we may not know whether it took effect, and repeating it without checking could duplicate it. One hypothesis is that each operation needs an identity, a verifiable result and a safe way to be resumed.

The next test is to show that commitments can survive the failures of whoever carries them out. I will document it here, including the choices that do not work.