I Built an AI Operating System So I Could Keep Building Products
Pillar
AI Leadership
Company
Guiri
Audience
Founder, executive, product leader, design leader, engineering leader, hiring manager
Date
2026
PLAYBOOK BRIEF
Capability
AI operating models, bounded delegation, reliability, product leadership
Overview
Guiri gave me a blunt constraint: one person has to watch product, reliability, feedback, growth, subscriptions, and delivery. I built a digital operations team that can investigate routine work but cannot spend money, access sensitive accounts, or declare itself done without evidence.
Evidence & limits
Evidence: Discord holds the operating queues, Telegram is the founder pager, and Railway routes work through runbooks. Engineering completion requires an artifact, exact commit, checks, an independent verdict, a truthful final state, and a receipt. Trade-offs: I optimise for protected attention, not maximum automation. Strategy, spending, sensitive communication, account access, and meaningful production risk stay with me. Evidence gates slow autonomy, and permissions expand only after a tool earns trust. Limits and failure modes: Agent theatre, noisy alerts, unowned handoffs, self-approved work, repeated failed approaches, false completion, or a monitoring system that can fail silently. What this proves: The 90/10 split is a design target, not a measured result. Some integrations are mature and others remain constrained. The next test is whether more routine work moves without pulling me back into monitoring it.
The dashboard loop
If I have to open Railway, GitHub, Linear, PostHog, Stripe, App Store Connect, and several admin tools to decide whether Guiri is healthy, the automation has failed.
I run Guiri as a team of one. Product strategy, design, engineering, reliability, customer feedback, growth, subscriptions, and content still need attention. I did not want routine monitoring and failed automations to consume the time I needed for the product.
The 90/10 operating model
I designed the system around a 90/10 target. Agents should handle routine, repeatable work. I keep strategy, spending, sensitive communication, account access, and meaningful production risk.
The split is a design target, not a measured result. The practical test is whether the system stays quiet when healthy and brings me a recommendation when a decision genuinely needs me.
Agent roles, authority limits, and runbooks
I turned more than 15 years of product-building experience into runbooks. Before an agent receives work, the runbook defines:
the outcome it owns
the actions it may take
the stop conditions
the evidence required
the point that needs escalation
A COO layer triages work, chooses the runbook, assigns a specialist, checks that work actually started, and asks for an artifact. Hermes filters founder decisions. Engineering agents investigate bounded problems in isolated environments.
Trust is not uniform. One tool, Jules, remains restricted to tiny maintenance tasks because I have not proved it can safely handle more.
If a tool hits a temporary rate limit, the system cools it down instead of burning through the execution budget. If an agent fails, the COO retries within policy, transfers the same tracked work to a fallback, or raises a precise blocker. An assignment does not count unless the work actually starts.
Make the pager hard to reach
Discord is the digital office. Engineering quality, reliability, analytics, growth, revenue, customer feedback, RAG quality, and executive reporting have separate operating queues.
Tracked actions can acknowledge, rerun, snooze, delegate, investigate, approve a rollback, or move work forward. The action updates the underlying system and returns a receipt. A button that only posts another message does not count.
Telegram is the founder pager. TheLittleGuiriBot is reserved for a real production emergency, a founder-only decision, an access or billing blocker, or a verified positive development. Routine reports and synthetic failures stay out.
My test is simple: the message should help me act, not make me anxious.
Define done before the work starts
I do not treat activity as progress. A Linear 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
a permanent execution receipt
The implementation agent cannot approve its own work.
Do not let the system repeat a failed approach
Runs, findings, assignments, attempts, verifications, and lessons are recorded in shared memory. 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 next attempt materially different. One component also checks the heartbeat of another so the monitoring layer does not fail silently.
What the system is for
The system currently coordinates availability, answer quality, pull-request health, analytics, subscriptions, acquisition, feedback, and the health of the automation layer itself. For bounded engineering work, it can investigate, run checks, and open a draft pull request without receiving production credentials.
The goal is not to remove me from Guiri. It is to remove the operational work that keeps me from building the product. When the system needs me, it should arrive with a recommendation rather than an unsorted problem.
