I Built an AI Operating System So I Could Keep Building Products

The operating problem

I run Guiri as a team of one. That does not mean I only have one job. On any given day, I am responsible for product strategy, design, engineering, reliability, customer feedback, growth, subscriptions, content, and everything else required to keep the company moving.

I did not want to spend my time checking dashboards, chasing failed automations, reviewing routine maintenance, or working out which alert actually mattered. I wanted to spend my time building the product.

The principle

I did not optimise for the maximum number of agents or automations. I optimised for protecting my attention. The system is designed around a 90/10 operating model: agents should handle routine, repeatable work; I should stay focused on the work that requires strategy, judgment, spending, sensitive communication, account access, or meaningful production risk.

The 90/10 split is the design target, not a measured result. The practical test is simpler: the system should stay quiet when everything is healthy. When it contacts me (my Hermes agent), it should tell me what happened, why it matters, what it recommends, and what decision only I can make.

1. Decide what only you can do

I started by separating founder-only work from work that could move safely without me. Strategy, spending, sensitive communication, account access, and meaningful production risk stay with me. Routine investigation, triage, maintenance, checks, drafting, and low-risk engineering work can be delegated when the scope and authority are clear.

2. Design a company, not a collection of bots

I did not want a theatre of agents posting status updates to each other. I designed the system to resemble a real technology company. Each agent has a role, a defined level of authority, and an outcome it owns.

A COO layer triages work, assigns owners, detects stalled handoffs, and demands proof. Reliability agents watch production. Engineering agents (powered by Droid) investigate bounded problems. An independent reviewer checks work before it can be accepted. Tools that have not earned trust remain restricted to small maintenance tasks.

3. Encode judgment before delegating

The most important part of the system is not the models. It is the operating judgment behind them. I turned what I have learned over more than 15 years of building products into runbooks.

The runbooks define which signals indicate a real problem, what an agent can handle, what needs my approval, how much evidence is required, which checks must pass, when to retry or stop, what done means, and what the system should remember. The agents do not invent company policy from scratch. They work inside a framework shaped by how I have learned to build and operate products.

4. Keep the healthy system quiet

Discord is the digital office. Engineering quality, reliability, analytics, growth, revenue, customer feedback, RAG quality, and executive reporting each have an operating surface. Tracked actions change the underlying state and return a receipt. A button that only posts another message does not count.

Telegram is the founder pager. It is reserved for real emergencies, founder-only decisions, access or billing blockers, and verified positive developments. My rule is simple: a Telegram message should help me act, not make me anxious.

5. Define completion around evidence

I do not treat activity as progress. A ticket is not completed work. An agent saying done is not proof. A draft pull request is not a production outcome.

For engineering work, completion requires a real artifact, the exact commit that was reviewed, relevant checks, an independent verdict, a merge or truthful final state, and a permanent execution receipt. The implementation agent cannot approve its own work.

6. Give the system memory

Runs, findings, assignments, attempts, verifications, and lessons are recorded in a shared learning layer. Before an agent returns to a recurring problem, it receives the relevant history. If it wants to retry a failed approach, it must explain what new evidence makes the new attempt materially different.

Evidence in practice

The system currently coordinates product availability, answer quality, pull-request health, analytics, subscriptions, acquisition, customer feedback, social readiness, and the health of the automation layer itself. For bounded engineering work, an agent can investigate in an isolated environment, run checks, and open a draft pull request without receiving production credentials.

This is operating evidence rather than a time-saved metric. The proof is in the roles, runbooks, authority limits, audit trails, checks, and working integrations. I am not claiming that the 90/10 target has already been measured or reached.

What this changes

The agents can investigate, triage, draft, test, and report on low-risk parts of the company while I stay focused on product direction and building. When the system needs me, it should arrive with a recommendation rather than an unsorted problem.

The goal is not to remove me from Guiri. It is to remove the operational work that prevents me from doing the parts of Guiri where I create the most value.

What is still being proven

This operating system is still evolving. Different agents have different levels of trust. Some integrations are mature; others are intentionally constrained. I keep updating the runbooks as new failure modes appear. The next proof is not more agents. It is whether the company can handle more routine work without creating more review debt or pulling my attention back into the machinery.