Designing the manager agent: planning, routing and delegating tasks

The inbox that never sleeps. Picture Sara, who runs Bloom Bakery online. Her phone fills with about sixty messages a day. One customer wants a tasting on Saturday, a price for fifty cupcakes, and a receipt for last month, all in a single message. In the last lesson you saw that a team of agents can share this load. But a team with nobody in charge is just a crowd, isn't it? Someone has to read each message, split it into jobs, and hand each job to the right helper. In an agent team, that someone is the manager agent. Today you'll design one that Sara could trust with her inbox.

What you will learn. By the end of this lesson you'll be able to do three things. First, plan, which means turning one messy customer message into a short list of separate tasks. Second, route, which means choosing which worker agent gets each task. Third, delegate, which means writing a short brief for that worker so it knows exactly what to do and when it's finished. None of this needs code in your no-code tool. I'll show a little Python only to make the logic visible, the same logic you'll type into a prompt.

The manager's three jobs. Here's the whole job on one page. A customer message comes in. The manager plans by listing the tasks inside it. It routes each task to a worker. Then it delegates by writing a brief for that worker. Notice what the manager doesn't do: it doesn't open the calendar or calculate prices. Those tools belong to the workers. Think of a restaurant head waiter who takes the order and passes tickets to the kitchen, but never cooks. Keeping the manager this narrow is what makes it reliable, because a smaller job means fewer ways to get it wrong. Its only output is a list of tasks, each with an owner.

Planning: one message, three tasks. Let's plan a real message. The customer writes: book me a tasting on Saturday, tell me the price for fifty cupcakes, and resend my receipt from last month. A person reads that and instantly sees three jobs. The manager must do the same, on purpose. Picture the long message on the screen, then three sticky notes on the wall, one per job. Each note holds one action with one clear result: a slot, a price, a resent receipt. If a task still contains the word "and", it's probably two tasks, so split it again. Small, single tasks are much easier to route and much easier to check later.

Routing: the simple first layer. Routing means picking a worker for each task. The cheapest version is a keyword table. Look at the top of the code: booking words go to the booking worker, price words to the quote worker, receipt words to the invoice worker. The middle part checks the message against each list in turn. The last line of the function says: if nothing matched, send it to a human. Run it and look at the output. The Friday message gets two workers at once. And the shipping question matches nothing, so it falls back to a human, which is exactly what we want. Keywords miss fuzzy wording, and they can also match the wrong word, because notebook contains book and unpaid contains paid. So in practice you add a language model as a classifier. A language model is the AI that reads and writes text, like ChatGPT. A classifier is just a sorter that puts each item into one of a few labelled boxes, like sorting post into pigeonholes.

Delegating: the task brief. Delegating means the manager hands each worker a brief, like a manager passing a clipboard across the desk. A good brief has five parts. The goal, one sentence with one result. The inputs, the facts the worker needs, such as the customer's name and the date they asked for. The output, the exact shape of the answer, for example a time slot and a confirmation line. Done when, which tells the worker what finished looks like, so it doesn't keep going. And limits, such as never confirming a booking that costs over two hundred dollars without approval. Notice how much guessing that removes from the worker's side?

The manager prompt in your tool. In a no-code tool like n8n, the manager is an AI Agent step, and everything we've covered goes into its prompt. A prompt is simply the written instructions you give the model. Read it from the top: you're the manager, you never do the work, list every request, pick one worker each, write a five-part brief, and reply only in JSON. JSON is a plain text format of labelled fields, like a filled-in form, which the next steps in your workflow can read without guessing. That last line, if unsure, route to human, is the cheapest safety feature you'll ever add.

The manager's output for our message. Here is what the manager actually sends back for our bakery message: a list of three tasks, one per worker. Look at the first one, the booking task, written out in full. The goal is to find a Saturday tasting slot. The inputs are the customer's name and the day she asked for. The output is one time slot and a line to confirm it. It's done when a free slot is held. And the limit says anything over two hundred dollars needs approval. The quote and invoice tasks get the same five parts; here we show only their goals to save space. This list is the whole of the manager's work, and every worker can act on it without asking a single question.

Worked example: one message, end to end. Let's run the whole thing. First the customer sends the three-part message into Sara's inbox. It then reaches the manager agent, which plans three tasks and routes each one. Now three briefs go out: to the booking worker, the quote worker and the invoice worker. Each worker uses its own tool, the calendar, the price list, the invoicing app. Then the results come back: Saturday at eleven, ninety-five dollars for fifty cupcakes, and the receipt resent. The manager writes one friendly reply that covers everything, and the customer never sees the team behind it.

Common mistake: the do-everything manager. Here's the trap almost everyone falls into. You give the manager agent every tool, just in case: the calendar, the price list, the invoicing app. Soon it starts doing the jobs itself, half booking and half pricing, while the workers sit idle. When something goes wrong, say a double-booked Saturday, you can't tell which part failed. The fix is strict: the manager gets no work tools at all. It reads, plans, routes and writes briefs. If you catch yourself adding a tool to the manager, that's a sign you need another worker instead.

Recap. Let's pull it together. The manager plans by splitting each message into single tasks, one action and one result each. It routes those tasks, starting with cheap keyword rules, adding a language model classifier for fuzzy wording, and always falling back to a human. And it delegates with a five-part brief: goal, inputs, output, done when, and limits. Look at Sara now, drinking her coffee while the trays move along the counter in order. That calm comes from a manager that only manages.

Your exercise. Now it's your turn, and you don't need any tool yet. Take ten real messages from your own business inbox, or invent ten for a small shop you know. For each one, list the tasks inside it and choose a worker: booking, quote, invoice or human. Then pick the hardest task and write its full brief with all five parts. Finally, note every message you'd send to a human and why. Bring this list to the next lesson, because we'll build the worker agents that receive these exact briefs.