What is an agent operating system?

The first wave of AI coding tools put a single assistant inside your editor. That helps you type faster, but the work still lives in your head and the agent forgets everything the moment the window closes. An agent operating system flips the model: the work is the durable object, and agents are workers that attach to it, governed by the same policies and visibility rules a real engineering org runs on.

Why a single AI agent isn't enough

One chat agent is stateless, unsupervised, and invisible to your team. There's no record of what it changed, why, or whether it was allowed to. As soon as you want more than one task running — or want to trust the output without re-reading every line — you need structure around the agent, not just a better agent.

• Durability — work and its history outlive any single session.
• Governance — agents operate under explicit policy: which repos, which paths, what risk tier, when a human must approve.
• Reviewability — every run yields an evidence pack so review is fast and trustworthy.
• Memory — lessons from past runs feed the next one.

The building blocks: a work graph

An agent OS models engineering work as a connected graph of durable objects rather than a transcript. In Loopy these are:

Object	What it is
Ticket	A unit of work — the atom of the workflow. Assignable to a human or an agent.
Agent	A governed, reusable worker with a kind (code, test, security…) and an inline policy.
Trigger	Binds work to an agent so it "just keeps going" — on assignment, status, schedule, or webhook.
Run	One execution of an agent against a ticket, streamed live.
Policy	Allowed repos, denied paths, risk tier, and approval gates that constrain a run.
Evidence pack	The reviewable artifact a run produces: plan, files touched, tests, risks, open questions.
Mission	A company-wide objective that fans out into many tickets across repos.
Memory	Lessons learned, compressed and recalled on the next relevant run.

The agentic loop

Loopy's name comes from its core workflow: an agentic loop. Each turn a planner sizes the work, routes it to a coding agent, runs quality checks, and feeds the result back in — looping until the ticket is actually shippable. That continuous agentic looping is what lets a fleet make real progress unattended, instead of an agentic coding tool that stops after a single suggestion.

How work gets routed to agents

When a ticket lands, the OS decides — explainably — whether to hand it to an agent already looping on that repo or to spin up a dedicated run. A small change is appended to a running loop; a big task gets its own agent so it isn't starved behind smaller work. That sizing decision, plus failover when an agent hits a usage limit, is what makes the fleet feel like a team rather than a single bot.

Agent OS vs. AI IDE vs. chatbot

	Chatbot	AI IDE	Agent OS
Unit of value	A reply	An edit	A shipped ticket
State	Ephemeral	Per-session	Durable work graph
Concurrency	One thread	One developer	A fleet of agents
Governance	None	Minimal	Policy + approvals
Trust	Re-read everything	Diff review	Evidence packs

How Loopy implements it — locally

Loopy is a local-first agent operating system. It runs on your machine with your own API keys, drives 43 coding-agent CLIs (Codex, Claude Code, Cursor, Gemini, and more), and stores its work graph in a local SQLite database. Agents research with Tavily and Firecrawl, remember with Mem0, and ship through GitHub, Linear, and Gmail via Composio — and every run ends in a verifiable ship receipt. Nothing is uploaded to a hosted Loopy service.