My Agentic OS: What a Non-Coder Actually Built

My last real coding class was BASIC, back when we were still fairly confident the personal computer might catch on. I never wrote production code after that. What I did instead was use technology hard — build systems on top of it, set up the workflows, and hire the people who could code when code was what the job needed. I’m a tech-obsessed normie: an effective user, a builder of systems, a manager of people who write software. Not a developer.

And I just built a working agentic operating system.

I say that carefully, because in 2026 nearly everyone demonstrating an impressive agent setup is an engineer. Watch enough of these videos and you absorb a quiet assumption: this is a technical person’s game, and if you can’t code, you’ll be wiring together toys while the real builders do the real work. In the previous post I laid out why I decided to run this experiment myself — the distinction between AI that enhances people and AI that replaces work, the fact that “agent” mostly means whatever the vendor needs it to mean, and the RPA background that makes me skeptical of both. I closed that post promising to show what I actually built first. This is that post.

Here’s the punchline up front, because it’s the whole point: the hard part isn’t the code. It’s the files. The leverage in an agentic OS lives in what you own — your context and your curated knowledge. The tool you rent to operate on it is the cheap, swappable part. That’s why a non-coder can build one that does real work, and why I could build mine with nothing more exotic than Obsidian, Claude, and my email and calendar.

I’m a tech-obsessed normie — and that turns out to be the point

Let me be specific about the “normie” claim, because it matters for what follows.

I made spreadsheets sing — Lotus, then Excel on a Mac, Excel on a PC, back to a Mac — and used them to reshape how actual work got done. I went through multiple large-system implementations and learned their guts, for inventory and for finance and accounting. I built and led a process improvement team that used Lean to redesign work, then automated a good deal of it with Robotic Process Automation. I did some consulting on business transformation and RPA implementations along the way. None of it required me to write the lowest-level code.

That’s the pattern I keep coming back to. In RPA, the person who made the automation deliver value was rarely the one writing the tightest script. It was the one who understood the process cold and owned the logic — what the work actually was, where it broke, which steps were rules and which needed judgment. The code was downstream of that understanding. Agentic AI rhymes with it exactly. The scarce skill is knowing what good work looks like and describing it precisely enough that a capable system can execute it. Syntax is the cheap part.

What I’m actually trying to build

Three jobs, stated plainly.

A chief-of-staff agent to help me manage the work — surface what needs my attention and keep the trains running.

A content production process that improves the quality of what I publish and gets it out faster. Better voice and higher velocity from the same build — which happens to be the single most important thing I’m trying to accomplish this quarter.

A files-over-app, LLM-agnostic system underneath both: my personal context in files I own, a research wiki that doubles as the raw material for my content, and a place to capture interesting sources before they evaporate.

Notice those are jobs to be done, not features. That’s deliberate. If you’re an operations leader evaluating this, the useful question is simple: did the work get better or faster? “Do I have an agent?” doesn’t make the list. Everything below is in service of those three outcomes.

Approach 1: The chief-of-staff Agent OS

The first approach I built on comes from Nufar Gaspar, whose 7-layer Agent OS I found through The AI Daily Brief. The framework’s central bet is that the specific tool matters less every month, because every agentic tool is converging on the same underlying capabilities — reading context files, remembering across sessions, connecting to email and calendar, running on a schedule. What lasts is the system you build underneath, described in plain text files that any tool can pick up.

The seven layers are identity (who you are and the rules that always apply), context (your actual situation and priorities), skills (reusable instruction sets for the things you do repeatedly), memory (what persists between sessions), connections (the reach into email, calendar, and other systems), verification (what gets checked and when), and automations (what runs while you’re not watching). Every agent you build sits on top of that foundation and inherits all of it.

Mine has access to my email, my calendar, my projects and experiments, my content workflow, and the context files I’ve written about how I work and what I’m trying to do. It surfaces email, calendar, and meeting notes with recommended actions, drafts project plans from my inputs, and keeps an eye out for sources worth my review.

The part worth naming for anyone who’s done this before: it compounds. Gaspar’s claim is that the first agent takes a weekend, because you’re building the OS and the agent at the same time; the second takes an afternoon; the fifth takes a few hours, because the foundation is already there. I watched exactly that curve in RPA. The first bot in a new environment took weeks. By the tenth, the team was shipping in days. The investment was always in the foundation. The individual deployment was almost an afterthought.

Approach 2: The Karpathy method — a wiki that compounds

The second approach came from Andrej Karpathy, a founding member of OpenAI and Tesla’s former director of AI. I mention the pedigree deliberately: this comes from a genuinely technical authority, and what he’s proposing is almost aggressively simple.

Most people’s experience with LLMs and their own documents is RAG — retrieval-augmented generation. You point the model at a pile of files, it grabs the relevant chunks when you ask a question, and it generates an answer. Nothing accumulates. Ask a hard question that requires synthesizing five documents, and the model re-derives the answer from scratch every single time, like a consultant who bills you to re-read the same binder at every meeting.

Karpathy’s alternative: instead of retrieving from raw sources at query time, you have the LLM build and maintain a persistent wiki that sits between you and the sources. Ingest a new source, and the model reads it and folds it into the existing pages — updating entries, revising summaries, flagging where new information contradicts old. Ask a good question, and the answer gets filed back into the wiki as a new page. The knowledge compiles once and stays current instead of evaporating after every conversation. His metaphor: Obsidian is the workspace, the LLM is the programmer, and the wiki is the codebase.

This fits files-over-app perfectly. The wiki is plain markdown that I own; the LLM is the rented compiler that keeps it tidy. And I implemented it for real — raw sources go in, compiled wiki pages come out, with an AI acting as the disciplined librarian that does the bookkeeping I would inevitably abandon. The wiki this very post drew its research from is that system, running.

The one idea underneath both: files over app

Both approaches rest on the same foundation, articulated by Steph Ango, the CEO of Obsidian: “the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last.” Own the files. Rent the AI.

For an operations leader, that abstraction cashes out as something concrete: portability. Because my system is plain files, it’s LLM-agnostic. If a better tool shows up next quarter, I point it at the same folder and keep going. No migration project, no rebuild.

I learned the cost of the alternative the hard way. RPA bots built inside proprietary platforms were married to the vendor. When the vendor changed pricing or re-architected the platform, those bots had to be rebuilt from scratch. The teams that had documented their processes — the underlying logic, not just the vendor’s software — were the only ones who could migrate cleanly. The documentation outlasted the tool. Same lesson, new decade.

My tech stack — deliberately boring

• Obsidian — local-first markdown. This is the file-over-app home: plain text, portable, mine.
• Claude Pro — Chat, Cowork, and Code. The rented layer that does the work.
• Gmail and Google Calendar — the connections.

That’s the whole stack. No exotic infrastructure, no server to stand up, nothing that requires a developer to assemble. If you’re reading this, you could put the same pieces together this week — which is either encouraging or slightly deflating, depending on how much you were hoping the secret was expensive.

The guardrails — this is the honest-assessment part

Building it is one thing. Not getting run over by it is another, and this is where I spent real attention.

Connections start read-only. The agent can look at my calendar and inbox before it’s allowed to touch anything, because — as Gaspar puts it — the risk scales with the capability, and there are already real incidents of agents with loose permissions cheerfully handing private information to anyone who asks. Write access is earned, not granted by default. Beyond that: nothing gets sent, posted, or published to the outside world without my explicit approval; nothing gets deleted without me confirming it; and each agent operates only in its scoped part of the vault.

None of that is novel security theory. It’s the RPA-earned instinct restated: match the oversight to the blast radius. An agent that drafts a note for me to review needs light supervision. An agent that could email a client on my behalf needs a great deal more. That distinction is exactly where “driving the train of AI without getting run over by it” stops being a slogan and becomes a set of specific, boring rules.

My agents, and what I’ve actually learned

What I run is a two-tool architecture. The chief of staff lives in Claude Cowork and manages the operational side — experiments, content pipeline, daily notes, inbox, scheduling. A separate wiki compiler lives in Claude Code and does one job: turn raw sources into maintained wiki pages. Each has its own domain and its own permissions. They don’t reach into each other’s work.

Now the learning-in-public part, which is the whole reason I’m writing this series.

A few things have worked better than I expected. Around the time I started, Obsidian substantially upgraded its web clipper, and it’s now genuinely easy to feed web pages and YouTube content straight into the raw-source folder that Claude Code compiles from. My personal wiki has quietly become very smart about the specific things I care about, and it does a real share of my research now.

The content agent surprised me most. It can go from an outline or a rough idea to a complete blog post faster than I can talk myself out of writing one.

That speed came with a catch, and it’s the most useful thing I’ve learned so far: it was too easy to publish content that didn’t actually sound like me, and too hard to review at the level of detail I needed to be comfortable putting my name on it. So I changed the agent. I made it demand more input from me, through a stricter structure, and I built a running list of AI writing tics that I ask Claude to hunt down and strip out of every draft. (I wrote about that whole problem separately, in You’re Building an AI Habit. Make Sure You’re Not Building the Wrong One. The tool got faster; I had to build the guardrails that kept fast from becoming careless.

There’s still friction. More than once, an agent has done something other than what I told it to. Every time, I go back and ask what happened. Sometimes it made an outright error. Sometimes it quietly assumed a different path than the one I described. Then we fix it — usually by editing the skill behind the agent so that specific failure can’t recur. It’s less like configuring software and more like training a very fast, very literal new hire.

And I have open questions I don’t have answers to yet. I’m still deliberately conservative about connections: read-only, Gmail and calendar only. I haven’t connected Chrome or other applications while I get smarter about the security tradeoffs. I know there’s real value sitting on the other side of those connections — I also know enough to want to understand the risk before I reach for it. I’m still working on making the content process unambiguously my own thinking and writing while keeping it efficient; that’s an active tension, not a solved problem. And right now this whole system points almost exclusively at my AI-learning work. Whether I can extend it into other parts of my life without giving up privacy and security is the question I’m sitting with next.

Where this leaves us

Let me say plainly what this is. It’s a build-in-public experiment. Calling it a finished product, or a template to copy wholesale, would be overselling it — and overselling is the exact thing this platform exists to push back on. The value is in owning the system underneath, the part that survives when the tools change. The boring stack is incidental. That’s the whole bet.

I promised at the top to point you to people more expert than me for the actual step-by-step, and I meant it. For the chief-of-staff architecture, Nufar Gaspar’s AgentOS walkthrough via The AI Daily Brief. For the compounding wiki, Andrej Karpathy’s LLM wiki write-up. For the philosophy that ties it together, Steph Ango’s “File Over App” essay. Start there, then build the smallest version that does one real job for you.

Then follow along here for the rest of the series, where I get into what each piece of this actually revealed — including the parts that didn’t work as advertised.