Running a Company on AI Agents. The Useful Number isn't 100%

There was no master plan. I kept pushing Claude Code past what it was for, and eighteen months later, it runs most of my company. The biggest lesson wasn't how far it could go, but learning to stop at 95% and leave the last 5%, that is the judgment, to a human by design.

Aim an agent at a task and, with enough harnessing and context engineering, it gets remarkably far. But there's almost always a last 5% that needs a person; a judgment call, an approval, a decision about what's actually true. I stopped treating that 5% as a failure to automate away and started treating it as the design. Build the system so a human picks up the last 5% cleanly. Right now, that decision is mine; later, it could be someone else’s. That is not a limitation of working with AI. I think it's the point.

This is the honest version of how that system came to be: what worked, what I got wrong, and why I just open-sourced all of it.

It didn't start as a product.

It started with me pushing a tool. I was using Claude Code to ideate and build, and kept handing it work it wasn't really meant for. It kept up, and then it kept getting better; at code first, then research, writing, analysis, operations. So I kept handing it more.

One of the things that fell out of that was a small personal-assistant app. It read my inbox, triaged it, and drafted replies on its own. It also gave me a visual layer over the C-suite of agents I'd already been running: finance, marketing, product, engineering, and sales. None of this was exotic at the time. A lot of people were quietly working on the same shape, even before the wave of agent products that showed up later. I just didn't stop.

What it Became, Mostly Still in the Lab

Over time, the assistant grew into something closer to an operating system for the company. Agents mapped to the functions you'd otherwise hire for, each with its own skills and its own schedule:

• Finance. A CFO agent that can read bank statements across entities, classify transactions, reconcile the books, and knows the edges of its own authority. It once ran a full reconciliation and then refused to mark invoices paid in Stripe, because I had only given it read access. It flagged them for me instead of finding a workaround.
• Engineering. An engineering agent that picks up tasks, reads the codebase, and opens pull requests.
• Sales. A sales agent keeps the pipeline honest, scoring leads, drafting follow-ups, and queuing them for me.
• Content, research, marketing, social, newsletters. Drafting posts, running competitor scans, turning one piece into many, and sending the things that get approved.
• An executive layer that coordinates the rest and ties each agent's work back to a real company priority, so the machine stays aimed instead of just busy.

I want to be honest about what this is and what it isn't. It has run a lot of small jobs over the past few months, but the overwhelming majority have been research, testing, drafting, and review, and not full-scale production. I haven't flipped a switch and let it run the company unattended, and I wouldn't. The early wins are real but modest: code fixes that shipped, a newsletter where every claim was checked against actually-merged pull requests before it went out, drafts that saved me hours. The point was never a dashboard of impressive totals. The point was learning where the 95 ends and the 5 begins.

It Breaks, and it Tells You.

If I only showed you the wins, this would be a brochure. The interesting failures taught me more.

The agents once found a bug in their own machinery, an email warm-up routine whose concurrency lock would, under the wrong timing, zero out its own send count after legitimate sends. One of them isolated it and filed it. Watching the system debug itself is a strange thing.

A monitoring job failed dozens of times in a row because a credential had quietly expired. Credentials expire; that's not the lesson. The lesson is that it said so, in plain language, every single run: "this is blocked, here's the one fix that unblocks everything downstream," instead of dying silently the way a cron job usually does. A system you can run on is one that tells you the truth about its own state. That, again, is the 5% showing up where it belongs.

What I Got Most Wrong was Memory

For a while, my approval queue kept filling up, and I assumed I was the bottleneck, which was too slow to bless the work the agents had finished.

Then I looked closer. Much of what was waiting for me was already done. I had handled it myself, or it had resolved over email, or another part of the system had closed it outside of any single agent's run. The agents had no shared memory of that. Each run started fresh, saw an open task, and left it open. The system was generating work that no longer existed.

The problem wasn't my throughput. It was memory. And remember, this all runs inside Claude Code, where memory management wasn't what it is today. The ecosystem has since converged hard on this, and the memory systems shipping now mirror what a lot of us were hand-rolling a year ago. I was working with a lot of data and context, so memory had to be architected. Thank goodness for hooks. I tried several approaches and landed on one: persistent semantic search over everything the agents had written, a knowledge graph that tracks when facts change, a diary each agent keeps across cycles, and rules that close a task only on real evidence, a sent email, a matching transaction, or a merged PR. The agents stopped asking me to approve things that were already done and started handing me the evidence instead.

The hard part of this work, it turns out, isn't getting one agent to do one task. It's getting a system of agents to agree on what's true right now.

One App Instead of Ten

Somewhere in here, the experience became the problem worth solving. Running all this meant constantly switching: a terminal here to talk to an agent, a file browser there, an editor to read what it wrote, another window to watch a workflow run, one more to check a queue. The work was spread across a dozen tools that didn't know about each other.

So I pulled it into one. Today, it is a single app where I chat with an agent, browse files and folders, open and read a file, run and watch workflows, and check the mail, finance, and sales queues, all in one window, and all of it, aware of itself. It isn't an IDE. It is not an agent harness or a chat client. It's something else, and I don't think I'm the only one who noticed the gap; tools like cmux, terax, and tuicommander are circling the same idea. A new class of apps is forming out of people's own needs, and it's one of the more interesting things happening in software right now.

I called mine Ikenga.

What's actually in it

A quick, honest tour of what's there today:

• Local-first. It's a Tauri 2 desktop app. Data lives on your machine: local database, encrypted secrets vault. Nothing has to leave the device.
• Split panes. A terminal, a chat, and a file or viewer, side by side, with a ⌘K palette to jump anywhere.
• The engine is swappable. Claude Code is the one that is fully wired today. Gemini and Codex are pluggable adapters, still gated on their CLIs, the point is that the engine is an adapter, not a hard dependency.
• Composable packages, hot-mounted. Every function is a package you can drop in and reload without restarting the app.
• Mini-apps. Sessions, chat, scratchpads, a todo/tasks board, and the Studio all ship. A few of the business apps (sales, outbound, email) are still placeholders, and I would rather say so than pretend.
• Self-contained artifacts. An agent can write a dashboard as a single HTML file that runs in any browser and lights up with live data inside the workspace.
• Scheduled routines. Cron-style jobs, defined per package, for the work that should run without me.
• A control bridge. Iyke lets any MCP client drive the running app; read the screen, click, type, pull a screenshot, which is how an agent operates the workspace itself.

The plan Kept Changing

This is the part I find most honest to admit: I changed my mind about what this should be, more than once.

First, I thought I could build a SaaS product out of it. Plenty of companies sell individual pieces of this, and combinations of them, a real market. Then I leaned toward open-sourcing parts of it, open-core style, keeping the good bits back. There's good company there, too; projects like Paperclip and the Hermes line have shown there is a real appetite for open agent infrastructure.

But while I was building, the capabilities outran the plan. What started as essentially a Claude Code wrapper became an AI workspace that builds its own small apps; where an agent can author a working, refreshable dashboard about as easily as it writes a paragraph. The format for that was itself built by a team of agents working in parallel: one writing the skill, one the schema, one validating, one reviewing. Once it could do that, holding parts back, stopped making sense to me.

So I'm open-sourcing all of it, the whole thing. The shell, the kernel, the package format, the engine adapters, the design system, the lot. I would rather see what people build with it than guess at what to charge them for.

What's open

Ikenga is on GitHub now, fully open. You can take the shell and the package kernel and build your own workspace for whatever you run: a law practice, an accounting firm, a research lab, a media company, a one-person stack of side projects. If you'd rather not run it yourself, I'll do cloud and enterprise deployments and the occasional deep custom build. But the code isn't the moat. What I learned running it is.

And some of it works without Ikenga at all. A few pieces are plain Claude Code skills, they install into any agent setup that supports the skill format (Claude Code, Cursor, Codex, Gemini CLI) and don't need the workspace running:

• groundwork — npx skills add royalti-io/groundwork — turns a vague "plan this" into a real research → design → plan → build folder, instead of one giant prompt.
• ikenga-artifact-builder — npx skills add royalti-io/ikenga-artifact-builder — have an agent author a single-file interactive dashboard or view that runs in any browser (and lights up with live data if you do run Ikenga).
• royalti-api-skill — npx skills add royalti-io/royalti-api-skill — the full Royalti API reference, dropped straight into your coding agent.

Take those even if you never touch the workspace. That's the point of open.

I have started eating my own cooking on a new use case: an AI-assisted video production studio built into the workspace; a storyboard canvas where each frame is a real artifact, with an agent you can talk to while you compose. I'll be beta-testing it with a few people soon.

I didn't set out to build a platform. I set out to stop drowning in the work of running my own company, and to find out how far the tools could go if I kept pushing. Eighteen months later, I'm more interested than when I started, because every week someone, sometimes the system itself, does something with this that I didn't expect, and the ceiling keeps moving.

If you build something on it, tell me. That's the whole reason it's open.

• Code: github.com/Royalti-io/ikenga (packages at github.com/Royalti-io/ikenga-pkgs)
• A proper home is going up at ikenga.dev
• The longer, more strategic version of this is coming next.