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.

I'm reading about Gwern's Guardian Angels (https://gwern.net/guardian-angel).

The idea is that instead of using general LLMs (which are trained to be useful to everyone, hackers included), you train your own personal LLM.

Instead of putting some bit of info about your personality into the context (which is never complete by definition), the idea is that the "persona" gets derived from the data.

The data is an append-only log of text editing actions. The model predicts the next action and suggests it to you. The success test is: the model wrote the whole text from the first paragraph.

Right now the author's idea is to digitize his data as a stream of actions. He uses Emacs, so he gets this out of the box. There's a bit more detail here: https://gwern.net/nenex.

Training a separate model for each user (and retraining it on new data on top of that) is expensive, so you'd have to use a simple model. If the model struggles to predict, it can ask a more expensive general model, ask the user for feedback, and fine-tune on that feedback.

This is a cool thing. As an Emacs fan I want it, and not just for text and code but for any kind of activity.

And there's another conclusion here that I agree with. Identity is exactly the actions we take. It's worth collecting them now, so there's something to train on later.

The format, and how you capture, safely store, and use these actions, matters a lot too.

The classic SaaS business model is this: the user hands their data over to a provider, and in exchange they get an easy onboarding.

The risks are obvious. The user doesn't know how the provider handles their data, and can't do anything about the risk of leaks. The provider can also lock the account without warning, or just stop existing, so there's a risk of losing your data forever.

The opposite model is open source, where the user sets up their own servers, installs the software they need, spends time maintaining it, and takes care of backups, updates, and security themselves.

The first way wins on scale. People seem to not care about the risk of losing their data.

I don't get it. Is security and owning your own stuff really of no interest to people, and nobody even thinks about it? Or is it a conscious decision, and the point is that running and maintaining your own open source cloud is too complicated and expensive, more than the data is worth?

And how much sense does it make to offer people a service for setting up and maintaining their own stacks for AI agents and their environment?

I've used PostHog for years as an open source alternative to Google Analytics. Today I read the docs and realized it's a deeper tool that flips the whole approach to infrastructure monitoring.

Traditionally the technical data about the state of a system (logs, metrics, traces) lives in a separate engineering system (ClickStack, Grafana LGTM, DataDog, etc). In that model, the system is the center of gravity. Monitoring answers questions like "is microservice X working correctly" and "is there a problem with the database".

For an engineer, an error is a line in a log and a ticket in an issue tracker. For the business it's lost money and lost customer loyalty.

PostHog builds observability around the customer instead. Every event (including cases where something is broken), every log entry, every trace gets tied to a user session and stored right next to the business metrics.

That inverts how you look at infrastructure, analytics, and monitoring. The system exists to serve the customer, not the other way around. That shift takes some getting used to. For years we've measured service uptime, not the customer's path.

Now the cost of an incident is obvious. A broken payment button isn't a line in a log, it's the sessions that dropped off at checkout, and you see it in the same interface where you look at conversion.

You shouldn't treat PostHog as a replacement for your technical observability stack. Some internal events aren't directly tied to user actions, so PostHog is an awkward place to look at them. But alongside the technical stack? Absolutely.

What to do about tags on a blog.

The point of tags is to highlight the topics I keep coming back to.

One problem with tags is that they're unstable. They depend on how deep you've gone into a topic.

At first, when I'm just starting to dig into a new topic, say AI, every post gets the same high-level tag: AI. Then as things get more specific, LLM shows up, then ollama, then mlx, and you can keep going deeper forever.

But if you start with detailed tags from the beginning, you end up with a huge pile of empty tags, each one marking a single post. That's not useful. It's easier to just use search.

For my blog I set up automatic tag generation for each post, based on the text.

Each run starts from scratch, with no hint from a global tag dictionary. That keeps it from drifting toward the tags I used in my earliest posts.

The problem this creates is duplicate tags. When the same thing is written slightly differently, like agent and ai-agent and ai-agents all meaning the same thing. With independent runs and no hints, you can't fully avoid that.

For now I've left it as is. Later I'll add a periodic merge of tags, or some extra tooling to classify them and pull out common themes.

I needed to transcribe a call between two people.

I looked for something ready-made and didn't find anything that fit. I wanted it to just work in one click on Apple MLX, split up who said what, and run LLM post-processing on top (to strip out the mumbling and filler words).

I decided to throw together a small Python script, and as usual it grew into half a day of debugging (which is why I don't like vibe-coding my own tools).

But I did get to do a quick bit of research on the state of speech recognition.

For the model I tried whisper-large-v3-turbo, but it works badly, it actually makes mistakes. Right now I'm trying whisper-large-v3, and if it's no better I'll switch to parakeet, which from what I can tell works really well.

For diarization (figuring out who said which line) we tried a bunch of options:

• Sortformer didn't fit in memory on anything over an hour, and once we chunked it, it started glitching and counted 4 speakers instead of two
• sherpa either split it into too many speakers, or collapsed and gave all the text to one, basically it glitched too
• we tried a homegrown solution: cut on pauses and compare by embeddings, bad. either our voices turned out to be the same, or the embedding algorithm is bad. or maybe the voice doesn't factor into the embedding and the meaning was pulling the coordinates around
• pyannotate seemed to work best of all.

But there's a problem with the mlx + pyannotate stack, they need different pytorch versions, so they don't run in the same venv, I had to split them.

On top of that I bolted on the LLM cleanup, and got a more or less readable result.

Now I'll try to clean it all up, polish it, and open-source it.

While coding it, I forgot what I needed it for.

I figured I'd look into how speech-to-text is doing these days.

Locally, I use Handy for input.

I tried comparing a few tools, like openwhispr and wisprflow. Handy isn't the most feature-rich of the bunch, but the fact that it's free, open source, and runs locally wins me over.

Compared to wisprflow, for example, it's instant. Because the request doesn't go anywhere, it's processed locally.

Compared to openwhispr I didn't notice much of a difference, except that it's free.

At first I thought the recognition model alone wasn't enough and you'd need LLM post-processing, but it turns out it's totally enough. LLM post-processing adds a lot to the processing time, and the quality only goes up by about five percent.

Worth noting though, I don't need any text-editing features, meaning I need the text typed out word for word. If you want a transform option, say when you dictate something and the result gets run through some prompt, then Handy obviously won't cut it.

But for my cases it's more than enough.

In the age of AI, it's really tempting to automate blogging, build content factories, all of that.

But you have to split this by what you're writing for.

Marketing copy you can and should write with an LLM. The LLM makes it better, tunes it to the right audience, checks for mistakes, and so on.

But the stuff you write for yourself, you should write yourself.

It doesn't matter how deeply the work gets automated, how many teams of AI agents I orchestrate, what percentage of the work is automated, or how deep the agents are in my work.

The thoughts in my head stay. And they need to be made explicit (written down, and ideally published).

Yes, the scale of the thinking goes up. I used to think like a developer. Now I think in bigger categories: like a manager of a team of agents, like a founder of a company of agents.

The categories in my head are different, but that doesn't mean pulling those thoughts out and putting them on the page can be automated.

So my blog stays written from my head. Sure, the thoughts will sometimes be naive, sometimes wrong, sometimes half-polished. But they're mine.

That's how I split my own thoughts from the derivatives.

And the derivatives, the ones prepped and made interesting for specific audiences, those can go out on social media. That content factory is the one I'll have to build for myself (and maybe I'll turn it into a product).

I spent a few hours today and yesterday working out a strategy for social media and being public.

I want social media to be a nice storefront, showing only the good trail. But what I write is raw thoughts, from the angles I actually care about.

I ended up landing on a split between "author-based" writing and "reader-based" writing.

Reader-based writing is aimed at the reader. It solves some problem the reader has, it's interesting (otherwise the reader doesn't subscribe).

But for me, as the author, the raw thoughts are the interesting part.

The first solution I came up with was discobrain, a private notebook built on Discourse. Raw thoughts go in there, and I pull the "quality" posts out of it.

But then I remembered https://simonwillison.net/ and got inspired to publish raw thoughts on my site instead.

This means I have to keep an eye on some minimum level of quality, but it also lets me publish less polished stuff (nobody sees it unless they go looking for it).

And there's still value in it. Maybe at some point I'll need to link back to some raw thought or idea.

And on top of that, I don't have to filter by interest, because there are no subscriptions on the site. Nobody gets bothered, nobody unsubscribes, and no algorithm breaks if I post something irrelevant.

MCP is now used everywhere, and some products exist only as MCP servers. Some of these MCPs contain dozens or even hundreds of tools, and that creates a real problem when working with them.

The problem

The manifest of such an MCP is shipped in every LLM call, which means token usage grows proportionally with the size of the tool catalogue. The cost of running an agent system that depends on these MCPs grows accordingly. Prompt caching lets you reduce that cost (see IBM's overview and Anthropic's documentation), but it doesn't solve the problem of context window pollution.

There's also a defocus effect: a weaker LLM can struggle to choose the right tool from a long list, and that affects the quality of the result. The Berkeley Function Calling Leaderboard (BFCL) measures function-calling quality directly and shows that smaller models visibly degrade. ToolLLM frames the same regime as a learning problem: how to teach an LLM to work with 16K+ APIs.

The root issue is that the full information about every tool is sent on every request — while in practice only one or two tools from the entire list will actually be used.

An optimization

This can be optimized. Suppose we have an MCP for working with notes, and we want to implement two basic tools: create(text) and find(keywords). Instead of implementing them as separate MCP tools, we can expose a single one: notes_mcp_call(method, params). Then we'd invoke them as call('create', ['Hello, World']) and call('find', ['notes about emacs']).

Effectively, this is untyped RPC dispatch on top of MCP, whereas the conventional approach is to expose each method as its own typed tool. Naturally, this isn't a silver bullet — choosing one approach over the other is a real architectural decision for the MCP developer. The proposed approach pays off most when the number of tools is genuinely large. And for dynamic MCPs, where the set of methods isn't known ahead of time, it's arguably the only viable option.

The discovery problem

With this approach, a discovery problem appears immediately. The LLM has to learn somehow what methods this MCP exposes — but at the same time it shouldn't receive the full list of tools all at once.

So we also need a service method, help. It can be implemented as call('help', ['create']), or as a separate MCP tool.

Regardless of how help is implemented, it can operate in several modes.

The first mode is keyword search (or semantic search). The LLM asks the MCP something like "how do I create a new note?" and gets back a list of tools with their descriptions, parameter lists, and result descriptions. This is very easy to implement, but it requires maintaining semantic search infrastructure, including embedding the incoming queries. There's a bigger issue, though: building a complete map of available methods is hard for the LLM, because it doesn't know all of the MCP's capabilities — and so the discovery goal isn't actually reached. The model has to already know what it needs from the MCP.

The second mode is FSM-style discovery: help ships wiki-like documentation with cross-links. help without parameters returns a general overview and links to other pages. The LLM reads the wiki sequentially and assembles information about all the pages. This mode can be combined with search; it enables real discovery, but it requires extra effort from the MCP developer to maintain that documentation. As a side note: nothing stops you from implementing just a single FSM state with the full list of tools — in that case the mechanism behaves very close to the default MCP behaviour.

The final design

So the MCP manifest ends up containing two tools: help and call. The description of call should include the call format, instructions on how to use help for discovery, and optionally a description of the most frequently used methods — so the LLM doesn't have to go through help for every little thing.

What already exists

Before building this ourselves, let's look at what already exists in the industry.

Anthropic implements dynamic tool loading in its own products through tool_search, but this doesn't work in other vendors, so it can't be used as a universal pattern.

There's a draft standard proposal, SEP-1821, which extends the MCP standard with keyword search. This is partly what I need, but it doesn't enable flexible FSM-style documentation.

Speakeasy implements a very similar pattern in their tool Gram (see their blog post and the documentation).

I've been reading Anthropic's research on the problems with AI assistance when acquiring new skills (arXiv paper).

The hypothesis: AI accelerates your work where you're already an expert but hinders you from becoming an expert in something new. If you fully delegate tasks to AI, you start to get dumber and eventually become obsolete.

At first glance, this contradicts my post on autonomy with acceptable quality, but it doesn't. In that post, I was discussing autonomous task completion, not learning something new. I set the tasks myself, which means I already have some understanding of what needs to be done and how to evaluate the result.

But what do you do when you lack that understanding? How should AI help you learn when it always wants to do everything itself?

The research suggests these approaches:

1. Discuss conceptual options but write the code yourself
2. Generate code and ask for explanations

The key point: you need to put in the effort, to think. That's when learning happens. If you just mindlessly delegate task solutions to AI, you won't learn anything.

My Approach

I usually take a different path when learning something new or building fundamentally new (for me) systems. These are tasks I can't yet fully delegate to autonomous AI:

1. Problem formulation: Define what needs to be done and how to evaluate the result
2. Research: Gather all possible solutions, existing technologies, tools, and practices. Compare and choose
3. Architectural decomposition: Together with AI, I build an understanding of how the finished system will work. It's crucial for me to actually understand what the result will be because I'm responsible for the decision made and implemented. I'll need to review and accept the result. This is, in my view, the key difference from mindless vibe coding. Without this understanding, there's no way to take responsibility for the outcome, and the result may or may not work out
4. Documentation/tests preparation based on the discussion above. AI formulates, I carefully reread these documents and make many changes. This is where my understanding and AI's understanding synchronize
5. Writing code: Here I mostly trust the AI. I only review the most critical parts, but I believe verification should be automated through tests (including architectural ones) and possibly other methods (formal verification)
6. Verification: Automated through tests
7. Acceptance: Still manual, but this needs to be automated too
8. Debugging: Automated by AI, but it's important to engage rather than just copy-paste errors. I always require descriptions of error causes and read them to understand what actually happened

After going through this cycle for the first time, I can extract this class of tasks into an autonomous solver that will do all of this next time without me.

Understanding is the key in this process. Without understanding, you have problems.

Is Shallow Understanding Really a Problem?

Maybe it's becoming the new normal? Maybe I'm the odd one? After all, Anthropic didn't put an abacus in the header image for nothing. Who knows how to use an abacus in 2026? Who even remembers what it is?

Building AI systems to work reliably is also a skill you can learn (including experimentally), putting in effort and making mistakes. So this also needs to be done, which is exactly what I'm doing and describing in this blog.

But as usual, the truth is somewhere in the middle. Both matter.

When actively using Claude Code in manual mode, I always apply the same technique. I keep sessions as short as possible. I set a task, get the result, close the chat. If I realize I need to return to the task to clarify something, I do so via claude -r.

This workflow creates a need to save information between contexts. At the end of each session, I ask Claude to summarize and format a short summary of the session outcomes, which I then publish to the issue tracker for that task. I also ask it to update documentation, tests, architecture decisions, and CLAUDE.md to keep all descriptions synchronized.

I recently heard the opposite recommendation: do everything in one session, never close it. The guy complained that his tokens were flying away catastrophically fast, but when I suggested keeping sessions short, he said someone had recommended doing everything in one session.

In that case, the context contains not just what you need (the things you deliberately identified as important and placed in CLAUDE.md). It contains absolutely everything that was discussed, and half of it gets lost anyway. This is clearly an inefficient way to interact, which that guy discovered in his own wallet, but he refuses to believe the obvious because faith in an authority's words turned out to be stronger.

The primary metric I use to evaluate my autonomous AI systems: autonomy of work with acceptable quality of result. This seems obvious from the name "autonomous," but until you articulate it explicitly, it's not.

I see people around me setting up multiple monitors to watch several parallel Claude Code sessions simultaneously, constantly tweaking and running from one to another.

I believe this approach is fundamentally wrong. Context switching in the human mind is an expensive operation. Very expensive. Frequent task switching is exhausting, regardless of what anyone thinks or says. There's research on this: The Cost of Interrupted Work, Executive Control of Cognitive Processes, Brief Interruptions Spawn Errors.

So my job as an architect of this class of solutions is not to "do as much as possible with AI," and not simply to "efficiently burn tokens," as I thought before (see also From Solo Sessions to Agent Orchestras). It's specifically to ensure autonomy with acceptable quality.

That means I need to ensure predictable and repeatable results with minimal effort on my part.

I don't measure how many tasks I did with AI. I measure how many tasks AI did without my help. Of course, it's not entirely accurate to say "without my help" since I built the system that enables it to work effectively and autonomously. But that's exactly the point.

This is about the extent to which my solutions are AGI.

My hypothesis is simple. The recipe for success is to offer something simple and familiar (lowering the barrier to entry) and add value on top of it. Products that work on interfaces users already understand take off. Products that completely change how people work don't.

Consider these examples.

Cursor is VS Code, familiar to everyone. You don't need to radically change how you work. Just tweak your workflow a bit.

Claude Code is a terminal that every developer already knows how to use. AI-powered development (the value) is built on top of it. Developers don't need to get used to a new interface. The barrier to entry is minimal.

Such products don't require users to invest significant time changing their process. That's the key. This is the quality you must preserve when building your own product.

And there are thousands of examples of products that force users to work differently with their calendar, their code, to change all their daily habits. They don't take off and never will.

If using my product requires the user to perform many actions and learn new things, meaning they must take a very wide step from their current state (not using my product) to the target state (spent time, uses the product, receives value), then even if the benefit is obvious to them, they'll likely give up without even trying.

However, once a user takes that first step, they'll take subsequent steps with much more enthusiasm and commitment (because they already feel the value).

This is what you should always keep in mind. Simple beats complex. And something simple is better than nothing at all (see Done Today Beats Perfect Never).

Many small steps beat one big leap.

Yesterday all channels were buzzing about Clawdbot. I decided to install it and give it a try.

I liked the concept. Following my thinking from Product Over Technology, I always consider the product concept and how to sell it first. The execution is not great, but that's not what matters. What matters is that it's generating hype (meaning it sells) and it works well enough.

What I fundamentally didn't like was the lack of a platform approach. No separation of important and unimportant. No core versus everything else. This led to having to think about everything during installation. Network configs (Tailscale), provider settings (though you could reuse what's already in ~/.claude/), plugin sets. I have no idea which plugins to enable right now. I haven't even decided what I need this for. I want to try it quickly and move on. In some places, I noticed NIH syndrome (Not Invented Here), with vibe-coded solutions instead of existing tools.

Because of this, the whole thing looks like a super over-engineered solution tailored to one specific person (the developer), ignoring the fact that different people need different things.

What I Would Do Differently

I would extract the core that absolutely everyone needs. Which I actually did. My Capsules are exactly about this. Then I would let the bot grow and develop itself.

This actually looks like a solution to my problem of agent interaction in Capsules. Instead of some unified supervisor orchestrating everything, I can let agents self-develop and interact with each other.

To demonstrate how Capsules work, I could launch my own personal assistant bot (similar to Clawdbot) running on Capsules with my own vision. In my vision, the bot-assistant doesn't create other systems itself. Instead, it provides communication between the user (the botlord) and other agents. And possibly other people through their assistants.

I see the core as super minimal. Just a chat through which you can give commands for self-improvement. Through this chat, you configure the bot itself. Self-development. The goal is to get a working companion in seconds and then tune its capabilities over time, including various access interfaces.

This resonates with my idea to use Nix for describing Capsules. In this case, the bot can literally write itself.

My hypothesis is confirmed: Clawdbot takes off because it uses standard familiar interfaces (Telegram, Discord) and adds value on top of them. The interface matters. I expanded on this in Small Steps Beat Big Leaps.