Bots

One thing I've learned in the past month: agent labor scales, but human attention doesn't.

I've spent a considerable amount of time over the last few weeks playing with both Hermes and Grok Bot. I find them both incredibly interesting, and I actually see an increase in my productivity every day.

I make a point of keeping both bot platforms synchronized in terms of the bots that I've created for them. Whenever I make a change in one, I reflect that change in the other. That enables me to spend a few days with one platform and then a few days with the other platform, and then see how they perform, what their limitations are, and the quality of their output.

The power of agent platforms

Now I should take a step back here and describe for you my experience with agents over the last several months. A while back, I created my own agent server platform. This was a response to OpenClaw, which I found way too complicated.

My Agent Server would run as a macOS menu bar app in the background of your Mac. It would use claude -p to call your Claude (not an API call), allow you to set up environment variables and API keys so not everything had to be a token-consuming MCP call, and gain access to your browser, files, and content.

Agents were defined as Markdown files, of course. Each agent had a robust security model in its YAML front matter, which dictated what it could and could not have access to. It also had capabilities for watching files, listening to webhooks, and communicating via Slack and Telegram.

Agent server had an immediate productivity impact. Every morning, I would receive a focused list of things to work on. My employer is remote-first and async, so a big chunk of this list were items done overnight while I slept or was otherwise engaged. Over time, as Slack, Notion, and Linear embraced more MCP and CLI search, my agents improved with the better context available to them.

Today, none of this is impressive. Everyone on the vanguard of the technology does the same, and Slack even has features like "Today" built in to it that do it for you.

As a result of my commitment to my agent server, my agents started getting more sophisticated. I programmed them to analyze my work and suggest ways for me to improve. I asked them to ingest copious amounts of leadership and management training and critique my replies and methods daily. My agents became a poor man's career coach.

Most recently, I have agents that listen for webhooks or poll information in Linear and Notion so that when I am mentioned in work or assigned issues, the first draft is pre-built for me and put into Notion. I created a specific "Agents" Notion database that is displayed as a Kanban board so I can see work that has been drafted for me, work that I am making progress on, and work that I have completed.

The agents have gotten more complex and more involved, and they've now outpaced my ability to supervise them.

Designing people organizations

Let's take a step back for a moment and talk about how I design organizations. As a 35-year veteran of developer marketing, I have seen more than my fair share of re-orgs. I've watched organizations flow around functional areas, products, leaders, and so on. Marketing may one day be a central organization under one powerful leader, or it may be broken up so that product marketing lives with product, growth marketing lives on its own, brand with comms, and so on. A central organization has the advantage of coordinated planning, but at the expense of speed and agility. A distributed organization can gain speed and focus, but you will often see teams clobber one another.

Good leaders can overcome both, of course. I live for cross-organizational and cross-functional collaboration. My brain gets special joy out of connecting disparate work streams and watching them flourish. So, for me, distributed teams give me speed and my personality gives the organization coordination. Putting me in a rote, centralized organization is oil and water.

As we think about how we organize our bot armies, we can take cues from successful people organizations. Many executives, including nVidia's Jensen Huang and Amazon's former CEO Jeff Bezos, famously do not do 1:1s. They want to know when their direct reports have issues that need to be escalated to the CEO level, but otherwise leave the business to be functionally run by their lieutenants.

Organizing your bots

I've been watching a lot of discourse on Twitter about how people have chosen to organize the bots in Grok Bot. Many of them take an approach in which they create a "chief of staff" bot with whom they interact primarily, and who then delegates work to several sub-bots. This was my first approach as well.

I created a Chief of Staff (who I called "The Skipper") and individual bots focused on various functions.

This was helpful when conceiving the work I wanted Grok Bot to do for me, but it quickly broke down as I added new work. I lost track of who was doing what and I found myself constantly asking The Skipper to list for me all agents, their timing, and their outputs.

While using The Skipper, I was still the switchboard. I constantly asked who owned what, what their routines were, and I had to context-switch between these interrupts. It was enjoyable at first. There was lots of metrics theater. And, ultimately, I think the appeal was that I was being constantly reminded that this shiny new toy was working for me.

But this is not the vision I have for agents in my life.

In reality, I have a number of workstreams. Let's call them "business units" to continue the people organization analogy.

• I have a day job leading product marketing at Supabase.
• I have a side gig writing novels and books.
• I have a personal life as a husband and dad.
• I vibe coded a little app for Montessori schools that miraculously school administrators actually pay me to use.

At the end of the day, I don't care much for the inner machinations of the bottom three business units. I just want to set goals, watch results, and intervene when necessary. Ideally, this enables me to focus energy on the demands of being a leader at a rocketship startup, the creative energy of writing, and the need to be present with my family.

So instead of a Chief of Staff model in which I am inundated with interruptions and context switches, I've opted for more of a General Manager model.

Bot organizations

The first thing I realized was that I was making the same mistake with my bots that companies often make with people. I'd designed the organization around work that could theoretically be done rather than the work I could effectively supervise.

There's a well-established management concept called "span of control." It's basically the number of people a manager can effectively supervise. There's no magic number to it. I've always tried to stick to around 6-7, but I'm also loathe to create middle management where there shouldn't be, so sometimes I've personally stretched to about 10-12. The key in those instances is to make sure people cluster around a set number of critical workstreams.

Agents make this problem particularly interesting because creating another bot is essentially free. I don't need to ask for headcount or go to recruiting. There's no need to worry about budget for salary and benefits. You just create a bot and burn more tokens.

This freedom is a curse, as I soon found out.

There's a temptation with bots that doesn't exist when designing people orgs: why not have dozens of them? If one makes me more productive, won't one hundred make me super duper productive?

The cost is in your attention. It doesn't get cheaper.

Every new bot creates a new thing I need to understand or react to. Another output or stream to review. Another set of instructions to maintain in my head. Another context switch to make when I should be focusing. And yet another agent whose work needs to be coordinated with other agents.

Your agent labor may scale. But your human attention doesn't.

And there's a further problem. Agents don't just create relationships with me. They create relationships with other agents.

This is where things really get complicated. Specialization creates efficiency, but it also creates handoffs that require coordination, generate overhead, and impact efficiency. You could quite literally end up with the bot equivalent of having two hundred employees who push paper around the office to one another. Imagine all these powerful tokens being used to create a digital DMV.

Re-orging my bots

Instead of a central choke point with The Skipper, I opted for more of a General Manager model. Each General Manager has specific outcomes assigned to them. They have specific criteria for when they can bother me and what they can do autonomously.

A GM's charter is just a handful of lines.

• What is their business unit's function?
• What jobs do they do?
• What jobs do they NOT do?
• What it is allowed to do without asking?

This isn't an organizational distinction, it's more about delegation and it changed my view on specialization. The Skipper was about task management. The GM is about delegating outcomes.

Here is my list of General Managers, their charter, and when they're required to contact me:

Name	Charter	When they contact me
Supabase	Employee job: Daily Focus, Linear capture, weekly goals and status, 1:1 prep, summarize product/engineering progress.	New or changed Linear items needing intake; @ message in Slack that requires me to reply
Author	Make me a bestselling author: help me sell The Age of the Astronomer, The Midnight Coder's Children, Picks and Shovels.	Prompt me to write social posts in my own voice and tone; Prompt me to provide creative direction for social content; Social posts are always in draft mode and always written by me first and saved in a Notion doc; Start or change live ads; Prompt responses to reader email
Personal	Daily life: restaurants, travel, meetings, waiting-for, add to my digital brain, health, Daily News, Portuguese and French lessons.	Booking or auth failures; Health or news that needs judgment
Career	Raise my profile as a marketer: CMO coaching, exceptional CMO research, speaking, blog ideas.	None. This is a research agent only.
Future Nerds	Find and fix bug reports, manage GTM, demand gen.	Blocked builds

Bots need to organize themselves

For my writing life, I had landed on having a research bot, an editing bot, a social media bot, and so on.

But my goals aren't to do research. They're to finish a book. My goal isn't to replace my remarkable editing team. They're to help me find clarity and to finish the book. My goal isn't to become a social media influencer. It's to sell more copies of the book. Research, editing, social media, etc. are all capabilities that help accomplish these primary goals.

So I don't really care whether my writing GM uses a research bot or a social media bot. I don't particularly care if it decides it needs a new bot tomorrow. That's its organization to manage, not mine. I care whether they're making progress against the outcomes I've given them.

I arrived at one rule: I talk to General Managers. I never talk to specialists. I wrote about why leaders should never reach down in their organizations, and I apply those principles here.

As an example, the GM I created to manage my life as an author finds podcasts (using the awesome Particle Pro tool) for which I'd be an ideal guest, scans social media for places where I should show up, prompts me daily with where I left off writing and what chapter I need to focus on next (I'm a plotter, someone who outlines and writes character and scene bibles), and suggests new books for me to read in my genre (my next book is a literary fiction + sci-fi crossover.)

Building accountability into bots

The Skipper's job was coordination. The GM's job is accountability.

Every GM also sends a Monday 05:00 Europe/Lisbon CEO brief: last week, this week, blockers, and SMART metrics with links.

This is the distinction between my old Chief of Staff and my GMs. The Skipper existed to help me manage my bots. My GMs exist so that I don't have to manage them.

Complexity should disappear as it moves up the organization. If my research bot generates ten sub-bots that regularly need my attention, I haven't actually done anything. But if my research bot detects that I'm writing about traversing distances measured in light years, it can escalate to the GM, who then filters that information into my reading list. So now I'm reading Andy Weir, whose novels are mathematically and scientifically accurate without sounding like you're reading GitHub.

Bots vs. people

In fact, this is how I manage teams IRL. I give people clear charters and complete ownership. Come to me with clarification questions or when you're blocked. I'll review content before it goes customer facing. Other than that, I trust my people to be great, build the right connections, and generate the agreed upon outcomes.

People can exercise judgment about when and what to escalate. Great employees know when something is weird or out of place and should come talk to me. Bots don't know any of that.

Bots need to be engineered to identify exceptions.

Management by exception

The goal isn't actually to supervise my bots better. It's to supervise them less.

I don't want status reports on everything they're doing. I want to know when they're blocked or uncertain. When they have encountered something in conflict with the rules of engagement I've setup. I want them to tell me when they need my judgement. Otherwise, they need to do the work.

In practice, I engineer the exceptions. I don't get status reports when nothing material changes. A marketing control run that sees that everything is on plan doesn't bother me by telling me that all systems are green. Linear only acts when Issue state changes to something an agent can take action upon. High-stakes actions (sending emails or posting in Slack) are forbidden entirely. The agents can draft for me, that's it. If a GM is silent, I assume progress. If a GM raises its hand and asks for me, I assume something needs my judgment.

Summary

With agents, we've reduced the constraints around resource scarcity. But we've introduced even more organizational complexity. If anything, we removed the natural friction in budget and hiring that used to prevent us from creating too much of it.

As my experiments with my bots continue, I'm becoming a believer that it's not about the number of bots or perhaps not even about the model. The interesting design problem is the organization itself.

Perhaps the best bots are the ones that require the least of you while reliably accomplishing the outcomes you care about.

Your agents need an org chart.