Lanius: AI Agents Need an OS, Not a Bigger Brain
I built lanius, and I really want to show it to you, but first I need to explain why I think it’s necessary.
We’re headed into a new phase of AI where pushing the frontier involves scaling down the amount of compute. A couple years ago we scaled up model sizes, and then we scaled up how much time we spent thinking. The shift into agency exploded the amount of compute required, but we’re getting ever so much more done.
But there’s things happening:
- Claude code subagents and then dynamic workflows — slicing off chunks of work to be handled separately.
- GPT-5.6 is launching with a ultra mode — a single API call that looks like a single model but is actually many models orchestrated together to collectively solve a problem.
- Sakana.ai’s Fugu — claimed “Fable-level performance” using a mixture of smaller open and closed model, orchestrated similar to GPT’s ultra mode.
In my own coding workflow, I’ve found that I can use Claude Fable to work with Opus to plan, which in turn dispatches to Sonnet to implement, and then Opus again to verify the work. Weirdly, it dramatically cuts down costs. I almost never run out of credits while I also still experience all the best things about Fable.
All of these things have something in common. They match the right-sized LLM to the right problem.
Right-sizing to the problem
There’s this concept, Ashby’s Law, that essentially says that a problem’s solution has to be at least as complex as the problem itself.
When Ashby’s Law is broken, systems start to also feel “broken”. Like when you call into a tech support hotline and the agent isn’t allowed to go off-script so you have to idly say things like, “yep, it’s plugged in. Yep, it’s turned on” in the face of ever-growing frustration.
What we’re experiencing is the other side of that. LLMs were such good problem absorbers that we threw them at
everything. E.g. in the OpenClaw docs they suggest setting up a HEARTBEAT.md file to do things
like check your email every 30 minutes.
Holy god in heaven dost thou ACTUALLY need a whole ass LLM just to realize there’s no new emails??
A more Ashby-pilled approach is to have the agent write a script to check the email inbox, and then send a message to the agent if there’s new email. Or better yet, send the message to a tiny LLM who can triage the email based on some policy (“eh, emails from Jack can wait a day or two, no sweat”) before forwarding it on to the agent who you actually trust to respond. Match the problem.
Right-sizing to the problem is going to involve a heck of a lot of moving parts.
Some are just scripts that an agent can call. Others are scripts that call the agent. Or big Fable-sized agents orchestrating a small army of local LLMs to continuously monitor a situation. Or a local coding agent consulting Fable on a problem that it’s out of its depth on. A lot of it needs to be very dynamic and temporary, coming into and out of existence as needed. Similar to how Claude’s Dynamic Workflows are scripts written in-the-moment by an orchestrating agent.
Scaling up the impact
Dwarkesh found that we’re about 4 orders of magnitude off from the level of hardware to scale today’s agent approach to the entirety of society. Yet we’re already experiencing growing pains, while we still need to 1000x to have the level of impact we think we’ll have. Clearly we need a new approach.
Lanius tackles this by being an agent harness that looks more like an operating system. You can create agents directly on lanius that look a lot like OpenClaw agents, but you can also open Claude Code inside lanius and get all the same benefits.
The core shape is everything is a message.
As an example, messaging between agents, as core as it seems like it is, is just a package consisting of skills, computed memory blocks (notify new messages) and daemon scripts (an MQTT client). Lanius is absolutely built for extension, right down to the core.
Is it an OS? Probably not. It’s closer to a control plane like Kubernetes. But where Kubernetes orchestrates containers, lanius provides a messaging layer that allows agents to orchestrate themselves. Lanius is that missing machinery that, if we’re going to be serious about scaling up impact by scaling down agents to right-sized problems, well we’re going to need a whole lot of whatever lanius is. Messaging and conflict avoidance deeply embedded.
Scaling out
As a messaging-forward AI platform, lanius seamlessly ties together any system in your digital life. We haven’t yet built all the integrations. We also don’t need to because lanius is extensible to the core.
Skills alone are inadequate for interoperability, because any action has to be initiated by an LLM. That’s not Ashby-pilled enough for me. In order to scale down compute, we need actions to be able to start from outside an LLM. Lots of messaging sources, pollers polling websites, websockets listening for events, etc. All coalescing under one single umbrella: the MQTT broker. Messaging at the core.
Interaction models are another version of this.
The latest GPT-Live announcement makes the split explicit: keep a fast conversational model in the loop, then delegate harder work to a deeper model in the background. That feels exactly right to me. It will not scale to make every live model as smart as Sol or Fable. At some point, it needs to borrow intelligence from a worker that is better suited to the job.
When the last realtime GPT came out, I made a web app that hooked it up to Claude Code so my daughter could speak games into existence. The realtime model did not write code. It translated her intent into messages for the coding agent, which was specialized for the actual work.
Scaled down to purpose.
MQTT is an Internet of Things (IoT) protocol. The better AI gets, the more corners of my life I want to include it ambiently. The IoT tie-in was honestly incidental, but once the idea entered the picture, it quickly felt very natural. It’s very nice to disconnect from screens. (I’m firmly against putting coding AI on my phone because it bleeds into my personal life too much)
How I’ve been using lanius
I’ve been dogfooding lanius while building it for the last few weeks. I’ve developed a workflow where I use Claude Fable to replace me — Opus develops plans while Fable drives it. And then Fable dispatches Sonnet, Opus, GPT-5.5, or GLM-5.2 for implementation and verification.
When I’m writing code this way, Fable can take on whole sections of the backlog, working for 5-10 hours at a time. I don’t review the code, Fable does sprint demos and shows me what was produced (okay fine, it’s a review).
Meanwhile, that’s a very long time between interactions. I don’t want to disturb Fable, so I’ll open up another Claude, Codex or opencode through lanius and tackle some unrelated aspect. Early on, before lanius was fully developed, this would confuse Fable and it would stop its work short of being done. But now, it introspects what the other agents are doing and even figures out how done their tasks are, sometimes picking up and finishing their work.
How you can use lanius
Initially, lanius was going to be a replacement for open-strix, a stateful agent harness in the same vein as OpenClaw or Hermes Agent. I think it absolutely still makes sense to use it that way. Or you can get Hermes Agent running inside lanius, alongside your Claude Code sessions. (This doesn’t work OOTB right now though)
Some other things to try:
- Funnels — scan noisy feeds, then progressively escalate only the interesting stuff.
- Shared memory — let agents remember facts without trapping the memory inside one agent.
- Custom context — give one scaled-down agent exactly the KB files it needs.
- Live status — inject Slack, Jira, inbox, or repo state directly into an agent’s prompt.
- Ambient search — keep associative memory running beside the main agent.
The cool part is you can start Claude Code through lanius without doing any of this, and just add different features progressively as you want. And yeah, maybe revisit your old IoT hack projects and see if they make more sense with an MQTT broker and an ambient subagent.
What next?
Honestly, my kids have been stealing snacks out of the pantry and it’s getting out of hand. I was going to setup a camera with a local VLM to detect the theft and have the robot yell at them in my voice. But again, the Ashby-pilled version has a lot of deterministic pre-processing to filter out frames that don’t need a VLM. God this all smells like IoT.
Meanwhile my local VLM is sitting there idle. I guess I could have it aggressively scan for potentially interesting news? I mean, in the time gaps when it’s not stalking my kids. Obviously lanius is going to pause the news gathering to process to urgently yell at my kids, that’s important. That means two or more threads sharing a GPU, working toward the common goal of producing good stuff that I want.
That’s cost management, and it’s going to be critical. Start thinking about agent workloads in fixed budgets with line items in dollars. Then just change up the Ashby-pilled tasks to maximize the value you get from the system.
But for now, go install it! It’s just
cargo install lanius
And then keep this running in a terminal or systemd:
lanius serve
You can chat with it and configure it in the web UI, or launch Claude Code (lanius code claude),
Codex (lanius code codex). When you start them through lanius, Claude can suddenly subagent to Codex and
vice versa. And if you launch a second agent on the side, they can negotiate and figure out what each other are
doing without using you as a substrate (tiring).
I’m excited to see what you do!