I want to show you how to stop asking AI for one-off favors and instead build yourself something permanent: a personal AI operating system. Not a system in the Windows or macOS sense. One project that knows your business, has access to your tools, and can do your work repeatably — even while you sleep. You build it in a tool called Claude Code, and from here on I'll refer to that system by its shorthand, AIOS (for AI operating system).
Let me say it upfront: this is not a ready-made "click here, then there" recipe. Everyone runs their work differently — different tools, different data, different priorities. So what I'm giving you is a way of thinking and a few frameworks for you to fill in your own way. I'll promise you one thing: by the end of this piece you'll know how to build a system like this from scratch, even if you've never opened Claude Code before.
I'll start with two terms, because they come up throughout. Claude Code is a tool in which the Claude model works on your computer — it reads files, runs steps, uses other programs. It runs in the terminal or in a code editor, but I don't use it for programming; I use it to run my day-to-day work. An agent is simply a model that acts on its own: it's given a goal and decides for itself what steps to take, rather than waiting for each next instruction. So much for theory. Today's plan is simple: first you get your head straight, then I'll lay out the four pillars of a good system, and finally you'll build it for real — from an empty project to routines that run without you.
Head first, tool second
The most common mistake I see is jumping straight to clicking around. Someone installs the tool, tries to "automate everything" in one evening, gives up after two days, and falls back into old habits. That's why the first stage is purely mental. I like to capture it in three words: mindset, method, machine. The machine — the tool itself — comes last, not first. That's deliberate.
Start with mindset, because it's the foundation. The question is never "will AI do this for me?" — that's a yes-or-no question, and the answer is almost always "not entirely." The right question is: "how much of this can I lean on AI for?" Every task has some share you can hand off — sometimes 30 percent, sometimes 60, rarely zero. Even if the system takes half the dull work off your plate, that's still half less to do. Out of this mindset come three habits I want to instill in you.
The first habit I call the default reflex. Before you start any task, ask yourself: "how could my system do this, even just a third of it?" Over time that reflex gets so strong that whenever something is dull or repetitive, your first thought is "let my system do it," not "I'll do it by hand." This isn't a motivational slogan — it's a lens you look at your day through to catch the shares worth handing off.
The second habit is breaking a role down into functions. Your work isn't one big block; it's a collection of small tasks. "Automate the whole report-writing process" sounds like an immovable mountain. But if you break the report into pieces — gathering the data, laying out the structure, writing the intro, checking the numbers — it turns out each piece can be handed off on its own. You automate one element at a time, and after a while you look up and see that eighty percent of the process now runs without you. Small steps, not one big leap.
The third habit is the curiosity rule. Never accept the system's answer without asking "why." Treat AI as a mentor, not a vending machine. A vending machine takes your coin and hands over a product; a mentor asks questions, pushes you, floats ideas, and sometimes tells you you're wrong. It sounds soft, but the reason is hard: if you blindly paste whatever you get, you stop understanding your own work. You don't need to be able to read code or know the technology — you only need to understand what your system does for you, and why.
So much for mindset. Method — the second "M" — is a separate skill: how you decide what is even worth automating and how deeply. I'll come back to it when we get hands-on, because it's easiest to show on concrete examples. The machine — the tool and its settings — I'm leaving for the very end, because there's no point fiddling with the screws before you know what you're actually building.
Why it's worth riding out the temporary dip
I have to give you one honest warning, because without it a lot of people quit. At the start your productivity will drop before it rises. Setup takes time, you're learning a new way of working, so for the first few days you'll be slower. That's natural — and that's where the trap lies.
Picture someone working solo who spends thirty days building their AIOS. In the first days their output clearly dips as they adjust to a new way of operating — in practice down by around a fifth from their normal rhythm. If they only looked at that week, they'd write the whole idea off as a mistake. But the right question isn't "is there a dip?" It's: "will the later gain outweigh this temporary dip?" If that same system then delivers a lasting speed-up — say, work that goes half again as fast — then giving up a fifth at the start comes out firmly ahead. I give the figures as an order of magnitude, not a promise; the point is the mechanism itself.
On top of that there's the learning curve. People assume learning runs in a straight line: the more you put in, the more you get out, in lockstep. It doesn't work that way. For a long stretch it feels like nothing has budged, and then suddenly you jump a level. Which means the worst moment is always at the very beginning — exactly when it's easiest to give up. I'm telling you this not to discourage you, but so you don't quit after day one.
One more thing before you move on to building. A system only pays off when you use it. It's a truism, but a true one: you get out what you put in. A setup you never return to gives you nothing — it'll just be a nice-looking folder. The whole point is in daily use, even imperfect use.
The four pillars of a good system
With your head in order, let me show you what a good AI operating system is made of. I like four words — in English they all start with "C," and here they build one on top of the next: context, connections, capabilities, cadence. The order is no accident. You go from the first to the fourth, and you can't skip ahead — there's no cadence without connections, and no capabilities without context.
Context is everything the system knows about you and your business: what you do, what you sell and to whom, how you communicate, what your priorities are this quarter, what your money looks like. There's a simple test for whether you have it. Open a new conversation with Claude Code and ask it something about your work. If the system answers like someone who met you five seconds ago — there's no context. If it answers like a colleague who knows your situation — you're on the right track.
Connections are access to the tools and data where that context actually lives. On its own, Claude Code can essentially only search the internet — and your most important data isn't out there in public. It's in your calendar, your email, your task system, your meeting notes. You make these connections in a few ways I'll come back to: through MCP (a standardized way for a tool to expose its data to AI), through an API (the interface programs use to "talk" to each other), or through plain terminal commands.
Capabilities are the concrete things the system can do with that data. Context and connections alone are just the library and the keys to the cabinets — capabilities are what the system can actually carry out: write a post, prepare a summary table, recap a meeting. You probably already have many such procedures in your head or in your documents. The point is to hand them to the system so it does them just as well as you do.
Cadence is the fourth and, in my view, the most interesting pillar. It's the point where the system runs on its own to a schedule — even when the computer is asleep — and starts to resemble an employee available around the clock. But cadence comes last for a reason: before anything can run on its own, it has to be able to reach your data (connections) and know how to do the thing (capabilities), and to do it sensibly it has to know you (context).
These four pillars are also your checklist. Once the system is standing, you can ask it directly which of the four areas it's strong in and where it has gaps — and so spot what's missing. But one step at a time. First you have to get the system standing at all.
The skeleton of the system: a map, a project, and a master instruction
Now you move to action. The starting point is deliberately analog: grab a sheet of paper or open a blank document and list out your tools. Don't open any program yet — sketch it all out in your head first, or you'll leave something out. And if you do leave something out, no drama; you can always add it later.
Lay out your work across the seven areas I use as a skeleton: revenue, client, calendar, communication, tasks, meetings, and knowledge. These are the seven "buckets" that catch nearly everything you do, and they roll up into four larger groups: operations, communication, data, and planning. Next to each area, note which tool you use — where your tasks live, where your calendar is, what you record meetings with. This is your map of what the system will later tie together.
Only with that map in hand do you create the project itself in Claude Code. At its heart sits a file called CLAUDE.md — the "master instruction" for the whole project. It describes what your system is, what lives in which folder, and when it should reach for a given skill. Think of it as the guide the system reads on startup so it knows where everything is. Alongside it you organize a few folders: one for context (what the system knows about you and the business), one for decisions (a log of important agreements, so it remembers what you've already settled), one for references (material to look things up in). Every time you add a new folder or file, you make sure CLAUDE.md knows about it — otherwise the system won't be able to find its way there.
Onboarding by conversation: seven questions
The best part is that you don't fill these folders in by hand. Onboarding starts with a conversation. You run a procedure you've prepared in advance, and the system walks you through a seven-question interview, saving your answers as its context on its own. It's a bit like a new employee's first day, asking you questions to get up to speed.
The first question is: "who are you, what do you sell, and to whom?" Don't be stingy with words here — the more context you give, the better the system will understand you afterward. The second question asks you to paste in one or two things you've written recently, without polishing them — that's how the system learns your way of writing and your tone. The third question is about the two or three most important priorities for the next 90 days — that is, what you're really working on right now. The questions that follow run along similar lines, going deeper into how you operate. You answer all seven, and at the end the system reports that day one is done: it now knows who you are, what you sell, what matters this quarter, and how you sound.
From this point on you can ask it something practical — say, "what should I focus on this week?" — and you'll get an answer grounded in your situation, not a generality. This is exactly the moment context starts to do its work. You have the first of the four pillars.
Capabilities: teach the system once, use it many times
Now the most important concept in the whole build — skills. These are reusable instructions saved in plain text files. The best analogy is a cooking recipe. Imagine that every time you want to bake a cake, you have to explain the whole procedure to someone from scratch, step by step. Exhausting. Instead, you write the recipe down once, and from then on you just say "bake this cake" — and it all happens.
A skill works the same way. Say you often write LinkedIn posts, and each time you do the same thing: look up information, prepare the graphic, write the text, review it, and publish. Rather than explaining that sequence for every post, you write it down once as a skill. Then you say "write me a LinkedIn post," the system reads its recipe and runs the whole procedure. The result is more predictable and higher quality, because the system always follows the same proven path.
The best part comes when you want to change something. If the next cake is meant to be different, you don't start from scratch — you tweak one line in the recipe ("two eggs instead of one") and on the next run the change simply takes effect. Your skills keep evolving, just as you do. This is the real leverage of the system: you describe your repeatable work once, then run it many times over, improving it along the way.
How a single skill is built
Each skill is one text file with a clear structure. At the top, in a short header, are two key things: a name and a description — what the skill is called and what it's for, or when to use it. This matters, because it's how the system recognizes which skill to use. When you ask for a LinkedIn post, Claude Code scans all the skills but reads only those short headers — the name and the description — and picks the matching one. That's why the description has to state clearly when the skill should fire.
Below the header you describe the rest: what the skill does, sometimes also what it doesn't do (so the system doesn't stray out of scope), and then the steps in order — step one, step two, step three. It's essentially a written-down procedure, your company's "how we do this," just in a form the system understands and executes. If none of your skills match a request, the system simply falls back on general knowledge.
Good news: you don't have to build all the skills yourself. Some you'll build naturally — you notice you keep doing something over and over, so you write it down as a recipe. Others you can download from ready-made skill libraries and add your own flavor to. One caveat I have to give: be careful where you get them from, and check that no one is slipping you a skill with harmful content. Since a skill can act on your behalf, treat it with the same caution as any program you let into your work.
Connections and cadence: a system that runs while you sleep
You now have context and capabilities. I'll come back now to connections, because without them the system knows you but can't reach your data. You'll connect it one by one to the tools from your seven-area map — calendar, tasks, meetings. Here a decision comes up that I want to walk you through, because it's easy to miss and it matters.
When you ask the system to hook up a tool, it will usually propose the quickest route on its own — namely MCP — if a ready-made connector exists for that tool. It works, but it has a downside: every such connector loaded into the project eats a little of the system's "working memory" (in English you talk about token usage — tokens are the units the model counts how much it can hold at once). That's why I more often choose the route through an API, because it's leaner. In practice you tell the system something like: "I want to connect to this tool through its API, because that's leaner than a ready-made connector; review the tool's documentation and save a reference file in the project with all the addresses I'll need." The system prepares it itself, and from then on you have a clean, lightweight connection.
Importantly, not every tool has a ready-made connector, or even public documentation — and that's not a problem either. There's always a way: as a last resort, the system can drive the tool through the browser, clicking around in it the way you would. A practical tip: don't connect everything at once. Start with the few most important things you use most often — tasks and meetings, say — and add the rest over time. It's that same principle again: small steps instead of one big leap.
Cadence: local routines and the ones in the cloud
Last, the fourth pillar — cadence. You build it with routines: scheduled commands the system runs on its own to a schedule — every morning, on chosen days of the week, on a regular beat. A routine is nothing complicated: it's simply a saved command that, at a set time, gets "typed into" the system as if you'd typed it yourself and pressed enter. The system then opens an ordinary conversation and does what you asked — often firing one of your skills along the way.
Here's one distinction you need to know, because it's easy to trip over. Routines can be local or in the cloud. A local one runs only while the app on your computer is open — the computer has to be on. A routine in the cloud runs even when the app is closed and the computer is off, because it executes on the provider's servers. That's exactly what makes the system start to resemble an employee available around the clock: in the morning you get a finished summary, even though no one clicked anything overnight.
I have to give an honest limitation here so you don't plan beyond your means. The number of cloud routines is sometimes capped by your subscription plan — for instance, on one of the pricier plans (on the order of two hundred dollars a month) you can have a dozen or so such remote routines running per day. That's a specific number for a specific plan, not a general rule — check what yours allows. For most people, a dozen well-chosen routines is more than they'll use to start with anyway.
One more thing worth knowing: each conversation with the system is separate. If a routine set up some task in one window, the system in another window doesn't know about it by default until it checks for itself. That's not a flaw, it's a feature — keep it in mind once you start having several things in flight at once.
What really changes, and where to start
When this system starts running day to day, three things change — and those are the real reward, not the setup itself.
First, knowledge comes out of your head and lands in one place. You stop carrying everything in memory, you stop plastering your desk with sticky notes. The system remembers for you, reminds you of deadlines, makes sure nothing slips. You also stop being the bottleneck — because sometimes the system has more gathered context on a given matter than you do at that moment.
Second, you stop opening dozens of tabs and apps. More and more of the work happens in one place, so the constant hopping between windows and losing the thread comes to an end. Third comes cadence: some tasks simply happen on their own, to a schedule, with no involvement from you. These are three of the pillars from another angle — context, capabilities, and cadence — this time seen as a daily change in your day, rather than a list to be built.
And one more thing I mentioned in passing that deserves a sentence of its own. The whole system is described in text files — which means it can be moved. The same setup you build for yourself can be replicated: for a colleague, for a team, eventually for a client, tuned to their reality. That's where the other half of the idea comes from, the part about "selling" — but that's a separate topic, one you'll only get to once the system has proven itself for you first.
The most important takeaway isn't technical. You don't have to build everything on the first try, or reach perfection. Start small — with context and one or two skills you'll genuinely use — and expand the system as you go, because it learns alongside you. Look at your repeatable work as something you can describe properly once and then run many times over. Open a blank sheet and write out those seven areas for yourself. That's the whole first step — and the only one you need to take today.