What an AI operating system is, for a business: the layer we run our agents on

An AI operating system, for a business, is the shared layer that every AI agent and every person in the company works on: where knowledge lives, where work is registered, which procedures agents follow, what each agent may touch and what a human has to approve. Some people call it an agent OS. The agents come and go. The layer is what stays.

Searches for “ai operating system” are up 876% in a year, according to Google Ads data, and the top results today are mostly glossary pages and forum threads. This article is about the business meaning, from how we run Bamboo Tech Studio.

Ours is a git-versioned Obsidian vault plus the rules around it. As of October 2026 it has more than 660 commits since June 13, 2026, 29 skills, 14 recorded decisions, a task register past number 553 and an agent memory of 81 notes. A coding assistant on our laptops, monitoring and compliance agents on servers, and chat agents for the team all run on it, alongside two humans.

An AI operating system is the layer under the agents

The first instinct with AI is to build one agent and give it a long prompt. That works until the second agent arrives. Now two agents need the same client context, both can create tasks, both can break things, and nobody remembers which rules each one was told.

A computer’s operating system solves the same problem for programs: shared files, permissions, a process table, logs. An AI operating system does it for agents. Each agent stays small and replaceable. The memory, the rules and the gates belong to the company.

The seven parts of an agent OS, and what breaks without each

1. Shared memory

A wiki the agents read and maintain: clients, projects, servers, decisions, lessons. We wrote up how ours is organized in the LLM Wiki in production, and how the different kinds of memory fit together in agent memory in practice, so here is only the governance point: it is under git. Every change has an author, a date and a diff.

Without it: every session starts from zero, and each agent builds its own private version of the truth.

2. One front door for work

Every task goes in one register, with a link to the note that documents it, in the same edit. A chat session’s task list is useful while the session runs, but it is visible only to that session and it ends with it. The register is what survives and what everyone can read.

One detail makes it hold: closing a task needs a line saying what happened, including “closed without doing it, because X”, which is what stops the same task from being reopened three months later.

Without it: work lives in a chat session and dies with it, and the second human cannot see what the agents are doing.

3. Standard procedures, written as skills

A skill is a short SKILL.md with a purpose, inputs, ordered steps, outputs and gotchas. Our rule for writing one: the task is done more than twice, has discrete steps, and the “how” is easy to get wrong. We have 29, covering things like publishing a site, provisioning a server, responding to a hacked WordPress install and running an agent with secrets injected at launch. They stay in one flat folder, grouped by a domain: field, because agents find skills by name.

Without it: each session re-derives the procedure, and the same mistake comes back every few weeks.

4. Scopes per agent

Each agent gets an identity and a list of what it may read and write. Two design choices matter more than the list itself:

• The identity comes from whatever launches the agent, never from the agent. It cannot claim to be another agent because it does not choose its own name.
• The scope table is a file in git. Resolution is deny, then write, then read, and anything not listed is refused. Adding a new folder to the vault never widens anyone’s reach by accident, and “who could read this folder in August” is answerable with git log.

In the table, our infrastructure monitoring agent may read infrastructure notes and write to exactly one file, its incident log. A support drafting agent whose workspace carries customer data may read one folder and write nothing. Private folders are denied to every agent. They also never reach the agents on servers: they are kept out of version control, so the read-only copies those agents read do not contain them. The simplest way to enforce a single-folder scope needs no code: launch the vault’s tool server with that folder as its root. We tested that boundary directly, and it refused ../, encoded traversal and symlinks pointing outside.

Without it: any agent holding the vault tools can read everything, including material that belongs to a different client or partner.

5. Approval gates: agents add, humans close

Our rule: agents can create tickets, follow-ups, drafts and proposals. Closing, deleting, invoicing and anything irreversible stay with people. The failure mode it prevents: an agent asked a read-only question can still close a real commitment, even while saying it does not know whether the work was done.

Agents that run on servers get a smaller door still. They read a read-only mirror of the vault, refreshed every 10 minutes, and write by adding one new file to their own proposals folder. A server-side git hook enforces it: the agent’s SSH key decides its identity, and a push may only add files under that agent’s folder. Editing or deleting anything, even its own earlier proposal, is refused. We tested it against writes to other folders, another agent’s folder, edits, deletions, merge commits and a bad path hidden in a second commit. All were refused; the legitimate add went through.

An organizer files some proposals on its own, with fixed rules and no model: only new files, only where the target does not exist yet, only under narrow folder prefixes listed per agent. Everything else waits for a human.

For destructive work by anyone, human or agent, we use five gates: a tested capability for the exact operation, explicit target IDs, a before and after diff with its blast radius, owner approval within a stated ceiling, and a rollback plus a way to verify the effect. Approval for one site is not approval for the fleet.

Without it: the agent that finds a problem also decides how to fix it, and you learn about the fix afterwards.

6. Monitoring that treats silence as a finding

A scanner that only sends a message when it finds something has a blind spot. If it stops running, for example because an edit drops its execute permission, it goes quiet, and that quiet reads exactly like good news. The edit that breaks it can even be the one that adds new checks, so the new detection never runs once.

Our rule for every periodic check: each completed run leaves a stamp, a separate watchdog alerts when the stamp goes stale, and a positive digest arrives even when nothing is wrong, so silence is never the only signal. The same applies to agents. “Message sent” in an agent’s own output is the agent narrating. We check the channel where the message should appear.

Without it: a dead monitor and a clean system look identical.

7. Written rules built from production failure modes

Many different failures in production AI systems share one shape: something fails and is recorded as a normal state, such as “pending”, “sent” or nothing at all. We keep a standard against it with twelve rules. A few of them:

• The default state is never the optimistic one. If you do not know what happened, the state is “unknown”.
• Nothing is confirmed before the effect happens. An agent must not tell a client “we already notified the team” unless a notification actually went out.
• A rule that lives only in the prompt is not a rule. A model can still do what its prompt forbids, so the enforcement has to live outside it.
• Always add a ceiling. Fix the specific cause, and also cap any loop at N actions per minute, including loops you have not seen yet.

Without it: each incident gets fixed once, locally, and its cousin shows up in a different agent next month.

Many agents and many humans on the same layer

An AI operating system has more than one reader, so it needs a few rules about who writes what.

• One schema, several agent families. CLAUDE.md for Claude Code, a shorter vendor-neutral AGENTS.md for Codex and others, and a STANDARDS/ folder that wins whenever they disagree. When a rule changes, it changes in the standard first.
• Shared knowledge, per-person working state. Everyone reads everyone’s working notes; each person’s agents write only their own. The reason is in the LLM Wiki article.
• Secrets stay out of the memory. Our standard: notes record a reference to a secret, never its value, and agents receive secrets at launch from a dedicated secrets manager, with a separate project per agent boundary.
• Sharing outside the company has its own guard. A part of the vault we exchange with an external partner is checked before every commit, and what decides whether a note can leave is who owns it, not what type of note it is.

A prompt is not a permission: sandbox agents at the OS level

Scopes on the vault tools raise the floor, but an agent with a shell can still read files directly. For agents whose output must pass through a human, two gaps are worth checking before launch: a chat bridge can hand its posting key to the agent’s environment, and an agent runtime can enable a shell regardless of its own tool restrictions.

So for those agents the gate lives at the operating system. The agent runs with no inherited environment, home directories hidden, a read-only filesystem and outbound network denied except for an allowlist. The key lives with a separate service user, and the agent reaches it only through a few narrow tools over a local socket. The agent also runs on a harness that enforces its own tool allowlist. On our WhatsApp CRM agent, every turn ends through one of two tools, “say this” or “nothing to say”, because a model left to end in prose can write its answer to a log nobody reads. The WhatsApp agents article covers those failure modes in detail.

How the parts fit together

A typical day looks like this:

1. An agent on a server notices a problem and sends an alert or drops a proposal.
2. A human reads the proposal. If it is real, a task goes into the register with a link to a note.
3. The fix follows a skill. If no skill exists and the work will repeat, one gets written.
4. If anything destructive is involved, it clears the five gates.
5. If the root cause was a failure recorded as success, the failure standard is checked for a missing rule, and the agent memory gets a short lesson with the reason.

None of these steps depends on a specific model or vendor.

How to start: week one and month one

Week one

1. Create a folder of Markdown files and put it under git the same day.
2. Write a short schema the agents must read first: folder map, note types and where tasks go.
3. Make a task register the only front door, with a link to a note on every row.
4. Write skills for the two or three things you already repeat.
5. Adopt one rule: agents add, humans close.
6. Move every secret out of notes and prompts.

Month one

1. Give each agent a launcher-set identity and a default-deny scope in a file under git.
2. Put agents on servers behind a read-only mirror and add-only proposals.
3. Add a completion stamp and a staleness alert to every monitor.
4. Write your own failure standard from the incidents you have already had.
5. Start a decision register, so a choice revisited next quarter finds its earlier reasoning.
6. Let agents record lessons from their mistakes, each with the reason and how to apply it.

If you are deciding what an AI agent should and should not be allowed to do in your company, the layer above is where that decision lives.

This is the same system we use to build and run the AI agents and automations we deliver to clients. If you want help setting up an AI operating system for your team, talk to us.