Agentic OS: the agent operating system for a 15–50-person company

"Agent operating system" means two different things. Which one do you need?

Search the phrase and the first result is AIOS, a research project that embeds a language model into an OS kernel. Next to it sit vendor guides from Dust, Slack, Make and MindStudio; Dust's definition is a "coordination layer" for agents. Then a Reddit thread where someone asks, in plain words, how to set this up without technical knowledge, and nobody answers them in plain words.

If you came for the runtime, our platform comparison covers it. The rest of this page is the operating model.

The client on this page never learned which runtime we used. They didn't need to.

What we installed for a 15-person IT services company

They came to us wanting agents for support, marketing, sales and admin. They had tried already. What they had was disparate patches: a scraper here, a chatbot there, a cron job somebody set up and forgot. They needed one system, and they needed it to stop costing them attention.

Eight agents went in, and every one answers from the same knowledge base. The owner column below is exactly what we are cleared to say; two rows we are not.

Notice what is missing. No support agent replying to clients. No sales-call agent. Both were on the wish-list. Both failed the admission test further down, and the company is better for it: support staff now query the archivist for the answer and write the reply themselves, which is faster and doesn't put a bot between them and a paying client.

By day three, two things were visible. The prospecting list and its enrichment ran end to end without a human, so the sales lead got a qualified list in the channel instead of building one. And the contract tracker surfaced renewals and overdue items people had forgotten about.

Why we refused to give every employee their own agent

The owner's original ask was an individual agent for each of the 15 people, and each of those agents running its own sub-agents. It is an interesting idea. It is also completely unnecessary at this size, and it is token clutter. Fifteen copies of the same context. Fifteen schedules burning tokens while nobody is asking anything.

We have watched this design die twice. A 20–50-person company gave every employee an always-on agent with its own token budget; spend reached $3,000–5,000 a month, mostly heartbeats, polling and cron loops with nobody at the keyboard, and they abandoned it in about two months. An IT company bought a Mac Mini and a personal agent setup for every major employee; costs ballooned, no ROI appeared, and it was shut down.

What we built instead: agents that work per department off a common knowledge base, supplemented by a personal agent of each person's preference. Anyone who didn't have one got a recommended setup. The whole company now runs on $300–1,000 a month in tokens and tool APIs.

The best current writing on AI-native companies agrees with the shape. Jacob Posel: "Most companies are trying to harness AI before they have built a harness for it." Kevin Simback argues for shared skills over personal setups. What none of them supply is the price of getting it wrong, because they haven't billed for cleaning it up.

Shared departmental agents beat one-agent-per-person. Twice we watched the other design fail, and once we replaced it.

Build the interaction point first. The agents come second.

Luke Pierce sequences it data, then workflows, then agents. Jacob Posel goes memory, connections, permissions. Neither builds the channel first, and nothing else we have read does either. We build the place where the humans and the agents meet on the same plane, across whatever channels the team already lives in. For this company that was Slack for the team, with a channel per department and direct messages to personal agents, and WhatsApp for the owner.

It gets the whole thing going. An agent that lives in a dashboard nobody opens is a report nobody reads. An agent that posts the qualified list into #sales at 8am is a colleague. The team learns to talk to it because it is already where they are talking.

The runtime underneath was our decision, task by task: a managed agent host for the shared memory and skills, custom code on the Claude and OpenAI APIs where judgment sat in the loop, no-code plumbing between tools. The client never needed to know which was which. That is the point.

An agent nobody can talk to where they already work is a report nobody reads.

Who manages each agent? The rule we installed after nobody did.

Before we arrived, nobody owned the agents. We found out how that ends during the audit, not from the client. Their SEO and analytics setup was re-pulling keyword rankings on a cron somebody had set without thinking about it, and every other patch had its own schedule. Nobody was reading the output. The cost wasn't dollars, it was people's time wading through repetitive reports, and nobody had noticed because nobody was responsible for noticing.

Three rules went in, and they now go into every install:

1. Every scheduled job has a named human owner. No cron without a person accountable for what it produces. The sales lead owns lead generation, prospecting and enrichment. The marketing lead owns SEO and analytics. The owner keeps the skills updater and the final say on budgets.
2. Every agent has a budget cap with an alert. A hard monthly ceiling per agent, so a runaway loop is a notification, not an invoice.
3. The cheapest model that clears the bar, per task. Classification and extraction on small models; drafting and decisions on frontier ones. On a dental clinic burning millions of tokens a day, this plus cron culling cut token cost by more than 80%.

What an owner actually does with their agent in a normal week is short: read what came back, fix what's off, approve what goes out, and tell the skills updater when a process changed. The 65-year-old lawyer we set up in Minnesota, non-technical, small practice, got more out of his agents than any founder we have worked with, for one reason: he already knew how to manage people.

An agent without a named human owner is a cost center with a schedule.

What agents may do without asking

We grade approval by reversibility, not importance. Reversible actions (draft, file, tag, enrich, report) run on their own. Consequential or irreversible ones (send to a client, change a contract record, pay anything) wait for the owner. Ashwin Gopinath describes the same gate for agent actions: if it is consequential or irreversible, it asks. Eric Siu runs his agency on green, amber and red bands. The band matters less than the fact that someone drew it.

Credentials get scoped per user and per department from day one. We learned that on a team deployment where a shared instance quietly became a shared-secrets problem: everyone who could talk to the agent could reach everything the agent could reach. The fix was isolation per user and department, and it is now the default, not an add-on.

Reversible actions run. Irreversible ones ask. Credentials are scoped before the first agent goes live.

What every agent answers from: the knowledge layer underneath

The archivist is the agent the other seven depend on. It is also the one that takes the longest to get right, because the company's real answers were not in the wiki. Across our second-brain installs they lived in Slack and WhatsApp threads, in two or three senior people's heads, and in documents that contradicted each other.

Slite asked 149 teams whether they had a company brain. Seventeen percent had one that works; in their words, "the rest have a wiki with a chat box on top." PostHog's rule for their own semantic layer is the one we enforce: "Nothing an agent touches is ever canonical on its own." Agents propose. A human promotes.

This is why we sell the Company Second Brain as its own build, and why we sequence it before the Agentic OS whenever the answers are not written down yet. Capture the tribal knowledge, fix ownership and versioning, then connect agents to it. Luke Pierce's line for the other order: "fragmented data fed into AI generates polished mistakes at scale."

Agents propose. A human promotes. Nothing becomes canonical on its own.

What an agentic OS costs to run, with a real number

Two lines. Build and run. Our builds start from $8,000 fixed, and the $1,500 audit that precedes them is credited in full. The run line is the one nobody publishes, so here it is: the 15-person company on this page runs on $300–1,000 a month in tokens and tool APIs after the shared-agent redesign.

Three things move that number, in order of damage:

• Idle loops. Heartbeats, polling, memory refresh and cron jobs running with nobody asking. This is what took the per-employee design to $3,000–5,000 a month. Run on a trigger or on a schedule a human chose, never on a default.
• Model routing. The best model on every task, including menial ones, was one of three failure points in the dental clinic rescue. Mapping each task to the cheapest model that clears its quality bar was one of four changes that cut that clinic's token cost by more than 80%.
• Paid data APIs. Enrichment and prospecting agents call services that bill per lookup. Cap them per agent and watch the alert.

A bad month looks like this: someone adds a scheduled job without an owner, it runs hourly against a paid API, and the cap alert is the only reason you hear about it on day two instead of day thirty.

How the rollout actually goes, and what "training the team" means

The owner and one lead used the system first. The rest of the team came on two to four weeks later, once the interaction point and the shared agents were stable. That order is not optional. At a tech company whose sales head was never convinced, the entire sales team rejected the transformation: no training, generic inputs, generic outputs, and trust died in the first week.

Training, concretely, was three things. Live sessions while building, so the team sat in as their agents were configured and saw the first outputs land. A written playbook per department: what the agent does, how to ask it, how to review it. And office hours in a shared channel instead of a course. Expect roughly 30% of staff to be active users at three months; that is success, and it only happens if the executives go first.

How we knew it had stuck:

Usage stayed up after we left. Nobody from Cognio was prompting anyone to use anything.

What breaks after go-live

• A process changes and nobody tells the agent. This is why the skills updater exists and why the owner holds it. When the sales lead changes the qualification rule, the prospecting playbook has to change the same day.
• The manager stops reviewing. An agent whose output nobody reads drifts, and the drift is invisible until a client sees it. The weekly review is the job.
• A schedule nobody set. The SEO cron above. Any patch that survives from before the install will have one.
• The shadow spreadsheet. Pierce's term for the old tracker someone keeps as insurance. If it is still alive at day 30, adoption failed in that department and you should ask why before adding agents.
• Resistance. On one engagement some of the team were very resistant to the idea and made learning an uphill task. You can install around resistance for a while. You cannot install through it.

Everything on this list is a missing owner wearing a different mask.

Who should not build an agentic OS

We have turned this work down, and these are the reasons:

• You need two or three automations, not an operating system. Build them in n8n, Make or Zapier with one motivated ops person. An OS on top of three workflows is overkill, and we told one company exactly that.
• It is being done to the team, not with them. If the people who will own the agents are not in the room for week one, adoption dies in month two and the install was a waste. We do not take these.
• Nothing is written down. No SOPs means nothing to install on. Start with the SOP generator, or with a Second Brain build that extracts the process first.
• You are one person. The one-person setups that Zephyr and others describe are a different product, four parts: a folder, a brief, connectors, routines. Good ones exist. They are not what a 15-person team needs, and a 15-person team pretending to be fifteen solo operators is the per-employee mistake wearing a different coat.

If you need three automations, buy three automations. We will tell you so on the call.

Build it yourself, no-code it, or hire someone: an honest split

The audit is $1,500 whichever route it recommends, and we have written no-build verdicts. That is the position this table is written from.

What the first six weeks look like

1. Week 1: consolidate and connect. Sit with the team, consolidate every workflow and process, run the three-part test on each, build the interaction point, stand up the first shared agents. Visible output by day three.
2. Weeks 2–3: knowledge and owners. Capture what lives in heads and threads into the archivist. Name an owner, a budget and an approval band for every agent. Owner and one lead use it daily.
3. Weeks 3–4: first department. Sales or ops comes on with its playbook and live sessions. Personal agents for whoever wants one.
4. Weeks 5–6: the rest, and the cull. Remaining departments. Kill every schedule without an owner. Hand over the skills updater. Then we leave and watch whether usage holds.

That is the shape, not a promise. A company with no written SOPs spends its first two weeks writing them.

Frequently asked questions

Related reading

• The AI operating model for a 15–50-person company — the company-level layer above this page: who owns what, whose job shifts, no Chief AI Officer.
• Nine AI agents we have actually deployed — the roster above, in other companies.
• The company second brain — the knowledge layer, in depth.
• What AI agents cost to build and run — the full cost breakdown.
• AI agent platforms, compared — the runtime meaning of the phrase.
• Why AI pilots fail — the dental clinic, the Mac Minis and the sales team, in full.