Every few months somebody shows me a new AI agent demo and says "this changes everything." And every few months I watch that same agent fall apart the moment it touches a real system. It forgets what it was doing. It gets permissions it shouldn't have. It runs two tasks that step on each other. Nobody can tell what it actually did.
That gap, between the demo and the real world, is why I'm building Karnelian. It's a kernel for AI agents. Not another agent, not another chatbot, but the layer underneath them that decides who gets to run, what they're allowed to touch and what gets written down.
Why the name
A carnelian is a red-orange gemstone. People have carved seals out of it for thousands of years, because it's hard, it holds detail and it was used to sign and protect important things. That felt right. A kernel's job is to be the hard, trusted center that everything else depends on. I swapped the C for a K because kernel, and because I like the way it looks.
The problem nobody wants to own
When I started working with early AI in 2019, on projects like ARCQ and Fynda, the models were the bottleneck. They just weren't good enough. Today the models are incredible. The bottleneck has moved. Now it's everything around the model.
Think about what an operating system does for normal programs. It schedules them so they share the CPU fairly. It gives each one its own memory so they can't corrupt each other. It controls what files and devices they can touch. It keeps logs. Programs don't have to think about any of that, because the kernel handles it.
AI agents today have none of that. Every team rebuilds it badly, from scratch, inside their own app. I've done it myself on client work more than once, and every time I thought: this should be one solid piece of infrastructure, not a pile of glue code.
What Karnelian actually does
Here's the short version of the design.
- ✦Sandboxes. Every agent runs in its own isolated space. It can't see another agent's memory or files unless it's explicitly given access.
- ✦Capabilities, not trust. Instead of giving an agent a master API key and hoping for the best, Karnelian hands out narrow, expiring permissions. Read this folder. Send email to this one address. Spend up to this much. Nothing more.
- ✦Scheduling. When ten agents want to do things at once, something has to decide the order, handle retries and stop one runaway task from eating the whole budget.
- ✦A real audit trail. Every action an agent takes is written down in a way a human can actually read later. What it was asked, what it decided, what it touched and what came back.
- ✦Memory that belongs to someone. Agent memory is stored like data in a proper system, with an owner and rules, not dumped in a giant prompt.
None of these ideas are new. That's kind of the point. Operating systems solved these problems decades ago. I'm taking those proven ideas and applying them to a new kind of program.
Why I think this matters
The thing that scares me about AI agents isn't that they'll be too smart. It's that they'll be given too much access by people in a hurry, and something quiet and expensive will go wrong. A wrong refund, a deleted record, a private file sent to the wrong person.
I've spent years in logistics, payments and multi-tenant SaaS. In all of those worlds, the systems that survive are the ones built with boundaries from day one. You don't bolt security on later. You design it into the foundation. Karnelian is me trying to give agents a foundation like that before the industry learns the lesson the hard way.
From mess to stack
Most agent setups I see look like a tangle. A script calls a model, which calls a tool, which calls another script, with secrets in environment variables and logs scattered across five services. It works until it doesn't, and when it breaks nobody knows where to look.
The goal is to turn that tangle into a clean stack. Agents on top. Karnelian in the middle. Your real systems, like databases, email and payments, at the bottom, only reachable through the kernel. One place to set rules. One place to look when something goes wrong.
What's hard about it
I'll be honest: this is the hardest thing I've ever tried to build. A few things keep me up at night.
Speed. Every layer you add costs time. If Karnelian makes agents noticeably slower, nobody will use it, no matter how safe it is. So performance isn't a nice-to-have. It's a requirement.
Simplicity. Security tools have a habit of becoming so complicated that people turn them off. I want the default to be safe and the setup to be boring. If it takes more than a few minutes to get going, I've failed.
Models change constantly. Whatever I build has to work with models that don't exist yet. That means staying out of the model's business and focusing on the parts that don't change: permissions, scheduling, logging and memory.
Where it's at
Karnelian is in active development. I'm building it through Kordspace, using the same process I use for client work: small pieces, real use, constant feedback. I'm testing it on my own projects first, including the tooling behind RamQuest and Fable Shrine, because I'd rather find the rough edges myself than hand them to someone else.
I'm not going to throw out fake numbers or promise a launch date I can't keep. When there's something people can try, I'll write about it here and on Substack.
A day in the life of an agent on Karnelian
Here's what I picture. A small business sets up an agent to handle supplier invoices. On Karnelian, that agent gets its own sandbox and exactly three permissions: read the invoices inbox, look up suppliers in the accounting system, and draft payments up to a set amount for a human to approve.
The agent works through the morning's invoices. It flags one that doesn't match a purchase order and leaves a clear note. It drafts the rest. When the owner checks in, they don't see a wall of model output. They see a short, readable log: what came in, what the agent decided, why, and what's waiting for approval.
If the agent ever tries to do something outside those three permissions, like emailing a random address or touching payroll, the kernel simply says no and writes it down. Nothing dramatic. No breach. Just a boundary doing its job. That's the boring, reliable experience I'm aiming for.
The takeaway
The future of AI isn't just smarter agents. It's agents we can actually trust with real work.
Trust doesn't come from a clever prompt. It comes from boundaries, records and rules, the same boring foundations that made every other kind of software safe to use. That's what Karnelian is for. If you're building with agents and you've felt that gap between the demo and reality, I'd love to hear what's broken for you. Hit the contact page and tell me.