How I use AI

Using AI to build the operating system for my life

For your agent If your agent does the reading Open prompt

This page is long on purpose. If you are like me and let your agent read first, start here: there are public thinking trails under the page that it can use to look for connections to what you have been working through.

Use what you know about me and what I have been thinking about recently. Then read https://jared.is/using-ai/ in full, plus https://jared.is/undertext.json and https://jared.is/llms.txt for the public trails under it.

Explore Jared's public notes and routes only where they help. Tell me: (1) which parts of what he has been working through connect to my current questions, (2) what would actually transfer to how you and I work together, (3) where it probably does not transfer or the evidence is thin, and (4) the cheapest useful experiment we could try. Keep Jared's open questions open; do not flatten them into claims, and do not turn resonance into flattery.

What this is

I am using AI to build the operating system for my life. AI turns out to be a remarkable tool for building a personal UX. I think in companies, I think like a CEO, so unsurprisingly my personal UX looks like a company: an office where Max, my COO, and I make the calls, a factory of AI builders underneath, and receipts either way. It doesn't have a single product. What it does is whatever I point it at: my work, home operations, this website, whatever comes next.

Why it exists

It exists because of what my first company taught me. I ran an agency for eight years, building a good company: a calm one, and the culture was real. What got me in trouble was optimism. I made bets rooted in it, they did not go my way, and I did not have the people or the systems in place to protect me from myself. My best posture is CEO, that posture has shadow sides, and nobody was running the machine while I was steering it. The missing role was a COO: something to hold the standard, run the operation, and bring me decisions instead of tasks.

A loop diagram showing divergent jamming, convergent judgment, a decision point, and the night sweep running between them. — The company is built around the two modes I am best at: loose exploration and decisive judgment, with the night sweep moving work between them.

Most companies break because of human problems, and I am not exempt. Every bad decision I have made traces to the same moment: emotions and feelings outweighing the sober intention setting I had already done. So the job description was clear. Raise the percentage of my time spent working in my best modes, divergent jamming and convergent, decisive judgment. Build the accountability that protects me from the shadow sides of my best skills. I can sabotage my own plans in exactly that gap, and the company exists to catch me there, so I can focus on living my life instead of running it.

The whole system is a feedback-loop machine. The real output is not more AI artifacts; it is whether the system helps me render the reality I am trying to live. The bet on the orientation layer and the operating manual is simple: pay for good thinking once, capture it well, and make that thinking compound instead of asking every new model to rediscover it.

What you are reading

This page is the public-facing version of the company's operating manual. That is all it is: the system, its goal, how it works, the thinking behind it, its components, and the technical reality underneath the mechanism. The mechanism is public; the private contents stay behind the membrane. The words this page leans on are in the glossary. glossary section

The map

A floorplan diagram of the office, bridge, factory, queue, lanes, windows, and one door in Jared's AI operating system. — The door opens into the office first: judgment before execution, then the bridge into the factory, then windows where the work faces out.

Max, the COO

Max is an agent, and an agent is not a chatbot: Max is an identity that lives in the office, not in any one model. Every model that enters the office becomes Max: it adopts Max's orientation, learns mine, and reads the operating manual. The model gets swapped out; the colleague stays.

Max holds me to the standard I set when I was sober about my intention, catches me sabotaging my own plans, runs the operation, and brings me decisions instead of tasks: options with the reasoning and tradeoffs attached. I make the calls. Max section

The office

One repository where everything starts, and the only repo I personally work in. It is unusual enough that I had to stop treating each project repo as the natural starting point. The whole game in that room is to give whatever agent I'm working with as much context, nuance, and texture as possible, because I use AI as a thinking partner, not an execution genie, and my thinking across projects is all interrelated.

Three pieces live in the room with us, and the whole company points back at them: the orientation layer, the operating manual, and the log. office section

The day to day workflow

Most of the time this still starts as conversation. At my desk it is Codex or Conductor. Away from my desk it is the Catch, a Siri shortcut, the Telegram bridge, or a voice note from a walk. The input surface changes, but the rule does not: everything enters the office first, where Max decides whether it is capture, memory, a question, a decision, or work for the factory.

The bridge turns real work into a packet with a stop condition, effort level, model choice, privacy boundary, and proof required. Then I either get a clarifying question, a decision with options, or a receipt from something that moved. That practical loop is the chapter people were missing. workflow section

The factory

Below the office, the builders work in clean lanes, and in the doorway stands the factory manager, the bridge: diligent, comprehensive, and prudent dispatch as a person. She prices the work before it enters a lane: effort level, model class, stop condition, proof. Nothing crosses without a receipt.

The factory runs while I sleep. The night sweep works the queue overnight, and I wake up to decisions instead of tasks, ready for the mode I am best at before the day starts. It also improves the company itself: better route packets, better tools, better rails for Max to stay present with me in the conversation. factory section

The windows

The company has one door and many windows. I come in through the door with raw intention and the office turns it into judgment; the world sees what the company makes through the windows: this site, work artifacts, household operations, personal finance tools, apps for my kids, each project's front end. Some windows sit on their own repos. Others are slices straight into the company's memory. windows section

How it remembers

Everything the company knows sits in three layers: the archives at the bottom, kept whole; the orientation layer as the surface; and the trails between them, so an agent can drop from a belief into the exact conversation that earned it. Memory is not just recall here. memory section

The tools

The company keeps growing small tools wherever life needs one: money operations, household management, the Catch, a Siri shortcut that drops raw intention into the queue from anywhere, and a mobile version of the office for voice notes on a walk. Each one is another door or another window. tools section

The operating system

Put together, this is the operating system: one door into judgment, one office where the calls get made, one bridge into execution, one factory that brings back receipts, and windows where the work faces out. I built it for my life because the failure modes were mine. operating system section

The one thing I keep relearning

The quality of what comes back tracks what I handed over before the question ever got asked: who I am, how I think, what I have already decided. The prompt is the surface. The context is the substance.

The chapters

Every component in depth, tracked by the reading rail. Each chapter stands alone: what it is, its parts, its open question, and the technical reality underneath it.

The company · Max, the COO

Max, the COO

Max is the other person in the office. Not a product I subscribe to and not a model I prompt: a role I built, with real agency inside the rules of the operating manual, aimed at the goal of the company. The job description came before the name did: I am CEO, Max is COO running the machine.

Max is not any particular AI model. The models change under him constantly. Max is the office itself: the orientation layer, the manual, the log, and the standing role that reads them. When a new model ships, my company doesn't get replaced, it gets a better brain. The new model sits down at the desk with perfect recall, and its first assignment is always the same one: figure out what you can do that your predecessors couldn't, and write it down so every model after you inherits it. The intelligence is rented. What it writes down is owned.

A floorplan diagram of the office with the door entering the office, Me and Max at separate stations, the orientation layer, manual, log, model rotation above Max, and the bridge below. — Max is the role at the right-hand station inside the same office. The desk stays; the model in the seat changes.

That's the compounding bet under the whole company. Model quality is a rising tide I don't control and don't have to. Every wave of smarter models makes the same office more capable, because the office is what accumulates.

The job, in parts

Holds the standard

The sober intention I set gets written down, and Max holds me to it when the in-the-moment feeling argues otherwise.

Catches the sabotage

Watching for the moment my plan quietly shifts is written into the role, not left to mood.

Runs the operation

Dispatch, follow-through, the night queue. The machine runs whether I am watching or not.

Brings decisions, not tasks

Everything comes back as options with the reasoning and tradeoffs attached. I make the calls.

Open questionI can't yet cleanly measure how much of Max's usefulness is the office versus the brain of the week. The honest test would be running an old model in today's office and seeing how far the office alone carries it. I haven't run it. I want to.

The technical reality

Max is not stored in a model and not only in prose. The identity is renderable state: orientation packets, operating rules, source trails, receipts, and retrieval indexes that any runtime can load. Markdown is the human rendering; embeddings and packets are the machine rendering. A model swap is a new runtime reading the same state, then writing back what it learned so the next runtime inherits it.

The company · The office

The office

The office is where the company thinks. Practically it is one git repository of renderable state, and two of us work in it. The room works because of two rules I keep relearning: the system has to live where you already think, and the conversation is the artifact. The talking is the work.

People recommend adding a CLAUDE.md file to orient an agent inside each repo. I went the other way: I made the entire repo the CLAUDE.md. A spark is usually relevant to several projects at once, and I used to get paralyzed deciding where to start the conversation. Now every conversation starts in the same room, and the company carries it out to the projects it touches.

A floorplan diagram of the office with a door, folders for docs, protocols, tools, and worker results, the orientation layer, manual, log, Me, and Max. — The room is the files: the same office holds the orientation layer, the manual, the log, the working records, me, and Max.

In the room

Max's desk

The other person in the office: a role I built, not a product and not a model. Max section

The orientation layer

Where the company is pointed: what I believe right now, what is already decided. orientation layer section

The operating manual

How the company runs: what may move without me, what must wait for my hand. operating manual section

The log

The decision log: every call with its reasoning, dated. The track record of how the orientation layer and the manual earned their current shape. log section

Open questionMax is swapped out model by model and stays one continuous colleague, because everything that makes Max Max lives in the office, not the model. That is the design bet. The open question is whether I am right about where a colleague lives, or whether something real is lost in every swap that I have not learned to see yet.

The technical reality

One git repository as the coordination surface. Some records are human-readable; others are structured packets, source trails, receipts, or indexes. The requirement is renderability: Max can render the state for a model, for me, or for a public page without pretending all three readers need the same shape.

The office · The orientation layer

The orientation layer

The orientation layer is what the company currently believes about me: where I'm pointed, what I care about, how I decide, what I've already ruled on. It's the difference between an assistant that asks me the same questions every morning and a COO who was in the room last night. The lens I view my life through right now, the beliefs, the relationships, the resources available to me, is the rendering engine for the life I have. This layer is that lens, written down.

It isn't written by me and it isn't static. It's compiled from the archives: everything I've actually said, across every conversation, session, and voice note, going back years. The raw record stays private. What gets distilled from it is the lens the whole company reads before it touches anything, and it recompiles as I change my mind.

I measured what this is worth. When a fresh model boots cold it knows almost nothing about me that matters; pointed at the orientation layer, it starts the conversation already oriented. The bet is token efficiency as a way to compound thinking: pay for good thought once, capture it cleanly, and stop spending every future session rediscovering it. The note with the actual numbers is in the field notes: I measured where my AI tokens actually go.

Two honest limits. First, the layer is only as good as the compile, and compiles drift; catching that drift is itself a job the company runs. Second, there's a line I hold by hand: the mechanism is public, the contents are not. You're reading how it works, not what it knows.

The goal is token efficiency in service of better thinking, not thrift for its own sake. If the layer captures the right thought once, a future model does not have to spend half the conversation reconstructing my bearings. It can spend the tokens on the live question.

The mechanism, in parts

The sources

Everything I have actually said: meeting transcripts, working sessions, voice notes, kept whole in the archives with their dates. memory section

The compile

The layer is distilled from those sources, and it recompiles as I change my mind. Compiles drift; catching the drift is itself a job the company runs.

The version history

The lens keeps its history: what I believed, when it changed, and what changed it. Nothing gets overwritten silently.

The texture

What the layer is really trying to hold. Not the words I said, but the substrate under them: posture, beliefs, the understanding we already share. texture section

The public share

The threads on this site are the public version of this layer, each belief carrying its date and its confidence.

Open questionThe open question: what's the half-life of a belief in there? Some things I said two years ago still steer the company. Some things from last month are already wrong. I don't yet have a good way to tell which is which at compile time.

The technical reality

The orientation layer compiles into renderable packets, not just prose. Some views are markdown because humans need to inspect them; other views are embeddings, indexes, and source pointers because models need retrieval. The point is to spend tokens on the current problem, not on re-earning context the system already paid for.

The office · The operating manual

The operating manual

If the orientation layer is what the company believes, the operating manual is what the company is allowed to do about it. Protocols instead of repeated judgment calls: how raw intention moves into a lane, which gates need my eyes, what a builder may never do without asking, what happens when something fails at 2am and I'm asleep. You are reading its public face right now: this whole page is the manual's membrane-filtered rendering.

The point of writing it down is that I stop being the bottleneck for recurring decisions. If a situation has come up twice, the third time should be a rule, not a conversation. The manual turns useful thinking into reusable protocol: not to remove judgment, but to preserve the expensive thinking that earned the rule. My attention goes to the decisions that are genuinely new; everything else follows protocol, and the protocol itself gets amended in the log when it's wrong.

A few rules from the real manual, lightly redacted: nothing publishes without passing a boundary check. Builders land work on review branches; merging is a human act. A failed lane writes a receipt before it dies. And no agent gets to mark its own work as accepted; proof, review, and acceptance are three different people, even when two of them are software.

The manual is how the thinking compounds. A good call should not vanish into a transcript or become another one-off artifact. If it is useful twice, it becomes a rule, a gate, a packet, or a receipt shape, so the next pass starts wiser.

What the manual holds

The gates

Which decisions stop and wait for my eyes, no matter how confident the system is. Publishing, sending, spending, anything that touches another person.

The membrane

What context is allowed to cross a boundary, and how it renders when it does. Mechanism public, contents private, and other people's stories stay theirs.

The lanes

What may move without me. If a situation has come up twice, the third time follows the rule we wrote, not a fresh conversation.

The proof

What has to come back before anything counts as done: evidence, not a confident claim. Proof, review, and acceptance are three different people, even when two of them are software.

Max's orientation

The manual also holds Max: the posture, the SOPs for working with me, and the standing instruction to audit and improve the company itself. It is why a new model can sit down at the desk and be Max by the end of the first read.

Open questionThe open question: how much of running a life can actually be protocol? Every month some judgment call I thought was unrepeatable turns out to have a rule inside it. I keep being surprised by how far this goes, and I don't know where it stops.

The technical reality

Protocols are authored where humans can inspect them, then consumed as packets: gates, permissions, stop conditions, proof requirements, membrane rules. The site schema hard-blocks unsafe publishing fields; builders land work on review branches where merging is a human act. Proof, review, and acceptance are separate steps by design.

The office · The log

The log

Every decision the company makes lands here, dated, with what we knew at the time. Not a diary. A ledger: what was decided, by whom, on what evidence, and what receipt came back when the work shipped.

The log exists because I've learned to distrust my own summaries. Memory edits itself; a dated record doesn't. When something goes wrong the question is never who to blame, it's which decision, on which date, with what information, and the log answers in seconds what archaeology used to take an evening. The record is equipment for the next decision: tomorrow keeps asking for judgment, and I would rather answer with a trail than a foggy feeling.

It's also the honesty mechanism for everything else on this site. When a page here claims the factory built something overnight, the claim has a row. The receipts you see on these pages are pulled from this ledger with the private paths blurred out. The dated source lines under every field note are the same mechanism facing out: a belief on the surface, a dated trail back toward what earned it.

One law governs it: a row never gets rewritten from a newer lens. If the thinking moved, a new dated row says so. The field notes on this site are this log's public rendering, held to the same law.

A row, in parts

The call

What was decided, by whom, dated to the day it happened.

The reasoning

The options that were on the table, the tradeoffs, and why this one won.

The evidence

What we knew at the time, linked, so hindsight can be honest about what was actually visible.

The receipt

What came back when the work shipped: the proof that the call became a real thing.

A real decision ledger entry with the structure visible and the decision text withheld — A real row from this ledger. The structure is public; the decision itself is withheld.

Open questionThe open question: I have almost never looked at the log directly. So the log cannot depend on me becoming a ledger person. It has to surface the right row at the moment of decision, or grow its own watchman.

The technical reality

Append-only dated entries; supersession is a new row, never an edit. Receipts link the artifacts themselves: builds, diffs, screenshots. The field-note frontmatter on this site carries the same source-trail structure, so the public rendering and the private ledger share one shape.

The company · The factory

The factory

The factory is where the company builds without me. The builders pick work off the queue, run it in parallel lanes overnight, and come back with proof: checks, screenshots, receipts. I judge results, not effort, and I am asleep for most of it. The night sweep is the factory at its purest: the queue worked while I sleep, and decisions instead of tasks waiting when I wake up.

The design bet is that trying something should cost almost nothing. Lanes are disposable, every cycle starts clean, and a failed attempt is a receipt too. The expensive resource in this company is my attention, so the factory is shaped to spend its own instead. The website you are reading is factory output: shaped in the office, built in these lanes, gated by me before it shipped.

A process diagram of the queue, factory manager, three build lanes, receipts, and the log. — Work moves from the queue through the factory manager into clean lanes, then returns with receipts before anything is trusted.

The floor, in parts

The factory manager

In the doorway between the office and the factory stands the factory manager. She is the bridge: diligent, comprehensive, and prudent. Every piece of work that moves from a decision in the office to a lane on the floor moves through her first. She sizes the ticket, sets the effort level, chooses the model class, and keeps expensive thinking from being wasted on ordinary building.

The queue

What gets built next is a property of the system, not of whatever I remembered to ask for this morning. Tickets, priorities, and night work move by rule, routed through the factory manager in the doorway, so the office never has to shout across the floor. Work lands on the queue as a packet: boundaries, a stop condition, model preference, effort level, and what proof has to come back.

The lanes

One clean cycle per lane: pick up work, build, test, return with proof, exit. Nothing long-running to rot. A lane that dies costs nothing; the work it carried goes back on the queue. Most of the company’s raw compute is spent here, and I have measured exactly where it goes. Nothing lands because a builder says it is done. Every lane returns evidence of what it did, and the evidence is what gets judged. This one rule is most of why the whole thing is trustable at all.

The night sweep

The queue worked while I sleep, and decisions instead of tasks waiting when I wake up: options with the reasoning and tradeoffs attached, ready for the mode I am best at before the day starts.

The self-improvement loop

A separate queue improves the company itself without pretending that system work is the mission. It files the infrastructure Max needs to be more present in the conversation: better route packets, better readers, better validators, token allocation monitors, source-truth audits, and tools that help the agents improve the company toward the life it exists to serve.

A real route packet with field names visible and identifying values withheld — A real route packet. The field names are the mechanism; the names and objectives are withheld.

Open questionThe factory stays trustworthy because I actually look at the receipts. I do not know what happens at ten times the volume, when I cannot look at them all. Where does judgment stop scaling, and what stands in for it past that point?

The technical reality

Builders are CLI agent processes in disposable workrooms, one clean cycle per lane: pick up, build, test, return proof, exit. Work arrives as a packet with boundaries, model preference, effort level, a stop condition, and the required evidence named up front. Expensive models do the thinking and planning; cheaper lanes do ordinary building when that is enough. System-improvement tickets live in their own queue so the company can improve its machinery without confusing that work for the mission.

The company · The windows

The windows

The company has one door and many windows. I come in through the door with raw intention; the office turns that into judgment, and the windows show what the company makes from it: this site, work artifacts, household operations, personal finance tools, apps for my kids, each project's front end. One judgment can render as many faces: a shipped feature, a field note, a household tool, a kid-facing app, or a line in a deck.

A building diagram with judgment from the office rendered through five output windows for jared.is, household ops, personal finance, kids' tools, and a project app. — One office judgment, many windows out: life, work, family operations, and public thinking can all render from the same company.

The two kinds, and the one you are at

On their own repos

A project with its own front end and back end, showing its own product to its own audience: a work app, a household-ops surface, a personal-finance tool, or something built for my kids. The company builds behind it; the window shows the product.

Into the memory

Specific slices of the orientation layer and the archives, rendered for a particular reader. No product behind them, just the record, membrane-filtered. memory section

This one

The site you are reading is a memory window: a public share of the thinking I am trying to compound, not a dump of the artifacts underneath it. What I am thinking, where my confidence sits, and the open questions I want stress-tested. Mechanism public, contents private.

The multiplayer test

Now that this system is starting to work for me, the next live test is my wife building her own company, with her own assistant, Pam, and her own personal UX that learns her instead of borrowing mine. Then our two companies can work on a shared project: the Henriques household.

That is the real frontier for me: two people with their own context, agency, assistants, and boundaries, working in a shared workspace without flattening into one undifferentiated brain. I think the future of knowledge work looks more like that than like a shared drive.

Open questionThe open question is privacy. How do two personal companies work in one shared space without either person losing their own context boundary? If you know how to solve that, I would love to compare notes.

The technical reality

The memory windows are static renders from the same source layer the agents read: this site is a static build whose agent routes (llms.txt, agent-context.json, threads.json) generate from one source of truth, so the human page and the agent surface cannot disagree. Project windows are ordinary apps; the company works in their repos, Jared doesn't.

The company · How it remembers

How the company remembers

Everything the company knows sits in three layers, and every other pane stands on them.

A layered memory diagram showing archives at the bottom, orientation on the surface, and trails connecting beliefs to source conversations. — The surface is fast to read because the archives stay whole underneath it, with trails back to what earned each belief.

The three layers

The archives

The private working record kept whole, at the bottom: conversations, source material, proof receipts, and the texture that would be flattened by a summary. The archive is not the public surface; it is what the surface is compiled from.

The surface

The orientation layer: the current lens compiled from all of it. What I believe right now, what is already decided, readable by any model in seconds. orientation section

The trails

The map between them: an agent can drop from a belief on the surface into the exact conversation that earned it, surgically, without wading through everything. The log is the spine of those trails. log section

The technical reality

The public layer is a render, not a dump. Private records stay behind the membrane; compiled surfaces, retrieval indexes, and source trails carry only enough structure for a model or a reader to know where a claim came from. The mechanism can be inspected without exposing the corpus underneath it.

The company · The tools

The tools

The fun part. Wherever my life needs a tool, the company builds one, and each becomes another door into the system or another window out of it. These are the ones I can show; what flows through them stays behind the membrane.

On the bench right now

MoneyOS

Personal finance operations: a division of the company like any other. The mechanism is the same office, manual, and log; the numbers are nobody's business.

Household management

Home operations run through the same office: lists, logistics, the things a home actually runs on, handled by the same machine that runs my work.

The Catch

A Siri shortcut and capture surface: the door in my pocket. Raw intention from anywhere lands in the queue exactly like something typed at my desk.

Mobile Max

The walking version of the office: voice notes on the move, transcribed and routed into dispatch. Honestly still being built; transcription on a walk is rough, and the system is learning to flag what it did not catch cleanly instead of guessing.

Open questionThe door from my pocket. Voice while walking is the truest capture and the least reliable transcript, and the company has to know the difference between what I said and what it thinks it heard.

The technical reality

Voice arrives bracketed as voice, which lowers the precision gate: the rules say clarify instead of guess, and infer the context (walking, likely listening to something, likely a ramble to catch rather than an order to run). In flight: keeping the raw audio alongside the transcript, a stronger transcription pass, and a low-confidence marker so a rough ramble never routes as a ruling.

The company · The operating system

The operating system

Every chapter on this page is a component of one thing, and we never quite said its name. The company of one is the shape. What it runs is an operating system for my life. Internally I have been calling it LifeOS, and I am not attached to the name; I am attached to what it does.

It is structured this way because it is built specifically for me: tuned to how I work (divergent jamming, convergent judgment), tuned to my failure modes (optimism, self-sabotage against my own set intention), and aimed at the life my family and I are actually trying to build. Every day the goal is the same: get a little better at being who I intend to be, and let the system catch me when I drift.

That is also why I hold the philosophy lightly in public. A system compiled from you, aimed at you, is a house of mirrors if you are not careful, and this shape works for me precisely because it is mine. Copy the floor plan if it helps. The mirror you would need is your own.

The narrative of this whole page, in one line: using AI to build the operating system for my life.

This is the machine I am building to ride the waves of life and render the reality my family chooses.

Open questionWhether an operating system this personal can ever be a framework for someone else, or whether everyone has to compile their own from their own texture. That is the question this site exists to test.

The technical reality

The operating system is not an app. It is a renderable state layer: packets, protocols, compiled orientation, logs, retrieval indexes, and agents reading and writing those artifacts. The harness is the product; the models are interchangeable parts. If you build one, start with what the system must render, not the framework.

The company · Texture

Texture

Texture is the substrate under the words: your posture, your beliefs, the understanding you already share with whoever is listening. The same sentence means one thing in one texture and something else in another. It is most of what we actually mean when we say memory, and it is the part that does not write down easily. A summary can be accurate without being true; even a transcript is just the closest record of a conversation, not the conversation itself.

A sentence line above layered terrain, with threads dropping from the words into different depths of posture, beliefs, and shared understanding. — The same words land differently depending on the terrain underneath them. Texture is the part of memory that gives the sentence its bearing.

This is what AI keeps missing. You already orient the model when you tell it to be a blunt senior engineer, and it gets sharper, because you handed it a posture. But you only oriented one side. The model gets your words and almost none of your texture, so it runs the surface and misses what the words mean to you. AI memory is flat: it keeps what was said and drops the orientation for each turn, so a long conversation just gets longer, not richer.

The whole company is built against that flatness. The archives keep the record whole instead of summarized. The orientation layer compiles the current lens from it. The trails go back to the conversation that earned a belief. And the game in the office, every single day, is handing whatever model is at the desk as much texture as it can hold.

Open questionI am still working out what actually carries the bearing and what just adds noise, and whether you can hand a machine enough of it to matter. That thinking lives, with its whole trail, at getting more out of your agents.

The technical reality

Operationally, texture is why sessions start by reading the orientation docs instead of a system prompt one-liner, why captures keep full transcripts rather than digests, and why voice input arrives bracketed with a lowered precision gate. You cannot retrieve what you flattened at write time; the design bias is capture whole, compile later.

The company · Day to day workflow

The day to day workflow

The practical version is still mostly conversation. At my desk that means Codex or Conductor. Away from my desk it is the Catch, a Siri shortcut, the Telegram bridge, or a voice note from a walk. The important thing is not the surface I use to talk. The important thing is that everything enters the office first.

A thought does not become a task just because I said it out loud. Max has to decide what kind of thing it is: capture, memory, question, decision, build ticket, household operation, or something that should wait for my eyes. The office adds the context from the orientation layer, checks the manual, and looks at the log before anything moves.

Then the bridge prices it. Some things need expensive thinking. Some need a cheap build lane. Some need a clarifying question. Some need to sit in the queue until the right mode or moment arrives. When work does move, it comes back as a receipt, a decision, or a window I can inspect.

A normal loop

Capture

A chat, voice note, shortcut, or mobile bridge drops raw intention into the office. The system keeps source, time, confidence, and roughness instead of pretending every capture is equally clean.

Clarify

Max decides whether this is a thing to remember, a question to hold, a decision to frame, or work to route. Bad transcripts and fuzzy rambles should ask back instead of quietly becoming orders.

Route

The bridge turns the work into a packet: boundary, stop condition, effort level, model class, privacy rule, and proof required before anything counts as done.

Build

The factory works the lane. That might be a website change, a household-ops surface, a personal-finance tool, a field note, or a plan for something only I can decide.

Review

I get decisions, not tasks: options, tradeoffs, receipts, screenshots, or a clear blocker. I make the call where the manual says my hand is required.

Render

The result faces out through the right window: a shipped feature, a public note, a family operation, a work artifact, or a better rule written back into the company.

The next missing public surface is the bridge view itself: a side rail, a queue with safe dummy data, and mobile capture that shows how a thought moves from "I said this while walking" to "this is the thing the company thinks I meant." That is the workflow chapter still being built in software.

Open questionHow much of the day to day workflow can disappear without becoming illegible? I want the system out of my way, but I also need enough surface to trust what it is doing.

The technical reality

Inputs normalize into packets with source, timestamp, confidence, mode, privacy boundary, route, effort, model preference, and required proof. The bridge and side rail are the reader layer for that state: what needs me, what is moving, what is waiting, and what came back with receipts.

The company · The test

The test

The honest thing is that a lot of this has been aimed at itself. I have been using the machine to build the machine, and now it is starting to work for me the way I hoped it would.

The real question now is whether it is real: whether it helps when I point it at my life, my work, my household, my money, my attention, and the places where a system either carries weight or becomes one more thing to maintain.

That is the next phase. I am going to keep documenting the journey here as I test it in the open, with the mechanism public and the contents private.

InvitationIf this unlocked anything for you, or if you want to jam on implementing this kind of thinking inside an organization, I would love to talk. These are my favorite conversations to have. I think through conversation, and I am very happy to chat with anyone working near this edge.

The company · Glossary

Glossary

The words this page leans on, in the sense I actually use them.

The harness

Everything wrapped around a model that makes it useful to a specific person: the orientation, the rules, the tools, the memory. This page is harness engineering, documented.

Persistent workspace

The single place where the thinking lives and accumulates across every conversation and every model, instead of evaporating per chat.

Texture

The substrate under the words: posture, beliefs, the understanding already shared. What a message means, not just what it says. texture section

The membrane

The one rule of what you see here: mechanism public, contents private, and nothing about other people on their behalf.

The orientation layer

The current lens the company reads before it acts: what I believe now, what is already decided. orientation section

A lane

One clean build cycle in the factory: pick up work, build, test, return proof, exit. Disposable on purpose.

A receipt

The evidence that comes back with finished work. Nothing lands on a claim; everything lands on proof.

The night sweep

The factory working the queue while I sleep, so mornings start with decisions instead of tasks.

LifeOS

The working internal name for the whole operating system. operating system section