I start agents, then step away

Introduction

I can normally start around ten agents, then go have a rest. I might go to the gym, do house chores for ten minutes, or look out of the window to rest my eyes. The work keeps moving while I step away from the computer.

I can take my phone and keep responding to agent prompts for a while. Bigger debugging sessions, releases, and checking data fidelity bring me back to the desk. Those need more attention and a larger view of what is happening.

That is why this setup works for me. It gives me room to move between focused work and a break without having to stop every task. The paper illustration above represents the connection between tasks, a phone, and review; it is conceptual artwork. The workflow on my homepage shows the actual tools.

My attention moves between tasks

Around ten agents is a description of how I work, not a target everyone should copy. Starting them is only useful when they have enough context to make progress while I am doing something else.

I give a task its scope, the relevant project instructions, and a description of the result I want. Agents work in tmux, where I can return to their output and continue the same conversation. ClawTab's daemon architecture keeps the terminal session separate from the desktop interface, so the interface can close while the work continues.

The separate sessions shown here let me return to a particular task. ClawTab Remote lets me follow the same work from my phone. I can deal with a prompt and let the agent continue, then come back to the computer when the result needs a closer look.

What needs my attention	Where I handle it
Agent prompts and short follow-up	Phone or computer
Bigger debugging sessions	Back at the computer
Releases	Back at the computer
Data fidelity: whether the data is accurate and preserved	Back at the computer

Being able to answer from my phone does not make that time a complete break. Sometimes I keep following the work; sometimes I put the screen down and rest my eyes. The useful part is having that choice.

Spare compute makes deployment an ordinary step

I have capacity available on a dedicated root server. That lets me deploy quickly without first worrying about where a new service will run. The hosted parts of my products use k3s, with deployment, storage, and monitoring shared across projects.

The distinction matters: I have room to run the services, while reviewing a release still needs my attention. Spare capacity removes a recurring infrastructure decision. It does not tell me whether the code or the data is correct. My compute setup describes the shared infrastructure.

I keep code changes in separate local Git worktrees. Git supports multiple working trees for one repository, which lets each change have its own checkout. When it is ready, I check it, commit, merge, and clean up. That keeps the work understandable when several tasks are underway.

One computer is not enough for how I work

My local journal, CRM, browser scrapers, and agents are separate pieces. I use cloudscale and ClawTab to keep them connected. Otherwise, useful context and running work would remain scattered across machines.

Each node keeps a ClawTab agent running. If one node fails, I can pick up my jobs from another. I think of this as related to Kubernetes, but for agent work spread across machines around the world. That is an analogy about where work can run and how I can return to it, not a claim that terminal processes migrate automatically or that every piece of state survives a failure.

Part of the setup	What it contributes
Local journal and CRM	Work context and relationship context
Browser scrapers	Information collected from the web
Agents on connected nodes	Places to run and pick up jobs
ClawTab and cloudscale	Connections between the separate pieces
Dedicated root server	Available capacity for hosted services

The important property for me is that the work is reachable from more than one machine. My computer is one place to interact with the system. It does not have to be the only place where useful work exists.

For browser tasks, bmux gives agents access to persistent browser sessions through a CLI. They can inspect the page they are changing, and I can review the result in context. The terminal, browser, and remote connection each support a different part of the task.

My experience is the part another builder cannot download

If everyone has access to increasingly capable intelligence, what makes my output different? My bet is on the experience I bring to the work and the personal choices I make in my products.

Garry Tan discusses a related idea in YC's “Own Your Intelligence”: a model becomes more personally useful when it can work with context accumulated from your own life and decisions. The section around 12:29 describes that personal library. That connects with how I want to use my own working history.

Agent sessions, browser history, emails, and journal notes can form a searchable catalog. An agent can look through it for a question I investigated, a decision I made, or an approach I already tried. That gives a new article or product a starting point grounded in my experience.

For example, instead of asking for a generic article about browser automation, I could ask an agent to find the problems I encountered while working with browser sessions. Then I could select the examples that explain why I made particular choices in bmux. This is an example of how I want to use the catalog, not a claim that every source is already indexed.

The same applies to this article. A list of tmux, worktrees, and servers describes the tools. Saying that I start agents and go do house chores explains why I put them together. The experience supplies the point of view.

Collect information, then make it useful

I expect scraping and knowledge bases to become more important as creating content and software gets easier. There will be more information to work with, and deciding what deserves attention will matter more.

A useful catalog needs a way to find relevant material, understand where it came from, and distinguish something current from an old attempt. Collecting everything is only the beginning. I want agents to help filter it into useful content and applications that other people can enjoy.

That also means keeping the difference between private context and public material. An email can help me understand a problem without becoming something I publish. A generated account of my experience should remain traceable to the actual work rather than filling gaps with a plausible story.

Products can support each other

As I build more products and websites, I can connect them through useful references and shared knowledge. A problem in one project can inform another. An article can explain a tool's design, and a product page can point to the article for the reasoning behind it.

Trend Seeker works with product research. ClawTab helps me run and follow agent work. bmux gives that work access to the browser. This site is a place to explain what I learn from using and building those pieces. Those are real connections a reader can follow.

I want those connections to grow because they help people find something useful. More websites alone do not produce that result; each one needs to contribute something worth connecting to.

The setup gives me space to step away while tasks continue. My role is still to choose the work, return when it needs judgment, and bring what I have learned into the next thing I build. That is the personal part I want to preserve as the agents become more capable.