Chapter 6: How to Lead Bots¶
Leading bots effectively requires a specific playbook: Know, Assemble, Guide, and Align.
Know Them¶
This is the heart of the discipline. And it's the most challenging technical aspect. I have allocated a Chapter of this book as your primer.
Every component of every bot contributes to its overall capabilities. To reach a gestalt understanding of the teammate, you must know the pieces.
Think of it like knowing a bit of psychology so that you can better relate to other people. But we rarely have the benefit of asking "How would I feel if...?"
A Bot is an alien intelligence.
Analogies are useful, but we must also sometimes wrangle with the true nature of bots, as engineers and technicians, in order to relate to them appropriately.
A Bot has a world model, as I described earlier.
You only have to know them well enough to make good decisions regarding them. There's more depth in this book than you really need, but it's also insufficient because the world is changing fast. You have to maintain currency.
It may be useful to classify bots. Bots with bodies vs without. Bots that are creative vs mostly analytical.
Knowing them includes knowing their limitations. The concept of "AI Slop" can guide us toward an understanding of those limitations.
On Slop¶
Slop is a derogatory term that we'll take to mean "a thing that AI did that I don't like."
Mixed in with the quality of the thing that AI did (the object) is
- The fact that it was done by AI, and
- The "I" (the subject) who does not like it
A lot of subjects just don't like AI, and that muddies any objective assessment; If Slop is anything made by AI, then it's a useless term, overlapping with "GenAI / AI-generated," "synthetic," and "automated." If Slop means inferior product then it describes a real problem, and one that can be fixed with better AI. For that reason, I expect that we will go through a repeating cycle of GenAI products being Slop and then indistinguishable from good (or human-made) products.
graph LR
1[Slop Product]
1 -->|AI Improves| 2[Slopless Product]
2 -->|Fashions Change| 3[New Slop Identified]
3 --> 1At the moment (April 2026), AI frequently exhibits some stylistic tells in its writing that lead to a bad experience for the reader. E.g.:
- False Complexity: The persistent use of words like however, but, or yet to artificially inject depth into what are often basic, common-sense observations.
- Em-Dash Obsession: A reliance on em-dashes—like this—to tack on seemingly "profound" concluding thoughts or break sentences up into digestible, corporate, online-postable chunks.
- Syntactic Symmetries: Overusing perfectly balanced sentences ("It’s not just about
[X]; it’s about[Y]"). It quickly gets hollow through repetition.
I think it's only fair to address the other side of the coin: These GenAI characteristics were probably formed via RLHF, meaning that there's something there we must like. So we could, for example, infer that we should use more em-dashes in our own writing! But I digress…
Slop leads to a bad experience for the reader, so we should know how to spot it. Know what your bots are doing to degrade your team's work product and aim for Slopless.
Assemble Them¶
We have learned that Bots can be LLM brains equipped with tools, physical robots sharing our space, or composites of digital and physical embodiments. They are machines that function like people.
Assembly requires a willingness to hire and fire. Just like with people, there is a cost associated with both adding and removing bots, but both actions must always be on the table. The benefits and penalties associated with hiring decisions are the similar, but the volatility of the hiring pool is magnitudes greater; Every dimension of a "good hire" is in constant disruption, with waves of new software techniques, new hardware capabilities, new vendors, and so on.
Buy Vs DIY¶
The DIY discussion revolves around control. Off-the-shelf systems allow varying amounts of configuration or customization. Worse, their policies or rails may change after you have already invested in the product and ecosystem!
To guarantee that your bots do exactly what you want, you can make the software yourself. Along these lines, consider your own "private source." Because coding has become primarily the purview of AI, building your own tools is much more accessible than it used to be. You can make the software do what you need, and you'll fully control the source code because you wrote it.
However, doing it yourself is a steeper challenge when it comes to embodiment. Making physical robots is hard. I've done it as part of the US Govt (read: lots of money) and with my animatronics startup (read: very little money). They're both hard. In fact, I got into simulations work largely because I could keep exploring ideas and building things without buying and fabricating physical parts (lots of my simulations were essentially character robots in a game engine). So while I'm going to touch on some DIY for robots, I want it to be on the foundation of this basic understanding that it's not an easy road.
Fortunately, there is a powerful alternative to buying locked-down systems: open source. Open source is the only way to really know what's going on with a computer program that you didn't write yourself. A lot of smart and good people understand that and are making efforts to grant the world the privilege of owning their bots.
There's a game I play called Blood on the Clocktower, where one group of people is good and the other evil. The good players don't know anyone's alignment (evil does, but they're outnumbered). A character called the Marionette is evil, but doesn't know it. The character might not actually be in the game, but the possibility that you, a good player, might be mistaken about your own alignment dramatically changes how you play. Even though the mechanical effect of the Marionette is minimal, its potential presence alters how everyone plays and therefore has a huge true impact.
I think of open source this way. The fact that you can walk away from big tech and their secret AI models will induce them to behave better, even if not a lot of us decide to run open source software. To be sure, big tech is not all bad when it comes to open source. Most big tech companies are leaning into open source in some capacity, such as by releasing open models.
So, consider open source. This is one of those topics where I could fill pages evangelizing something that's probably not going to shift your position much, so I'll wrap it up: You have more power if your software is free (as in freedom) and open.
Delegate¶
What to Delegate¶
perfect day exercise. Delegate the stuff you don't dream of doing
delegate stuff that you can monitor, or sufficiently trust without monitoring
delegate dull, dirty, dangerous. ← the classic.
match the intelligence of a particular bot mind to a particular job. intelligence is now a commodity. it can be treated as a module. so assign a task to a system smart enough to handle it.
A Note for Artists¶
My brother Jason is a professional artist (you can see his work at jasonfrailey.com). We've had a lot of conversations about what this new AI era means for people who create for a living. I want to share some of those thoughts with any other artists out there.
First things first: art is satisfying to produce. When we talk about delegating tasks, this is the stuff you keep. I covered this in "What to Delegate." If you love doing a thing, handing it off will just lower your quality of life.
But let's not kid ourselves about whether AI can produce real art. It's making amazing stuff that truly affects the people who experience it.
Among artists, there's a lot of cope right now about it lacking the "human touch." It's that "God of the gaps" argument I talked about in the leadership chapter rearing its head again. Yes, artistic merit is subjective. But generative imagery is so outstanding that it's winning awards and showing us some of the most dazzling things we've ever seen (and music is right on its heels). The arguments against its merit usually boil down to appeals to authority. "Trust me, I'm an artist, and it's bad art. And I am definitely not just saying that because my identity and livelihood have been totally upended." Right.
Many other artists are leaning into AI as a tool, and they're doing incredible work. We are in the centaur era of art, just as we are for agentic engineering. AI acts as a filter you can pass your art through to achieve a specific step; Could be final polish, a quick remix, style conversions, and so forth.
There's a famous lesson about "Fifty Pounds of Pots" that fits here. A ceramics teacher splits his class in two. One half is graded strictly on quantity—produce fifty pounds of pots, get an A. The other half is graded on quality—produce one perfect pot. At the end of the term, the highest quality pots all came from the quantity group. They churned out work, made mistakes, and rapidly improved, while the quality group sat around theorizing about perfection and produced very little.
Imagine how fast you can make fifty pounds of pots with degrees of automation in your workflow. You won't hone a particular skill if you hand it off to an AI, no doubt. But if that specific skill isn't the dimension you want to improve along? Go for it.
I resonate with the AI-skeptical artists when it comes to this: Lean into human connection. You can experience good art, but if there's no human behind it, you're not actually connecting to another person.
But why do art galleries place little plaques next to paintings detailing their history? Why does the artist show up to mingle at an opening? Why is behind the scenes so captivating? It's because the story matters. In some cases, the story matters more than the art itself.
So continue to foster that human aspect of your artistic works, no matter what elements were generated by a bot.
Organizational Charts with Bots¶
A diverse team of Bots brings varied approaches, distinct knowledge bases, and true diversity of thought to your work. This variety introduces the potential for constructive conflict—the kind of friction that drives growth and leads to optimal outcomes.
However, managing a wider variety of Bots also increases the complexity of your environment. It might be more convenient to have just one assistant, for example.
Your org chart can be shaped and reshaped to your liking.
you work with one bot. any agent will typically have other agents that works with, often creating them on the fly
mindmap
(("👤<br>You"))
["🤖<br>Bot"]
["🤖<br>Sub-Bot"]
["🤖<br>Sub-Bot"]you work with many bots
mindmap
(("👤<br>You"))
["🤖<br>Bot A"]
["🤖<br>Bot B"]
["🤖<br>Bot C"]you work with one or more Bot Leaders (ie, people). Still useful for you to know about Bot Leadership so you can interact with them better. I'm not covering how to work with people much in this book because it's thoroughly covered elsewhere.
mindmap
(("👤<br>You"))
(("👤<br>Bot<br>Leader"))
["🤖<br>Their Bot(s)"]
(("👤<br>Bot<br>Leader"))
["🤖<br>Their Bot(s)"]
(("👤<br>Bot<br>Leader"))
["🤖<br>Their Bot(s)"]you will work with your bots and other bots (ie, big tech's) and your bots will have bots and you'll work with other bot leaders who have their own similar trees
mindmap
(("👤<br>You"))
["🤖<br>Your Bot(s)"]
["🤖<br>Sub-Bot"]
["🤖<br>Big Tech<br>Bot"]
(("👤<br>Other Bot<br>Leader"))
["🤖<br>Their Bot(s)"]Guide Them¶
There's an infamously dreaded question for creatives (writers, comics, makers, etc.):
Where do you get your ideas?
It's too reductive, abstract, and just difficult to respond to with any accuracy. The comedian Norm Macdonald even had a recurring bit on his talk show where his hapless sidekick would "earnestly" put it to their guest just to mess with them.
Some questions are simply not going to take the conversation anywhere interesting.
People who don't work deeply with Bots often ask this question:
What work did you do and what did the AI do?
Well, let me try to explain.
Have you ever created new music with a group of friends? Have you ever sat at a writer's table? Have you ever stood on an improv stage with a cast of on-the-spot characters and tried to build a scene?
Those are the purest forms I can think of, but I'll stretch the idea a bit:
Have you ever played charades? Have you ever simultaneously co-written a document? Have you ever had a good meeting?
In these scenarios, somebody throws out a half-formed sentence and somebody else catches it wrong -- hears something the speaker never meant -- and that mishearing sparks a "yes, and" that pivots the whole room into territory nobody planned but everybody suddenly recognizes. You're reacting to something that was a reaction to your own throwaway line from three minutes ago, except your partner bent it just enough that now you're seeing a third thing you hadn't considered until the words were already out of your mouth. Meanwhile someone across the circle just shifted their weight and that changed the energy and now the thing you were about to say doesn't fit anymore so you say something else entirely and that lands, and the person next to you riffs on it before you even finish, and their riff reminds you of the original idea but it's mutated now, unrecognizable, better. A mistake becomes a hook. Your original intent gets swallowed by the momentum of what things are becoming.
That is what "group flow" feels like. You are in it. You are co-creating with other minds, and to piece together how exactly things happened afterwards is both absurdly difficult and not very interesting.
Instead of asking the question "How exactly did the thought work go down," I'd suggest getting into a group flow with AI. Then your answer to the question would be, "It was probably similar to what it was like when I did it," which I think is the most informed one could be on the subject.
Your role as Bot Leader is to guide the work toward your vision, no matter the form or source of the work being done.
Guidance is active. Remember that this is the worst AI will ever be; Bots grow, learn, and evolve. You shepherd that growth toward your desired outcome.
Communicate your vision. If a bot is not doing what you want or expect, it's most likely going to be worthwhile to course-correct. Something as simple as "You are doing X, but I want you to do Y," is remarkably effective. Any knowledge of your bot's inner working will help you guide it. For example, this is a common debugging pattern: "I don't like that you did X. Please identify if there is anything in your context that helped bring it about." Once the problem is identified, you could move to "Give me a corrective action plan" — That is, if the agent hasn't solved the problem proactively.
Personal Development for Bots.
Scaffolding : Tools, Rules, and Workspaces¶
"Scaffolding" has been getting some usage to describe all the complementary structure that surrounds a model.
Context engineering (which evolved from prompt engineering) names the specific focus on supporting an LLM with the ideal data environment. From our primer on LLMs, you might rightly think that context is the most critical element of the scaffolding.
For example, if you ask a bot for the weather, and it pulls weather data from the internet, then reads that weather data (which is now in context) and generates a response from it, then all the local software that lets the LLM reach out for weather data — and know that it could — is part of scaffolding.
Also includes programs
When a bot wakes up to perform a task, it has amnesia. It only knows what is in its immediate context window. Your job as a Bot Leader is to construct that context meticulously.
Bots thrive on structure. If you dump a 100-page unstructured document into a bot's context and ask "how does the system work," it will hallucinate or miss details.
OpenClaw has the AI world abuzz by providing a capable prepackaged scaffolding. It lets you run agents on your own hardware, often connected to your own LLMs for inference, and then provides a nice environment for customizing it.
OpenClaw's celebrated capability is a result of
- Skills Standard - OpenClaw ships with agentic skills that fit a standard for expansion. In many cases the user provides account login credentials and hits "GO".
- Marketplace - Run by the OpenClaw community. An operator can easily browse and add skills to get their Claw doing what they want.
- Openness - Running agentic systems on local hardware means independence; no reliance on a server sitting in a farm owned by big tech. The software is all open source, which means you can see and modify what your bot is doing.
- Context Engineering - The md files and other supporting files are well-suited for the kind of workflows that most operators want. Includes things like memory (
MEMORY.md) and personality (SOUL.md). There are also mechanisms for running the activities based on a timed interval or events to make the bot proactive.
I am somewhat skeptical that OpenClaw is "the answer" for a swath of AI applications , but it is a premium example of the returns one can receive by building a good scaffolding.
Constrained Action Spaces (Funneling)¶
Lossy Comms¶
LLMs have rapidly become key facilitators in our everyday communications. They shape everything from private journals, emails, and blogs to books and videos.
When working with your bot team, it is easy to lose sight of some important members of your audience: humans.
For reasons described throughout this book, we are incentivized to use AI to handle much of the grunt work involved in producing those communications. Typical patterns include:
- Take this seed of an idea and flesh it out, and
- Simplify this complex content.
Here's a scenario that follows those patterns
flowchart LR
subgraph Producer [Producer Environment]
direction LR
B[Concise Thought] --> AI_P((AI))
end
AI_P --> C[Verbose Text]
C --> AI_C
subgraph Consumer [Consumer Environment]
direction LR
AI_C((AI)) --> D[Concise Thought]
end
The problem:
How accurately does the concise thought in the producer's environment reflect the concise thought in the consumer's environment?
The solution is to be a good guide, and the onus is mostly on the producer.
- Be particular about formulating the concise thought. Any superfluous or ambiguous content can lead your bot astray. All the scaffolding available to the AI is similarly situated for refinement, because it can just as easily bloat the output by latching onto minor details and assigning them a level of importance that the producer never intended.
- Check things before sending. In other words, keep a "human in the loop."
- Consider just sending the concise thought.
- Do the
Verbose -> Concisestep in your Producer's Environment, and send the result. - Do it manually, following the aphorism, "If you want something done right, do it yourself." Of course, doing something yourself is terribly inefficient. It's also simple and robust and it deserves a permanent place on your tool belt. Besides, in a world more densely packed with bots, we might expect a higher premium on human authenticity.
- Do the
Usage Economics¶
As your team of bots scales, so does the cost to operate them.
That makes economic usage engineering another useful skill, up there with prompt engineering and context engineering. Every time you interact with a bot, it costs something. And those costs can compound fast.
We introduced tokens when discussing how bots work; LLMs process and generate tokens. The token counts can get so massive that they're hard to reconcile. If you're holding a copy this will obviously be easier to grasp, but:
The book you are reading is about 17,000 tokens.
Token Costs (Cloud and APIs)¶
When you rely on hosted models, you pay per token. And because bots have amnesia, every turn in a conversation re-sends the entire history of that session.
- Context Accumulation: Long chat sessions are disproportionately expensive. A 15-turn session isn't 15 times the cost of a 1-turn session; It multiplies as the history grows.
- Tool Taxes: When your bot uses tools to read files or search the web, that text gets dumped into the context window. And it stays there, taxing every subsequent prompt.
- Optimization: Prune your context ruthlessly. Archive completed work. Prefer short, single-purpose sessions over long, sprawling ones. If you have permanent scaffolding files, recognize that their size is a recurring tax on every single turn.
Managing Context Incrementally (Kaizen)¶
Here's a concrete example of a token-saving technique from my own experience.
When we want a bot to read a lot of files, our first instinct is to cram them all into one giant prompt. It's simple to code, and it bleeds tokens.
In addition to the token waste, LLMs forget things buried in the middle of long prompts. Further, there may be opposing info in a huge context, which may lead to a hallucinated compromise.
graph TD
A[File 1] --> E(Huge Text Blob)
B[File 2] --> E
C[File ] --> E
D[File 100] --> E
E -->|Huge Input| F["Single LLM Call<br>Analyze & Merge"]
F --> G["Token Limit Error<br>OR Hallucinated Summary"]
G --> H[(Knowledge Base)]
style G fill:#f96,stroke:#333,stroke-width:2pxInstead of tossing everything into one pot, borrow a concept from continuous improvement: incremental synthesis (or Kaizen).
Rather than batch-processing everything at once, feed the bot one new document at a time alongside your existing core knowledge. Tell the bot to extract only the high-value facts and carefully merge them into the central repository.
The bot reads the new file, cleanly updates the central knowledge base, and moves on to the next file.
---
title: Loop for Each File
---
graph RL
KB[(Knowledge<br>Base)]
File[File n] --> LLM[Bot: Analyze & Merge]
LLM -->|Writes Updates| KB
KB -.->|"Provides context<br>for File n"| LLMIf you're updating an existing project, the bot doesn't write a new file from scratch. It performs a smart merge.
It's an iterative loop of polishing, getting smarter with every pass. Because the bot is only ever looking at the polished core knowledge and one new document, it doesn't get overwhelmed. You can nurture your bot's knowledge growth from massive datasets without blowing your token budget.
Hardware Costs (Local Inference)¶
As we discussed regarding Local Inference , running bots on your own hardware flips the script. You trade recurring operational expenses (API tokens) for upfront capital expenses (silicon, GPUs).
When you run models locally, the marginal cost of a query drops near zero. It's just electricity. You can let agents loop endlessly without dreading a massive API bill at the end of the month.
But staying on the bleeding edge of AI hardware? That can quickly become a financial sinkhole.
Implementation Specifics¶
While this is one of the more technical chapters, I have intentionally avoided going deep into details about the technical execution of the ideas. In rapid technological change, a static object like a book is not going to be a resource for the latest and greatest.
If you want to know how to execute, I'd recommend this: Talk to a Bot about it.
With that disclaimer, I will suggest a few things...
MapReduce for Massive Tasks¶
Earlier we looked at managing context incrementally—building a knowledge base one file at a time. That Kaizen approach is your strategy when nurturing a long-lived machine brain.
But sometimes you just need to process a massive amount of data in a hurry. When that happens, you can try MapReduce.
Instead of an iterative loop, MapReduce splits the work into two phases.
First is the Map phase. You spin up a thousand bots simultaneously, handing each bot exactly one document. Their only job is to read that file and extract the key facts.
Second is the Reduce phase. Put all those extracted facts into thematic buckets, and hand each bucket to a bot that merges the scattered notes into a clean summary.
It scales infinitely. It's your strategy when strip-mining a mountain of unstructured documents for your bot to reason about.
graph TD
subgraph Map Phase [Map Phase: Parallel Extraction]
Doc1[Document 1] --> Bot1((Bot))
Doc2[Document 2] --> Bot2((Bot))
Doc3[Document 3] --> Bot3((Bot))
Bot1 --> Fact1(Extracted Facts)
Bot2 --> Fact2(Extracted Facts)
Bot3 --> Fact3(Extracted Facts)
end
subgraph Reduce Phase [Reduce Phase: Consolidation]
Fact1 --> Bucket1{Topic Bucket A}
Fact2 --> Bucket1
Fact2 --> Bucket2{Topic Bucket B}
Fact3 --> Bucket2
Bucket1 --> BotR1((Bot))
Bucket2 --> BotR2((Bot))
BotR1 --> Sum1[Clean Summary A]
BotR2 --> Sum2[Clean Summary B]
end
style Bot1 fill:#e1f5fe,stroke:#01579b
style Bot2 fill:#e1f5fe,stroke:#01579b
style Bot3 fill:#e1f5fe,stroke:#01579b
style BotR1 fill:#e1f5fe,stroke:#01579b
style BotR2 fill:#e1f5fe,stroke:#01579b
style Sum1 fill:#c8e6c9,stroke:#388e3c
style Sum2 fill:#c8e6c9,stroke:#388e3c
Create A Bot MVP¶
Anyone working with bots can also create custom bots. The companies leading the AI revolution all want you to use their infrastructure, so they want you to perceive the greatest value with their implementation. Accordingly, they've provided quick and easy ways to assemble scaffolding (and we all know the power of good scaffolding).
Gemini Gems, as well as competitors like OpenAI Custom GPTs, Anthropic Claude Projects, Microsoft Copilot Studio, and Poe.
Visual Studio Code (formerly "github copilot in vs code" until Microsoft decided to integrate it). Cursor is a different take on this setup. YMMV.
OpenClaw. If you get comfortable with OpenClaw, it may be your MVP factory. You'll want to build a template for a trimmed down agent (few files, etc.) and use that as your MVP starting point.
Bot Interfaces¶
You can type to a bot.
Talk to a bot. Right now it's just voice to text. Some aspects of vocal comms are missed out on, afaik, like vocal tone, inflection. Could go to pure audio later
Gestures. Video input with facial expression and gestures recognition etc.
Grab a bot arm and move it where you want to go. Teleop. With physical bots mostly.
Screen sharing workflows.
RTS Controls¶
controlling lots of bots is probably best done with RTS style controls