I’ve spent the last few months “playing” with agent - yes, I fell for the OpenClaw hype too. Reading documentation, running experiments, trying to wire things together. The question I was asking was: which of these gets me closer to the daemon?
I eventually realized I was asking the wrong question. But getting there required enough failed experiments to understand why.
The agent pitch is compelling on paper. You give a system tools - the ability to search, read, write, call APIs, interact with other services - and it uses them autonomously to complete complex tasks. Add enough intelligence, connect enough services, and you theoretically get something that can act on your behalf across your digital life.
You’ve certainyl heard of OpenClaw, but I wanted something more lightweight and something I could “read” the code of. Nanobot is a serious framework in this space, actively developed, with real capabilities - for the ones interested, have a look at their GitHub it is a very cool project. I’ve read a lot of it, run experiments, poked at the edges of what it can do. And I have almost nothing to show for it - not because it’s broken, but because I can’t find meaningful things to make it do.
That absence of use cases is the data point worth examining.
Almost everything written about personal AI agents assumes a particular kind of digital life. You’re an entrepreneur, or a developer, or someone with fluid access to your own tools: your company’s Slack, your CRM, your codebase, your calendar, your customer data. The agent can reach across all of it. The use cases write themselves.
I’m an IT guy in Corporate. That changes the picture entirely.
My professional digital life is rich - years of documents, communications, processes, institutional knowledge. But I’m not going to connect an experimental agent framework to corporate infrastructure. Not because I couldn’t, but first because I have a job to do and that’s not experimenting with agents, but more important, because I wouldn’t trust such a framework to run on our network and give it access to the data anyway. That puts the most interesting part of my working day off the table.
What’s left is my personal digital life, which is real but more modest. I have a Trilium Notes instance I’ve been using as a personal knowledge manager for about a year - imperfectly, incompletely, but it’s there. I have a Karakeep instance with eight hundred bookmarks, articles I’ve saved because they mattered to me in some way.
These felt like natural starting points. So I tried to connect them. Go MCP…
The theory: give the agent access to my notes and bookmarks, let it build context about my interests and thinking, start developing something like the knowledge layer the daemon needs.
The practice: MCP connections burning through free API tiers in minutes, hitting rate limits before anything useful happened. Results that technically worked but weren’t worth the tokens spent getting there. Then a pivot to n8n as an intermediary with building explicit workflows instead of letting the agent navigate through prompts - which works better but turned out to be manual in all the ways agents are supposed to not be. Even running Claude Code against the n8n instance to automate the workflow building didn’t make the friction disappear. It redistributed it.
None of this is a Nanobot failure. It’s what integration work actually looks like when you’re connecting things that weren’t designed to connect, with data that isn’t quite in the right shape, trying to produce value that isn’t quite defined. The agent is capable. The use case is underspecified. The gap between the two is work I have to do, not work the agent does for me.
This is where I want to introduce a distinction that’s been clarifying my thinking, even though I don’t have it fully resolved.
The agent approach à la OpenClaw is fundamentally bottom-up: you start with a capable toolset, wire it to things, and gradually enrich it with intelligence and knowledge. The bet is that adding enough intelligence to an automation platform eventually produces something worth talking to.
There’s another approach, let’s call it top-down, where you start with a capable assistant and progressively give it tools and context. The intelligence is primary. The automation is added where it genuinely helps.
We all know the top-down approach, we have been running over several years for now, this is Claude progressively enriched with MCP, skills, Code, Cowork, plugins, etc. but also projects and memory. Every conversation I’ve had with Claude over the past year - about the daemon architecture, about my writing, about thinking through problems - has been accumulating something in the quality of the interaction itself, in what I’ve learned to bring to it, in how the back-and-forth has shaped my thinking. That’s closer to the daemon than anything Nanobot produced.
OpenJarvis, a Stanford research project I’ve been reading about seems to be working on a version of the top-down approach, focused on building knowledge representation first, then capability. I haven’t tested it yet, so I’ll stop short of claiming it’s the answer. But the design philosophy feels more aligned with what the daemon actually requires than frameworks that start with automation and ask how smart they can become.
The daemon is not an agent with enough plugins.
An agent is optimized for doing things. The daemon is optimized for knowing you, for building the kind of understanding that makes it genuinely useful to think with, not just a capable system you occasionally direct at tasks. Those aren’t the same target, and the architectures that serve one don’t necessarily serve the other.
The agent use cases I couldn’t find aren’t missing because I haven’t thought hard enough. They’re missing because the daemon isn’t primarily useful for automation. It’s useful for thinking, for the kind of ongoing, accumulating, relationship-based cognitive companionship I’ve been writing about since the beginning of this series. Adding tool-use on top of that might eventually matter. But starting with tool-use and trying to build toward cognitive companionship is probably the wrong direction. I will keep spending time with Nanobot and personal automation but I doubt this is the core of my Daemon.
The bottom-up approach bet is: capable enough automation, plus enough intelligence, eventually becomes something you can think with. My experience suggests that’s not how it works. You don’t arrive at relationship by adding features to a task runner.