Why does your organization need an AIOS?

Since 14 September 2026 I have run my work through a system I call an AIOS, an operating system for AI agents. As of 3 November 2026 it has completed 1 152 tasks, and 689 of the 1 202 cards on the board came from the agents themselves. This article is about what the system is, what it has given me, what it cost, and what went wrong. At the end I describe what a team would need, and how we can help you get started.

Before I got my AIOS really going, I used to chat with Claude, Copilot or any other coding agent solution. I enabled some skills, typed in some instructions and waited for the response, before going another round. I wanted to present my ideas on a higher level, and keep my intentions between contexts.

What is an agentic operating system?

It is an operating system for agents: one Kanban queue for every type of task, a replaceable “brain” that plans and executes against written goals, results that come with evidence, and a local knowledge base that learns over time. That is the whole definition. The model does the thinking. The operating system keeps order.

I think of it as five services:

• a queue with planning
• context and memory
• storage
• tools and access with limits on what the agent may touch
• insight for the human who owns the work.

The last one is what lets me see what was done, and why.

The parallels to a normal operating system are close. A process is a card on the board, the scheduler is the runner that picks the next card when a slot is free, and RAM is the context window. The file system is the knowledge base, and permissions are the allowlist.

What changed when the agents got a queue?

The biggest change was not speed. It was that I stopped working alongside the AI and started delegating to it. I write a card with a purpose, and one agent turns it into a plan with acceptance criteria and asks me when something is unclear.

Another agent does the work in its own git worktree, in parallel with other cards. A third checks the evidence independently and sends back what does not hold. Then I approve, and the work is deployed or put in effect some other way.

Today the agents help me with ten kinds of work:

1. coding
2. operations and monitoring
3. presentations
4. research and analysis
5. meeting preparations
6. LinkedIn posts
7. blog posts and articles
8. promo videos
9. personal development
10. briefings at fixed times.

Each type has its own definition of done. Code needs a green build and screenshots. Research needs a source with a link and a date on every claim.

The numbers as of 3 November 2026, counted from the board: 1 152 tasks completed since 14 September. 513 cards came from me and 689 from the agents. Of 7 271 acceptance criteria, 7 016 point to a piece of evidence. The agents have run for 614 hours on cards alone, not counting routines.

What this does to my week is simple. I save the demanding work for when I am rested, and do the approvals and judgment calls when I have less energy. In the meantime, things just happen.

What does it cost?

I use the whole weekly quota in my subscription. Converted to API prices, my own estimate from 30 September 2026 was 600 to 1 000 dollars per week. I do not know whether that number says anything about the actual cost of running the models, but it says something about where pricing is heading.

The cache is what makes this possible. As of 3 November 2026 the agents have sent 571 million tokens in and received 108 million out, while 11.2 billion tokens were read from cache. Roughly 95 percent of everything the agents read comes from cache. Only about one token in twenty is new.

I also learned to spend less. In the beginning I ran most of it on Opus 5.5 with high effort, and it burned through tokens fast. On 13 October 2026 I turned the planning step down from max to medium effort, because on max the plan alone cost around 4.90 dollars per card no matter how small the card was, and many were small as the solutions started to settle. I did not notice much loss in quality, and more cards got through on the same quota. I can easily override the model and effort for each card as well.

What went wrong?

Plenty! A retro of the last month (yes, it runs its own retros!), from 3 October to 3 November 2026, counts 1 844 execution runs, of which 1 595 ended well. The verification step ran 1 133 times and passed 981. The rest hit a round limit, a time limit, a crash, or the quota.

The quota was the worst one. On 11 and 12 October the weekly quota was depleted, and the system kept trying anyway. The routine timer started a run every minute for fifteen hours, and 883 runs were rejected in that one stretch. That bug is fixed: the system now reads the reset time from the rejection and waits until then.

Cards also come back. 34 times in the month I sent a card back from Ready for test, and 14 of those were video cards. In several of them a generated clip showed the content of a screen through its back. Classic AI mistake! The QA agents did not see that. I did.

219 cards were blocked at least once in the month, often waiting on a video quota at Gemini, a login, or a change to production that only I may make. The retro still counts 1 280 runs rejected on quota, most of them from that one stretch in October.

And merge conflicts. When several cards change the same files, someone has to resolve the conflict. That is a job I hate, so a separate agent does it now, with the rule that both intentions survive. It ran 55 times last month and resolved all 55.

When something goes wrong, I mostly use AI to solve the issue permanently. I would just explain something like: Can you unblock this card, and change the skills, so that it does not happen again in the future. The issues described here are mostly gone, after this kind of tuning along the way.

Why does this matter for an organization?

Because most organizations are stuck in the middle.

Wharton Human-AI Research and GBK Collective published their fourth annual AI adoption report on 13 October 2026, based on around 1 400 people in large US companies. Two out of three departments say they use AI agents, but fewer than one in five let an agent finish a task without a person approving every step.

The report sorts the departments into four levels, by how much the agent is allowed to do on its own:

1. AI advises. The agent suggests, and a person makes every decision and does the work. That's when you use the chat window and describe a problem you have and get some code or a list of tasks back.
2. AI does the work, a person approves every action. The agent prepares the change, and nothing happens until a person has signed off on it. That's when you sit back and click approve all day.
3. Autonomous, a sample is checked afterwards. The agent finishes the task on its own, and a person looks at some of the results later. That is when you let the agent work in auto mode, and you approve bigger chunks of work, such as a plan ready for execution.
4. Autonomous, with real-time monitoring and guardrails. The agent finishes the task on its own. Automatic monitoring watches it while it works, and written rules say what it may not touch. That's like working as a boss with actual assistants supporting your work and decisions.

Nearly half of all departments sit on step two. It feels like the safe choice: you get the agent's work, and a person still decides. But it is also where you pay for an agent and keep a person busy approving everything it does. The person becomes the bottleneck, and you learn very little about what the agent could handle alone. Brian Smith at GBK calls it the “supervised middle”, where you pay for autonomy and then review every action, so you get no flow from it.

The interesting part is the shape of the curve. The report also counts how many departments at each level have redesigned how they work with AI. That share is highest at both ends of the ladder, and lowest in the middle, though it is a bit curious that the departments with the least AI maturity are among the highest in redesigning processes to incorporate AI. This may be because at level 1, you could have new processes where humans and AI collaborate over a chat window, whereas level 2 is actually just the old process, supported by AI.

The report argues that returns are highest when a redesigned process is implemented, and the best results are seen at level 4.

Getting to level four is what an agentic operating system does! It provides new processes with an AI-first mindset, built around the notion that work is done by agents and controlled, verified and accepted by humans. In my own AIOS, tasks move through a number of states, each with its own guardrails and definitions of done. Every criterion needs evidence, and what I eventually need to decide upon is presented in a concise manner, with screenshots and summaries, with all the details available if I need them. Critical operations, such as changing state in production or handling secrets, are not allowed, but instructions about what I need to do are provided.

Most application features are delivered by the agents fully autonomously. Many are even suggested by my product owner agents, which have knowledge about the products and the target audience. I usually just approve such features from the provided screenshots, and rely on a comprehensive test suite of both unit tests and automated end-to-end tests. Then I ship it, and eventually test it in the application manually. However, bugs and other issues are quite rare after me and the agents have gotten to know each other!

It is funny, but it's the same principle as leading people. You cannot control knowledge work in advance. You can replace checkpoints with trust, visibility, and feedback loops that everyone can see.

What would an agentic operating system for a team need?

The AIOS I run today is built for one user on one machine. That is both its strength and its limit. Everything is local, there is no server to operate, and the whole setup fits in one head. A team would need more.

Several users and roles, so cards can belong to people and approvals can be shared. A server available for all, instead of one personal computer, and isolation between users and customers with separate keys. Visible cost per customer or per team. And integrations with the tools people already use, such as the issue tracker and the chat, instead of a new board to look at.

Much of it already exists in the version I run: a queue with thresholds, instructions written as plain markdown so anyone can read what the agents are told, evidence with independent verification, and a knowledge base that grows with every card.

Although much of my AIOS use is for coding, it can also be used for a lot of other things. I use it for market reports, meeting preparation, research, content ideas, business strategy, stock market monitoring, production of video, infographics and presentations. I wonder if I'll let it buy stuff for me, when the payment solutions for agents become available...

What about the future?

I expect the next year to be about the threshold moving. Not about bigger models, but about more work that agents may own outright, with monitoring instead of approval. The organizations that write down what counts and what done means will move it faster than those that review every step.

At gnxt we build and run our products with AIOS, and we help companies set up something similar, from queue and written goals to agents that deliver with evidence. You can read more at gnxt.eu/aios. Good luck, and I'd be happy to help you get going, either by facilitating workshops to figure out what can be included in your own agentic operating system, or building and running the whole thing. And anything in between. I think it is best to set it up together, and then you can use the operating system to improve itself, adding new features and agents, and contact me whenever needed, if there are things you'd want to discuss, or ask about.