Skip to content

Chapter 7: Guide Your Team

Delegate

What to Delegate

[jotted ideas. expand this section]

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. [expand ]

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 [expand]

mindmap
  (("👤<br>You"))
    ["🤖<br>Bot"]
      ["🤖<br>Sub-Bot"]
      ["🤖<br>Sub-Bot"]

you work with many bots [expand]

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. [expand]

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

[ or cooperate ]

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. [explain flow and group flow? seems superfluous ]

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. [expand]

[consider describing Uncle Ed's personal operating system applied to AI. "develop your team"]

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 [explain agent framework if I didn't in Ch3. explain REPL, database access,]

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. [expand and introduce GuyFresh demo]

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. [expand]

[ To provide good scaffolding: - Use Markdown: Headings, bullet points, and code blocks provide semantic clues that an LLM cleanly parses. - Provide Examples: Few-shot prompting (giving 2-3 examples of the input and your desired output) is hands-down the most reliable way to guide a bot's behavior. It reduces ambiguity far better than paragraphs of explanation. - Give Them Memory: Humans remember the results of yesterday's work. Bots don't, unless you record it for them. Keep an ongoing project_memory.md or guidelines.md file in the workspace. Update it with lessons learned, active goals, and established facts. Have the bot read this file before beginning a new task. ]

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

  1. 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".
  2. Marketplace - Run by the OpenClaw community. An operator can easily browse and add skills to get their Claw doing what they want.
  3. 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.
  4. 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 [ref Buy vs DIY discussion], but it is a premium example of the returns one can receive by building a good scaffolding.

Separate the Engine from the Interface

A standard engineering principle becomes a lot more important once a bot is writing most of your code: keep the engine separate from the interface.

The engine is the execution logic — the scripts that actually do the work. The interface is everything you reach for to change your bot's behavior: the persona, the config values, the guidance rubric, the rules for what to never touch.

Here's the problem it solves: When you lean on a bot for technical work, you stop knowing that system the way its author would. So if all the knobs that tune behavior are buried deep in the code, stepping in to adjust your bot gets hazardous and opaque. You're editing something you didn't write.

So give yourself a control panel. Pull the persona and the settings out into plain files — a config.json, a guidance.md, the SOUL.md and MEMORY.md we saw with OpenClaw. Now you can tune the mind of your bot without risking the machinery it runs on.

It's the same thing that made C2ORE work, the army project I mentioned back in Chapter 2. The operator's will reached the bots through a good interface, not by reprogramming them mid-mission.

By separating interface from engine, you are applying an engineering principle to an old leadership skill: keeping clear lines open with your team. You establish the channels of communication with your bot, which lets you be a better leader.

Constrained Action Spaces (Funneling)

[expand: discuss Constrained Action Spaces (maybe call it "funneling"). Talk about how sometimes the best way to lead a bot is to restrict its choices entirely. e.g. instead of granting a bot the ability to "use SQL", you give it a tool that can only execute one of 20 pre-written, safe SQL commands. At the API level, this is also known as "Structured Outputs" or "Constrained Decoding". restricting freedom here increases reliability and safety.]

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:

  1. Take this seed of an idea and flesh it out, and
  2. 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.

  1. 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.
  2. Check things before sending. In other words, keep a "human in the loop."
  3. Consider just sending the concise thought.
    1. Do the Verbose -> Concise step in your Producer's Environment, and send the result.
    2. 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.

[ the cost of new data is approaching zero ]


Stay Updated.

I'll email you only with major announcements, like when the book gets published.