Two Ideas, One Week: The Convergence That Drove Me to Build an Agentic OS
I’ve been using Obsidian for note-taking for a while. I’ve built out a personal knowledge management system (PKM) for journaling, project management, and note taking, and I’ve recently started using Obsidian Web Clipper to pull in articles and sources for future reference. So when a wave of YouTube content appeared in April 2026 about combining Claude with Obsidian to build an Agentic Operating System, I paid attention. It was the first time I’d seen a framework built around a tool I already use every day — pointed at something in AI I genuinely wanted to understand.
The same week, Andrej Karpathy published an idea for building a persistent wiki using an LLM — not RAG, where you upload files and the model re-derives answers from scratch each time, but an incrementally built, maintained knowledge base. This approach also used Obsidian as the local home for that knowledge. Ingest a source, update the wiki. Ask a question, file the answer back in. The knowledge compounds rather than evaporating.
Two ideas, same week, both making the same underlying argument: the work worth doing is in the files, not the tools. Own your system. Rent the AI.
That convergence is why I decided to build my own Agentic OS. The reason has a longer backstory.
The two benefits nobody distinguishes clearly
When I started paying close attention to AI — coming from a background in process improvement and RPA — I noticed that most of the conversation collapses two different things into one.
The first benefit is AI as a capability enhancer: the AI works alongside a person, makes them faster, more effective, better-informed. Better organizations, better judgment, higher-quality output. This is genuinely valuable, and it may ultimately be the larger benefit for humanity and the economy. It’s also harder to put a number on.
The second benefit is AI as a human replacement: the AI performs work that a human was doing, without the human. Fewer headcount for the same output. This is where the short-term, measurable ROI lives — and where the pressure to justify the enormous AI investment will concentrate. CFOs don’t fund experiments. They fund results with a line in the budget.
I built a successful team for finance and accounting process improvement and automation utilizing RPA — robotic process automation — that could replace human actions in processes. Clicks, data entry, rule-based decisions, document routing. The bots didn’t enhance the humans who had been doing those steps; they replaced the steps. That’s where the ROI came from: documented headcount reduction, reduced error rates, measurable time savings.
The question I brought to AI was direct: if agents are the AI-era version of bots, do they actually work the same way? Or is “agent” a rebranded assistant with better marketing?
The definition problem
“Agent” is doing a lot of work in 2026, and most of it is driven by the AI sales cycle rather than a stable definition. It means whatever the vendor needs it to mean in the pitch deck.
I’ve watched this pattern before. “Robotic” in robotic process automation didn’t mean robots — it meant software executing clicks on a screen. “Intelligent” in intelligent process automation didn’t mean intelligence — it meant rules plus some pattern matching. The label inflated; the technology was more specific and more limited than the name implied. Eventually the gap between the label and the reality became the story.
AI agents are running the same pattern. The word signals autonomy, judgment, action. The reality, at least in a working definition worth using: an agent is a set of instructions, context, and tools that executes a workflow on your behalf, with or without your active involvement in that moment. It’s a configured system. It can be powerful. It is not magic.
The framework I found most useful came from Nufar Gaspar via The AI Daily Brief — a 7-layer Agentic OS: identity (who you are and what rules always apply), context (your situation, your priorities, and your constraints), skills (reusable instruction sets for things you do repeatedly), memory (what persists across sessions), connections (integrations to external systems like email and calendar), verification (what you check and when), and automations (what runs without you watching).
Every layer runs underneath the agents you build. The OS is built once; each new agent inherits the whole foundation. Gaspar’s claim: the first agent takes a weekend because you’re building the OS and the agent simultaneously. The second takes an afternoon. The fifth is a few hours.
I’d seen that compounding in RPA too. The first bot in a new environment takes weeks. By the tenth, the team is shipping in days. The investment is in the foundation, not the individual deployment.
Two ideas that arrived at the same time
The Karpathy Method landed in the same week. Andrej Karpathy’s idea is straightforward: instead of searching raw source files every time you need an answer, you use an LLM to build and maintain a structured wiki from those files. New source in, wiki updated. Question asked, answer filed back as a new page. The knowledge compiles and compounds — instead of being re-derived from scratch on every query.
Karpathy’s framing: Obsidian is the IDE (an integrated development environment — the workspace a programmer uses to write and manage code), the LLM is the programmer, and the wiki is the codebase. The schema document — the instructions that tell the LLM how the wiki works — is what turns a generic AI into a disciplined knowledge worker.
What the AgentOS framework and the Karpathy Method share is the same underlying philosophy, articulated by Steph Ango, CEO of Obsidian: files over apps. The files you create are more important than the tools you use to create them. Apps are ephemeral. Your files have a chance to last.
Applied to AI: own your agents in local files. Own your knowledge in local files. The AI tool is the rented layer — disposable, swappable as the ecosystem evolves. Your system travels with you regardless of what tool you’re running it on.
I’d seen the opposite failure in RPA. Bots built inside proprietary platforms were locked to the vendor. When the vendor changed pricing or the platform changed architecture, the bots had to be rebuilt. The organizations that had documented their processes — the underlying logic, not just the software — were the ones that could migrate. The documentation outlasted the tools. Same principle.
Why I decided to build one
The honest challenge with AI agents in 2026 is finding examples that are real. Not demos. Not press releases. Not case studies from vendors describing their own products. Documented accounts of agents performing replacement-level work — executing processes that a human was executing before, reliably, without constant supervision — are harder to find than the volume of coverage would suggest.
So I decided to run the experiment myself.
Not to have a setup. Not to be able to say I built an Agentic OS. To find out what agents can actually do — in my own workflows, in my domain, at the scale of a small professional services operation — and report back honestly.
That’s what this series is. A build-in-public experiment, documented as it happens. Each post covers a piece of what I built, what worked, what didn’t, and what it tells me about the question that actually matters: where does replacement-level AI work in practice, and where is the gap between the demo and the deployment still wide?
If you’ve built RPA bots before, you’ll recognize the pattern. The technology has changed. The questions haven’t.
Follow along for the next post, where I get into what I actually built first — and what it immediately revealed about where the gaps were.