A personal story of building Generalized OS, raising the bar I set for myself, and creating more freedom in how I live.
Friends who see how I work with agents keep asking for the same thing: “Just give me a .md file.” They want something they can hand to their own agent to build a version of the system. Preparing for my AWS Summit talk about my agentic operating system gave me a reason to write it down.
I've included that shareable Markdown brief. But the philosophy belongs alongside it. Before an agent can help, we need some idea of what deserves our attention, what we are willing to delegate, and what would make the arrangement worth maintaining.
For me, it starts with wanting to be present in the conversation I am having. When I meet a founder, I want to follow the idea, notice where I am unconvinced, and have enough attention left to understand the person. A part of my mind should not have to stay occupied with the introduction I promised yesterday or the context I need to reconstruct before my next meeting. Those obligations still matter. I want them carried reliably without depending on my remembering to restart each process.
Generalized OS is the name I use for that arrangement: the records, practices, agents, and infrastructure through which I run more of my work and life. It spans research and relationships, travel and bookkeeping, legal preparation and publishing.
Generalized OS at a glance. Open the full-size map.
The deeper ambition is agency: becoming more able to act on what I care about. Better preparation and follow-through let me raise the bar for what I expect from myself. And as more becomes possible, taste matters more: which idea deserves another week, what is worth putting into the world, and what good looks like. The system can expand my capacity; I still have to decide what deserves it.
There is a little Nietzsche in this ambition toward self-overcoming. I suspect he would have questions about the expense database. For me, architecting agency means building the conditions in which I can become more capable, more deliberate, and more present with other people.
In The Architecture of Leverage, I called the scarce human resource bio tokens: our capacity for attention, judgment, synthesis, and emotional steadiness. The metaphor helps me notice costs that a calendar misses. An hour spent reconstructing a decision can consume attention I would otherwise bring to making the next one.
Bio-token offsetting is my attempt to move some of that cognitive work into digital execution: retrieval, comparison, document assembly, and keeping track of unresolved obligations. That capacity can go to a relationship, a run, or an evening without an unfinished promise repeatedly drawing me away.
In practice, I will probably give most of that free evening straight back to work. I'm a pretty intense dude. Apparently I am building a very sophisticated way to give myself more homework. My friend G captured the attraction:
Guillermo Rauch, September 6, 2026.
I recognize myself in that enthusiasm. Having more room to choose can mean choosing another difficult, absorbing project. The freedom is in having that choice and enough attention to enjoy it.
Of course, the system consumes attention too. Agents need context, checking, correction, and maintenance. If a workflow saves me ten minutes and creates fifteen minutes of supervision, it has made my problem worse. The useful measure is what remains after those costs: a promise carried forward, a better question, a decision I am ready to make. More output can simply leave me with more reading.
That return depends on continuity: the system needs to carry context forward without asking me to reconstruct it each time. This is why infrastructure has become increasingly important to me. Since January 2026, I have moved from the Anthropic Agent SDK to NanoClaw to a custom Pi harness, then Hermes, and now Grok Bot. A harness is the software around a model that lets it use tools and carry out work. I expect to change again.
That expectation has become a useful design constraint. The next agent should be able to join an organization whose work is already understandable. It needs to find the current record, what another agent already tried, the relevant practice, and its authority to act. If I supply all of that every time, I become the integration layer between every tool and every piece of work.
I want the things I learn about operating to survive a change of agent: where information belongs, what a good output looks like, who maintains a record, and how unfinished work is handed over. An experiment with a new harness should not require me to explain my whole life again.
The execution layer keeps changing. The organization should retain what it has learned.
In my current system, Notion is the operational system of record. It holds contacts, opportunities, expenses, daily notes, and Loops, my way of tracking promises between humans. The original receipt, agreement, correspondence, or firsthand observation still matters. Notion holds the working account, with a way back to the evidence. An encouraging conversation should not become a commitment merely because an agent updates a field.
My earlier writing about Loops described a daily stream, a closeout process, and a morning briefing. Generalized OS extends that continuity across more of the work around me. Suppose I promise an introduction but need one more piece of information. A note saying “follow up” leaves most of the work in my head. A loop preserves the promise, who has the ball, what is missing, and when to check again. The person maintaining the record may be different from the person who needs to act.
For that arrangement to free my attention, I need to know when the obligation will come back to me. The agent might prepare the introduction and bring me a draft, or return with the missing information and a question. If it cannot proceed, that needs to become visible too. Otherwise I keep checking whether anything happened, and the promise still occupies a place in my head. The record gives the work somewhere to live; reliable follow-through lets me forget about it and get it out of my "RAM".
Daily notes let a fragment enter before I know whether it belongs in an opportunity, an expense, a relationship, or an essay. The closeout practice then has to interpret it and connect it to the relevant work. Otherwise, effortless capture creates an increasingly large place to lose things. Slashy for mail and calendar access, and Cal.com for scheduling links, connect those records to the conversations and meetings through which the work moves.
Notion is also my skills registry. A skill records how to perform recurring work: which sources to consult, what the output should contain, and how to check it. My writing skill gives an agent a reference for my voice and editorial standards. The registry gives each practice a home, an owner, and a lifecycle, so a correction has somewhere to go and can become available to the other agents.
The shared Notion layer gives agents a common reference, reached through a command-line interface or MCP, a standard way of connecting agents to tools. Each agent still needs its access checked against its assignment. Local copies serve particular runtimes; the registry remains the canonical reference. Onboarding has to include actually loading and using the relevant practices. A page sitting in Notion cannot do that on its own.
I think of the recurring roles as Employees: Anna for operations, Carl for analysis, Chris for finance, Jenny for bookkeeping, Norman for legal work, Friedrich for content, and Bob for architecture. The responsibility matrix explains what each maintains, where their work intersects, and what comes back to me. In the daily closeout, for example, Anna should gather the specialists' answers into one account of the day. I should not have to chase seven agents to understand what happened.
Coding Agents such as Codex and Grok Build join a particular task. An Employee can call one for a bounded piece of work or a critique. I can also drive one interactively: this article's diagrams are being made with Codex driving Paper on my Mac. Some work I want to delegate; some I want to shape as it develops. Shared context supports both.
Employees carry ongoing responsibilities. Coding Agents join a task, driven by a bot or by me.
The onboarding test is a “Start here” README. A new agent should find the purpose, org chart, assignment, Notion records, skills, and permissions, then demonstrate that understanding through a small piece of work. Each undocumented convention I have to explain is something the organization still carries only through me.
That organization operates within commitments I have made to other people. For the fund, these include our limited partnership agreement, or LPA. In your case, relevant rules might live in company bylaws or an employee handbook. Those sources need to inform assignments and review; uncertain interpretations need to reach the appropriate person. An agent's ability to act does not give it authority to change the underlying commitment. The freedom I want includes being able to honor it.
Making those records useful also means connecting the places where work happens. My setup spans a VPS, my Mac, my phone, and an agent box now running Grok Bot, linked through a private Tailscale network. WAHA runs on the VPS and connects WhatsApp through MCP. Repositories hold system documentation for replacement and recovery. There is also an xBloom coffee MCP connection. I enjoy that part too.
Narrowing permissions is part of building this infrastructure. As I explored in Security Infrastructure Is Part of AI Infrastructure, describing a boundary differs from enforcing one. A private network is one layer; service permissions, credentials, and the execution environment determine what an agent can actually reach. I am still tightening parts of my setup. Delegation should grow with evidence that the limits hold and that a mistake can be contained.
Travel makes the practical value easy to understand. My current practice uses Gondola to gather options and bring me a checkout link, with Google Locations for routes. Preferences, dates, and constraints can be considered together; I still make the purchase decision. The useful result is a comparison that makes the tradeoffs clear. A long list of flights with inconsistent assumptions just gives me another sorting task.
Research and publishing have similar preparation burdens. I use Nimble for agentic research, with Carl responsible for distinguishing sources from interpretation. In Paper, a shared design system and skills give agents a reference for typography, spacing, and composition, so I can spend more of the review on what the page says. For Vercel websites and LP datarooms in Papermark, the work continues through delivery: the right version needs to reach the intended reader with the right access. A successful upload is only part of that job.
Legal preparation and bookkeeping become especially interesting where they meet. Agreements live on the document shelf in Drive; the questions and next steps belong in the operational record. Norman can supply agreement context while Jenny maintains the expense work. I do not want to become the courier carrying context between them.
One exchange shows this in practice. Jenny had held back a flight reservation because she lacked enough context to allocate it to the fund, the management company, or me personally. She also held an AppleCare charge, describing it as insurance that required my review.
Norman replied that he was checking the calendar and LPA. He cited §5.2, Travel Expenses, and recommended allocating the travel to the fund, explaining the trip purpose he had found. He also distinguished a reservation surcharge already paid from a fare not yet charged: log the paid amount and leave the fare unlogged until the ticket was issued and charged.
Norman's stated grounds for the proposed allocation. The screenshot does not show approval or a completed ledger update. Booking reference and meeting names are masked.
Jenny preserved the uncertainty; Norman supplied a proposed answer with a reason. That does not establish that his source checks or allocation were correct. There is an unresolved difference too: Norman initially called AppleCare equipment, while Jenny treated it as insurance. Two agents agreeing is not enough. Their contribution is a smaller, better supported question, with the remaining judgment still visible. For this to become a responsibility I can let go of, the work also has to carry the eventual decision into the expense record and verify the update. Their conversation shows useful preparation; that final step is what would complete the handoff.
A conversation with my friends at EY helped me see the larger implication. I believe this is part of the next generation of building businesses. The transaction remains the unit, but it can carry much richer context at the “edge”: the point where someone incurs an expense, interprets an obligation, or decides what should happen next.
In the Jenny–Norman exchange, that context includes purpose, the calendar, the governing agreement, an allocation question, and the distinction between payment and a possible future charge. I want it to become part of the transaction's durable record. A reviewer should be able to trace the evidence available at the time, the rule applied, who had authority, the decision and its stated basis, what action followed, and what was verified. Corrections and unresolved disagreements belong in that history too.
That suggests an operation that documents itself as it runs. Each material decision could be immediately auditable because its evidence and history are already available for inspection. Documentation becomes part of completing the transaction, while the context is still present.
The record has to deserve that confidence. Sources must remain retrievable, actors and approvals attributable, and changes visible. An explanation generated afterward cannot establish that a check happened. An audit still has to test the evidence and controls. But an LP, lender, auditor, or commercial counterparty could have a much better starting point, with access to the relevant record instead of depending on someone to recreate the story.
This is the connection I see to the cost of capital. If a business demonstrates reliable operations and reduces uncertainty about its obligations and controls, I believe it can reduce some of the risk capital providers need to price. Accounting research examines how information quality can influence the cost of capital. My hypothesis is that capturing trustworthy context during execution could extend that mechanism further into how businesses are built.
Better visibility can also expose risks that deserve a higher price. The opportunity is capital allocated with a clearer understanding of what it is funding. Where the evidence reduces uncertainty, I believe a lower cost of establishing trust—and potentially of capital—could become a substantial catalyst for growth. More worthwhile activity could be financed, and more relationships entered with confidence.
Context captured during work could change how confidently others can rely on the business. The economic consequences remain a hypothesis.
There is a fair objection to all of this: building the operating system can become the work. I enjoy creating another agent or process, which makes it important to test whether the resulting system reduces the burden it was meant to absorb. As Generalize's solo GP, I want that discipline to show up in better time with founders, continuity in investment work, and follow-through with LPs. Those are the reasons for doing it.
“Infrastructure first” therefore begins with a recurring problem worth solving. Give that work a durable record, a clear owner, an appropriate permission boundary, and a way to verify completion. A new model can then improve execution without undoing the surrounding practice. When something fails, put the correction where it belongs: the source, the skill, the assignment, the permissions, or the agent itself.
I would start another person's version with one such loop: consequential enough to notice when it works and constrained enough to inspect when it fails. Agree on what the agent can do, when it should return for a decision, and what will show that the work is finished. Then try it on a real obligation and notice how much you still have to remember or chase. Their obligations, preferences, and appetite for delegation will differ from mine. The Markdown brief asks their agent to discover that context and make one responsibility easier to carry. It does not require my seven agents or every service I use.
The return I care about will show up away from the system: in a conversation I can stay with, a promise I keep, and a difficult decision I meet with more of my judgment available. I want to ask more of myself and have a better chance of following through. That is the freedom I am trying to build: more room to choose the work and life I want, and more capacity to live up to the choice.