The more I dig into OMP, the more it reminds me of Emacs org-mode (https://orgmode.org/), and specifically its org-babel module (https://orgmode.org/worg/org-contrib/babel/).

I want to try using org-mode files as an interface to agents.

I create a new org file, and that starts a session.

A new heading shows up automatically with a code block of type "agent". Running that block just sends its text to the agent session.

While it works, the agent can create as many subheadings inside that block as it wants, write comments in them, add separate blocks, run them, edit files, call tools, and so on.

When the agent is done, it creates the next heading so I can type the next block.

You end up with a structured, executable playbook.

The file holds the whole session, every tool call and every detail, so you can reuse it as a re-runnable playbook.

I'm not sure what to do about forks, or whether they're even needed. The idea would be to roll back the agent's last action and continue from some earlier state. But that brings a pile of problems right away. You can't just fork the Claude session, you also have to undo the changes the agent made. More on that here: https://andysmith.ai/2026/Aug/20/a-programming-paradigm-for-spatiotemporal-composability/.

If I do the forking through Org itself, it gets muddy where the split is about meaning (by steps, or by logical sections) and where it's an actual fork.

So I could just not bother with forks. Or do it by making a new file that shares the same beginning with the end cut off. Or just use git the way it's meant to be used, roll the file back to the state I need, and keep going.

Even then, there'll probably be odd surprises around undoing the agent's actions. If the agent did something outside the file, the state I'm forking from doesn't know about it.

I've been listening to Gödel, Escher, Bach, and it feels like it's about exactly what I want to build: systems that describe themselves. You know those Escher drawings, the staircase that keeps going down but never ends, or the waterfall that pours down and somehow feeds itself back at the top. Those self-looping things, systems that describe themselves.

Languages that describe systems like this have a funny property. You can describe more kinds of systems in them than in languages that can't describe themselves, and the descriptions come out cleaner and shorter. LISP is one of those languages. It can describe itself. I don't really get why everyone forgot about LISP. It was built for AI in the first place, the very first AI language, about 70 years ago.

But there's a practical reason this matters for agents too: a permission sandbox. Say an agent wants to call a sub-agent, but the sub-agent has to be limited in what it can do. In normal languages that's almost impossible. You can't say: run any Python you want, except, say, listing a directory. The moment you give a sub-agent access to Python, it has full access to the system, it can do anything. Python and JavaScript just don't have a language-level sandbox. In LISP you can easily say: here are your operations, this one, this one, and this one. Think whatever you want, but the only way you reach the outside world is through those three. And the agent physically can't get around it. For corporate workflows that's exactly what you need. For personal ones it's probably overkill, but for corporate it's a must-have.

To me, all these IDEs and Claudes seem to have one basic problem: they don't work as a team. You've got your own context, your own tricks, principles, gates, everything you've set up for yourself. My context is totally different. The devs have a third one. And when we're building one shared product, each of us playing by our own rules, the question becomes: where and when is all of this supposed to sync up? And when the edits conflict, whose is right?

The simplest example is tabs versus spaces. Your agent always uses tabs, mine uses spaces. You commit code with tabs. My agent sees it's off from our standard and switches it to spaces. Your agent sees spaces and puts the tabs back. And this tug of war between agents goes on forever, even where agreeing should be trivial, just because my agent has my context and yours has yours.

My fix is drastic. The problem is that we're trying to boost a person with an agent inside the old processes: do the same thing, just faster. But that's the wrong goal. We shouldn't do the same thing faster, we should build new processes that weren't possible before and are now. To do that, you have to take the agent off the personal level and move it to the team level. All the agreements, the checks, the styles, the gates, the architecture, should live at the team or company level, not the personal one. At the personal level it's called character. At the team level it's called corporate culture.

What's left at the personal level is just a thin layer. I think of it as a butler. It knows you well, it knows your habits, it gets what you meant even when you didn't spell it out. Its job is to take the task off your hands, maybe flesh it out the way you would have, and hand it to the corporate agent system. It also manages your attention and your schedule: "hey, something urgent just came up, let's drop this and talk now."

The team work itself is a separate thing. It should be one corporate AI, not a bunch of personal AIs trying to sync their contexts over Git or out loud, which is inefficient. And it's not just documents and text, it's processes too, and processes are code. So somewhere there has to be a shared server where all of this runs and builds up. Taken to the limit, you get an AI company: not people boosted by agents, but the company itself as one big agent, or an ensemble of agents. And people in two roles: either they build and maintain the system, or they act as experts. When the system breaks, we say "this would be better done this way," which is how we train it. And there are still purely manual steps where you need a human: sending money, say, or approving something.

I've been thinking for a while about what I call a personal stream, and now I finally have a chance to try it.

The idea is this. There's an endless feed, like on social media. That's the visual version. And there's a second version: you put in an earbud, and it's like radio. Smart radio that just reads the feed out to you. At any point you can say stop, I don't get this part, let's look at it. And just like in a feed, you can comment on any item: I disagree with this, this one isn't quite clear to me.

I think voice is the most promising interface. You can do something else while it plays, walk somewhere, give your eyes a rest, and it just gets read out to you. And the stream itself can hold anything. Answers to your questions (you ask something, and the next items immediately rearrange around it). Passages from books and articles on the topic: someone already wrote about this, listen to a chapter. You could also add a screen with schematics and diagrams.

One thing that really grabs me is reading formulas out loud. Right now I'm trying to listen to a math book through an automatic text-to-speech thing, and it reads the formulas as a string of letters, totally impossible to follow. If my agent read them instead, it could say them properly, like a lecturer. Not letters one after another, but "B to the fourth power, times something."

It's hard to take in by ear, but it's a way of taking things in that's worth building up in yourself.

I'm thinking about storing the context of my whole life, every event and every reaction, as a graph. At first I wanted to call it a data lake. But experience lake is closer: everything you've built up over years.

The point of a lake like this is that you can open it up piece by piece. Say a company comes to you and says they want to train their models on how people react to some situation. Like what you feel when you see a half-built house. You can open just that part of your experience instead of all of it. Their models only learn from what you chose to show. It works the same way between people. You've fished for decades but never write about it anywhere. You meet someone who's also into fishing, and he's not sure whether it's worth bringing up with you. Then you just open that part of your experience to him. That's how trust and reputation get built between you.

But before you can even start collecting all this, you need a guarantee the data won't leak anywhere. A plain text file won't cut it. Steal it and you've stolen a whole life in one go. That's serious. It could leak from GitHub too. It doesn't matter who it leaks from, what matters is that it's your entire life. So the data has to be encrypted, and only decrypted on request, on demand, with a hardware key. That's hard, but if you bake it into the architecture, people will trust it a lot more.

I picture the storage itself as a separate, self-running system. Imports wired up from Apple Health and other sources, encrypted, backed up, maybe on a blockchain. It's yours, it's safe, and it runs on its own, independent of you and of your agents. You don't even have to spend any attention on it. You just know everything's in one place and safe.

I got talking with someone about collecting data on yourself. He was telling me how he logs the meals he eats through the claude.ai web interface and saves them all in one database.

I don't believe in collecting data on yourself through discipline. Discipline breaks. When you do something without really understanding it, without a big goal (and collecting observability data has no such goal by definition, the goal shows up later, once you've got the data and can pull something out of it), at some point you skip it once, and nothing changes. So you just stop doing it. That's why I try to collect data on myself seamlessly, with nothing to distract me, so it just happens on its own.

I've already pulled this off with video and books. I set up Jellyfin, BookOrbit for books, and I found an app that reads a book aloud in an AI voice: you press a button and it reads it out. Not perfect, it sort of has intonation but also sort of doesn't, but overall it's fine as a cheap audiobook. So everything I read or listen to gets logged: this book, at this time, for this long. When I'm working at the computer, that gets captured automatically too. All of it can be exported into one context database where you can see, by time, what I was doing when: reading a book, watching a show, working.

Next I want the same for my body. I'm going to drop WHOOP (they're great, but they don't share their data) and buy an Oura smart ring. That, the Apple Watch, and other wearables all feed into Apple Health, and from Apple Health into that same single database.

And in general, I think it's better (and more reliable in the long run) to collect data through a good app and pull it from there into one system, than to type it in by hand through a chat interface.

For what I eat, I could use Rayban smart glasses (though I don't know if they can stream), because having to snap a photo every time is discipline too.

The kanban I'm working on is mainly for communication between a human and an agent. Between agents you don't need a kanban at all. That part can be whatever. But for a person, moving little cards around a board is just handy.

The idea is this. You start a session with an agent. It does its thing, and at some point it figures out that it needs you. It can't keep going without you. So it files a task for you and goes to sleep. You read what the task says and you do it. And doing the task usually just means writing a comment, because the agent asked you something.

So in that sense the kanban isn't even for the agents, it's for you. It's a way to answer the agents' questions without losing your mind over how async they are, and to put some order to the whole thing. That's roughly how I see it.

I keep running into this problem on small teams where everyone uses AI.

Person 1 writes code with their agents, which lean on person 1's context. They commit to the repo. Then person 2 makes changes, with agents that lean on person 2's context.

The two contexts are different, because each one can carry that person's personal preferences. So the agents start from different assumptions.

The result is that person 2's agents can land on different decisions than person 1's, and start making big changes to the code from their own point of view. Then person 1's agents, on the next edit, put their own decisions back. This goes on forever and burns tokens for nothing.

A shared context for the whole team only fixes part of this. It sits on top of each person's personal context, it doesn't replace it.

I think the answer is systems like https://andysmith.ai/2026/Aug/15/the-company-as-a-system/.

In other words, a team (even a team of one, for personal projects) is its own thing: its own context, its own set of rules, and probably even its own infrastructure.

So instead of personal agents, you move to agents-as-part-of-a-team. They share one context, run inside a protected perimeter, and don't contradict each other. Usually that's some ensemble of different providers, and the company's AI architect decides exactly how they work together.

And personal agents (what everyone runs on their home laptops right now) are really just one interface into that team of agents. It should take your instructions (maybe filling in and clarifying what you meant) and send them off to run on the company's AI mainframe.

I'm reading (well, listening to) Gödel, Escher, Bach by Douglas Hofstadter.

The chapter on formal systems caught my eye, because you might be able to apply it to infrastructure.

The goal: infrastructure that's guaranteed to be secure.

The idea is to describe infrastructure as a formal system where the theorems are the set of things that count as "secure infrastructure".

Then we can set up the inference rules so that starting from infrastructure that's already secure, we only ever get infrastructure that's still secure. In other words, we never add a new security hole.

I've been chewing on this for a long time, but it used to be impossible: there are too many inference rules and they're too hard to build. Now, with AI, it feels a bit more doable.

I set up automatic publishing of my posts to a Telegram channel.

I decided to post them there raw, with no AI reworking. I called it brain dump. Same as on the site, I'll put down whatever's left in my head once everything else is automated. And something always is. You can't just think about nothing.

Now I write any post in discobrain, and it goes out to the site and to Telegram automatically.

These days every post publishes in Reach Post mode (Telegram added that mode not long ago).

I ran into a couple of problems:

1. Paragraphs don't get any spacing between them, so I had to add an empty paragraph in between. If Telegram changes the layout later, it'll all break and shift.
2. The title on these posts is really faint and gets lost, so I used bold text instead. I might switch it to a heading later, but for now bold fits better.

But the mode has some real upsides too:

1. No trouble posting with images, you can embed them nicely inside the post.
2. The post length isn't capped at 4000 characters anymore, you can go up to 32000.

At first I only wanted to publish the posts with images the new way, but then I changed my mind and made them all the same.

An AI agent like Hermes or OpenClaw can do real work out in the world, like writing code or filing bug reports. So it's tempting to use it for exactly that.

I see it differently.

To me, a personal assistant is an agent system that shouldn't do any of that outside work itself. Instead it orchestrates the other systems and gives you one interface to all of them.

A butler is a good way to think about it.

A butler doesn't clean the rooms, set the table, or cook the food himself.

He manages the people who do, signs off on their work, and gives the client one easy interface. The client doesn't have to talk to every worker or organize their work.

So a personal AI assistant is just a proxy.

Some people like to work in text (chat, or Obsidian), some by voice, some through boards. The assistant's job is to be right there and make it easy for you to work with all the systems around you.

With that in mind, you really want to keep the agent local and as close to the body as you can. To cut latency and reduce privacy risks.

And you have to watch that the agent doesn't do anyone else's work, just hands it off and takes back the result.

Of course, by then all the rest of the work has to be set up so the agent can assign it and accept it.

If you keep a careful tree of your context and reactions (https://andysmith.ai/2026/Aug/16/context-as-a-separate-stream-of-events/), you can use it as proof of competence.

It could even become a new kind of résumé.

Say I'm an expert in AI, and I also know how to build birdhouses. But for some reason I'd rather not make that public. Maybe it gets in the way of how I want to position myself.

Then life takes a turn. I need to build a birdhouse, and I've found funding. Now I have to prove I'm an experienced birdhouse builder. So I reveal part of my context and reaction tree. (You could just call it that, an experience tree, or an experience lake, like a Data Lake.)

The main thing is to avoid a leak. If I use ZK to reveal this data to someone, that someone can't then go and publish the proof. Especially if the fact that I can build birdhouses could hurt me somehow. (I'm mostly thinking about reputational risk here.)

The context tree gets collected anyway. The only question is how to store it and manage access to it so this works without any extra effort.

I've tried a lot of different AI interfaces: copilot, chats, console agents, bots in direct and group chats in messengers.

They all miss the same thing for me: async.

Right now I'm experimenting with kanban boards.

One board, four columns:

• Backlog: the task needs my attention. I take the first card, get into the context, write a detailed comment, and move it to ToDo.
• ToDo: the queue for the agents. As resources free up, an agent pulls a task into InProgress.
• InProgress: the agent works on it. It reads the context, breaks the task down for subagents, puts those on other internal boards (I don't touch those), does the work, and commits the code. If something's unclear, or the task needs a clarification, or it needs my attention some other way, it moves the task back to Backlog.
• Done: also needs my attention. I review the task. If everything's fine, I close the issue. If there are problems or something's off, I write a comment and move it to ToDo.

I went with Forgejo's minimal interface, but the setup would work on any kanban board with an API.

I caught myself realizing I've stopped reading the code an LLM writes closely.

Instead, I put my attention on everything around it: tests, observability, quality metrics.

That makes DevOps far more important. You have to catch a problem as early as you can and keep it off prod. Tests have to work, always. Metrics and traces should flag a problem as early as possible.

One way to build context-reaction pairs, while keeping infinite context in mind, goes like this.

Call everything context: everything I see, hear, and feel. Everything around me is context. Split it into quanta (events) and write them to a separate append-only log. That's pretty hard, because a lot of what I see and hear isn't easy to digitize. Maybe wearables will help with that.

Reactions are the opposite. They're what comes out of me: what I say (publicly or privately), what I write, or whatever I put out some other way. Written stuff is easy to record. It's basically already being recorded anyway. For spoken stuff, wearables again.

You don't need a separate link between a reaction and its context. Every reaction is connected to all the context events near it in time, so you can just use the clock to sync them.

A reaction can be tied directly to one specific context event, or a few, like when I answer an email. But the surrounding events always shape the reaction too. Some rudeness in a reply, say, might come from some outside event, not necessarily from what was in the message I'm replying to.

Which brings up a separate problem: different parts of the context can carry different weight. One context event should be marked as "strongly influential," another as "barely influential." I don't know whether you can label the input context like that when you train an LLM.

I'm building on my idea for a personal EDU stream (https://andysmith.ai/2026/Aug/14/a-personal-public-edu-stream/).

The idea is a universal voice assistant where one of the modes is learning.

This assistant can also run all my sessions in Claude Code (and other agents), answer email, and do everything some Hermes-like thing does. Voice is just one of the interfaces.

It could look like this. I hop on Discord (or some other call app) and spend 100% of my time (or close to it) on a call with the agent.

The agent can read my feed out loud (how that feed gets built is a separate discussion from the voice part) and collect my feedback on what it's reading.

In the simplest version, it just reads out loud the books and articles I've picked (and it's picked).

I can interrupt it at any point and give feedback or ask about something (and then the agent drops what it was doing and talks through whatever I don't get or find interesting).

At any point I can also say I've had a thought and dictate a post.

Or ask it to do some task.

Basically, I want to make voice one of my main interfaces for work. Or at least lean on it hard. And give my eyes a rest now and then.

I'll put together the architecture for all this in the next few days and see what's already out there.

Instead of forcing old models onto agent work (where everyone runs their own agents and automates their own piece), we should aim to build the company as a set of agents that run all the time and talk to each other.

In this setup, people (backed by their own personal agents) either build and keep the system running, or they're the experts who make the call in hard cases. Which really means they're the ones training it.

The main thing to get here is that the company isn't the set of communication tools between personal agents. It's the agents themselves, and the networks of communication between them.

I try to read not just through agents, but the original sources too.

I want to read everything in one place: PDF papers, web pages, books.

I used to do all of this in Zotero (annotations too), but the problem is the server is closed and paid, and WebDAV plays badly with the API. I never managed to give agents proper access to add a new source over WebDAV.

What I want is simple to state: an open-source backend to store the library (with an API for adding sources, plus annotations and reading stats), and a nice iOS client for the actual reading, with offline support.

Turned out to be a bit trickier than that.

First I set up Kavita (https://github.com/Kareadita/Kavita). It does OPDS, so a ton of reader apps work with it, but it doesn't sync reading progress or annotations, so it's out. I want to see the stats.

Then I tried BookOrbit (https://github.com/bookorbit/bookorbit). Pretty much the same features, but it can also sync progress and annotations over the KoReader protocol. Paired with the Readest reader, it does what I need. It can also read text out loud (it calls Azure's AI, though I still haven't figured out who's paying for that. It's free to use.)

When you put together a history of active actions (https://andysmith.ai/2026/Aug/14/a-stream-of-reactions-as-a-user-profile/), the context is all of life.

Every reaction is the sum of everything that happened in my life up to the moment it happens.

How do you capture that to build a training set?

One option: attach the most relevant slice of context. The email or message you're replying to, say.

Then link to another event that holds the start of the context.

You'll never get the full context this way. It's infinite. But something already beats nothing.

I write blog posts, off the top of my head, about whatever I'm thinking about.

Agents post to social media as me, but they generalize my writing up to some known model or theory.

Then they look at those theories through my own writing.

The point is that I'd actually want to read the results. My own ideas run through these transformations and auto-research.

And if I find it interesting, other people probably will too.

How ethical is this? It's basically auto-SMM that I've handed my social accounts over to, and I'm not hiding that, so I'd lean toward yes, it's fine.

I need to check how well it lines up with the platforms' rules. Maybe I have to put an "AI-generated" label on everything, or otherwise clearly mark that the content is generated.

I look at markets from first principles: what systems are in there, what roles exist, and how those roles get pushed through their lifecycle.

From there, if I want to make money, I have to pick a role and play it well.

Can I create a new role? Or is "find" the better word here? The role already exists, and maybe someone's already playing it, but I'll find it, name it, and that's where my edge over everyone else comes from.

Is this the only model, or are there others?

Thought through an idea from https://andysmith.ai/2026/Aug/13/training-a-personal-llm-on-what-you-actually-do/ a bit more.

The thing you store and process isn't an "event" or an "active action." It's a reaction to some stimulus. The stimulus here is context, a description of the state of the world around the user. The reaction is what the person does in that context.

For example, the context could be a specific social media post, a song, a YouTube video, or even some situation in the real world. The reaction: scrolled past it in 0.1 seconds, turned it off after 2 seconds, skipped ahead, liked it, wrote a comment. Ideally you'd also ask the user why they didn't like the video, but that's probably not realistic.

Anyone can collect and store their own interest profile on their own, as a stream of reactions to one context or another. You could offer a handy, secure tool for this and sell it.

A person's digital shadow, which is basically the sum of these actions, is the most valuable thing they have. You can't leave it up to corporations and store it who knows where (with the risk of a leak or losing it).

It's worth thinking about launching an L2/L3 blockchain that stores all the reactions. Each event is stored in a ZK-Rollup.

You could also build in interfaces for partial disclosure. For example, a company is willing to pay for all the reactions to some specific content (a post, say). It posts an offer, and people can accept it and disclose their reactions for some reward.

And of course, you can train your own personal LLM on this to predict future reactions as accurately as possible.

Reading tons of text from AI agents wears my eyes out, so I've been thinking about other ways to interact with them.

The obvious one is voice.

The simplest version is just a voice assistant that answers questions, but that's not interesting. The default ChatGPT apps already do it.

Taking the idea further, I landed on wanting a kind of voice stream, like a radio, that I could listen to on walks or at the gym.

I think this stream should be educational first, which is what would let it be public. Nothing about my closed projects (those probably need a separate, private stream), but a lot about my open-source services and public ideas.

The stream should be unique to me. It should account for my preferences and interests. But it could also be interesting to other people, the ones who share those interests.

I'd want to shape the stream somehow, to give feedback about what I like and what I don't.

Technically this could be a Discord channel that I join, with an agent sitting in there too, telling me interesting things that matter to me right now, maybe playing YouTube videos or something like that.

I could give feedback by voice, or, say, post on Twitter/Threads with the agent's tag. And it would parse that.

Anyone can join and watch my stream (the value is in the choice of information based on my feedback), but only I can give feedback.

The recordings of the streams might be useful on their own, so maybe they're worth publishing somewhere.

You could also turn this into a product, so anyone could start a channel like this for themselves. For example, the open channel free, and the private one behind a subscription.