This is part four of Agentic Operating System For Your Business. Part one began with the Chief Agentic Officer Briefing. Part two followed the podcast until it hit the publishing gate. Part three asked whether the harness is the employee and the API is the contractor. This chapter is about the moment I realised I was no longer building a messaging room. I was building an operating system.

I thought the decision was simple.

The Chief Agentic Officer work had started as a briefing, then a subscriber path, then a publishing loop, then a visible place for agentic work to move through.

So I made the next decision: stop treating it as a messaging platform and turn it into a full Agentic Operating System For Your Business.

Little did I know.

The glue problem

There is a big difference between asking Codex to run a task here, setting an overnight run there, and holding the whole thing together in your own head.

That is the early-stage version.

You are the glue.

You know which task was started. You remember what it was meant to do. You know which worker was used. You know which file matters. You know whether the result can be trusted. You know what has been spent, what has been tested, and what still needs a human decision.

That works for a while.

Then the system grows.

It now has to know where work runs, which runner owns it, what state it is in, what evidence has come back, what the next gate is, what is allowed, what is blocked, what has failed, what can be retried, what needs a server, what can stay local, and what must not happen without approval.

At that point, you are no longer improving a chat room.

You are building the operating layer of a company.

The business operating system

A company is already an operating system.

It has procurement, supply, finance, sales, marketing, research, delivery, operations, admin, risk, and governance. We call them departments because that is how humans organise work. Underneath, they are operating functions.

If agentic workers are going to hold meaningful parts of those functions, the business needs more than prompts.

It needs runners.

Some work may run in Codex because the harness gives it local files, terminals, tools, approvals, and reviewable evidence. Some work may run on a server because it needs to be scheduled, resilient, or always available. Some work may need a direct API path. Some work may need a local or sovereign AI route where privacy, jurisdiction, resilience, or cost makes that route the right answer.

The point is not that one route is morally superior.

The point is that the business should know which route it is using, why that route was chosen, what authority it has, and how to stop it.

For me, that is why Orchistra matters. It is not just a place where agentic work chats. It is becoming the operating room: lanes, routes, receipts, state, handoffs, escalation, review, and human oversight.

The Chief Agentic Officer idea is not separate from Agentic First, Orchistra, or SNAXK. They are all part of the same practical question: how do you make agentic work useful without turning the business into fog?

Zero to corpus

The first recurring proof line in this series is still the same.

We started with zero useful briefing corpus.

No issues. No tracked signals. No linked sources. No topic threads.

Now the system has 15 issues, 76 tracked signals, 76 linked sources, and 64 topic threads.

That matters because a business operating system needs memory, not just activity.

Tasks are not enough. A good company knows what it has seen, what it believes, what it is watching, what changed, what evidence supports it, and which decision may come next.

The operating system is not merely doing work. It is accumulating structured attention.

Are we nearly there yet?

While building this, I kept thinking about family holidays when I was a kid.

We would be in the car. A little Morris Minor Traveller, the wooden-framed one. Three children in the back. Mum and Dad in the front.

And the questions would start.

Are we nearly there yet?

Where are we?

Have we passed Salisbury?

Have we passed Exeter?

Can you see the sea yet?

That was not just childish impatience, although there was definitely some of that.

It was a need for orientation.

Those places were waypoints. They told us where we were in the journey. They turned an unknowable stretch of road into something human-sized. They meant progress could be felt.

Modern companies do the same thing with OKRs, milestones, percentages, traffic lights, burndown charts, status reports, dashboards, and board packs.

Humans need to know where they are.

A coastal countryside route map showing how agentic work moves from task and messaging into an operating system with runners, state, control, evidence, and human-visible waypoints.
The agentic operating system needs waypoints: task, room, runner, system, and sea visible.

AI does not naturally give you the road signs

One of the small changes I made this week was almost comically basic.

I asked the worker to tell me the percentage.

Not because the percentage is mathematically perfect. It rarely is.

Because without it, a long-running agentic build can feel like silence with a spinner attached.

Tell me which section we are in. Tell me what is built. Tell me what remains. Tell me what is blocked. Tell me whether the current stage is thirty percent, sixty percent, or basically stuck outside Exeter with a warm sandwich and declining morale.

This is not just a personal preference. Usability research has said versions of this for years. The visibility of system status is one of the basic heuristics: people need feedback about what is happening. Progress indicators reduce uncertainty, especially when a process takes more than a moment. Yale's usability guidance makes the same point: status feedback tells people where they are, what is happening, and what to expect next.

Agentic work makes that old lesson more important, not less.

A worker that disappears for six hours and returns with a result may be impressive.

A company cannot run on impressive disappearances.

Desired state, current state, receipts

The operating model I keep coming back to is simple to say and difficult to build.

What is the desired state?

What is the current state?

What is the difference?

Who or what is allowed to move it?

What evidence proves the movement happened?

That is familiar software thinking. Kubernetes describes objects as records of intent, with a desired state and observed status. Controllers then work to bring the current state closer to the desired state. Observability systems such as OpenTelemetry give distributed systems traces, metrics, and logs so humans can understand what happened across components.

An agentic company needs the same discipline in business language.

If you cannot say where the work is, what state it is in, what runner owns it, what evidence exists, what it costs, and what can stop it, you do not yet have an operating system.

You have a set of clever errands.

The runner question

This is where the work became bigger than I expected.

The system needs to run on Codex. It needs to run on servers. It needs to be able to use different AI environments. It needs to allow local or sovereign AI routes when I want that. It needs development environments, test environments, backups, security, audit trails, and recovery paths.

It also needs to run more than one business.

Not every company I am involved with. Some have their own environments and governance, and that should be respected.

But for the companies I wholly own and am starting up, I want the same operating backbone to be able to carry the work.

The job contract should travel.

The runner can change.

The company should still understand what the work means.

The shepherd job

This is why the Shepherd Of Agentic Sheep idea still holds.

I am not pretending agents are employees or people.

The shepherd sets the field.

Goals, roles, budgets, permissions, evidence standards, cadence, stop-lines, review points, and escalation routes.

The agentic workers can act inside the field.

The human remains accountable.

MCP helps here because tools, resources, and prompts can be exposed in a structured way to an AI application. But the operating lesson is not merely "connect more tools." The useful part is controlled capability: clear contracts, consent where action is involved, and receipts after work is done.

More capability without more state is just a faster way to lose track of things.

Where I am now

This build has taken longer than I thought.

It has burned through more Codex resets than I particularly want to admit in public, so naturally I am admitting it in public.

The current tests are encouraging.

But this is the middle of the journey, not the arrival.

The exciting part is not that everything works perfectly. It does not.

The exciting part is that the shape is becoming visible.

A company that can route work to the right runner. A company that can remember what it has seen. A company that can show where work is. A company that can stop before spending, publishing, contacting, deploying, or changing something important without a named human approval.

That is the test.

Can I create a company that is run through agentic work, governed by human judgement, and capable of making money?

I do not need the system to tell me it is clever.

I need it to tell me whether we have passed Exeter, whether the sea is visible, and what happens if the car breaks down.

In this series

Sources and notes

This article is a field note from the Chief Agentic Officer build, supported by public product, protocol, and systems-design references. Product capabilities and deployment options change, so the sources below are used as current context rather than permanent guarantees.