Building worker agents with tools: research, writing and data entry

The manager has no hands. Meet Lina. She sells handmade candles online, and every morning her inbox holds about forty messages. There are wholesale inquiries, booking requests for candle-making workshops, and customers asking where their order is. In the last lesson you built a manager agent that reads those messages and decides who should handle each one. But who does the handling? The manager can say "look up this lead" or "add this booking," yet it has no way to touch a spreadsheet or a calendar. That's where worker agents come in. Today you'll give the manager a small team of workers, and each worker gets the tools it needs to really get the job done.

What you will learn. Here's the plan for this lesson. First, you'll learn exactly what a worker agent is and what people mean by a tool, in plain words. Second, you'll build three typical workers for a small online business: a research worker that checks out new leads, a writing worker that drafts replies, and a data entry worker that records bookings and orders. Third, and this is the part most people skip, you'll learn to give each worker only the tools its job needs. That one habit makes your agent team cheaper, safer and much easier to fix when something goes wrong.

What a worker agent is. A worker agent has four parts. First, a short job description, like "you qualify sales leads." Second, a language model. That's the AI that reads text and writes text, a bit like a very fast assistant who has read a huge library but knows nothing about your shop. Third, tools, which we'll unpack next. Fourth, a fixed report format, so the manager always gets the answer in the same shape. Watch the loop. The worker reads the task, decides a tool would help, calls it, reads what comes back, and repeats until it can write its report. A worker might take one trip around that loop or five.

What a tool really is. A tool is simply an action the worker is allowed to take, like looking up an order, searching a website, or adding a row to a sheet. Think of a toolbox where every tool has a label. The model can't see inside the tool. It only reads the label: a name, a one-sentence description, and the inputs it needs. Here the label says "find an order by its number," and the input is an order number like A-1042. When the model calls the tool, your system runs the real action and hands the result back. Run it, and order A-1042 comes back as shipped. In no-code tools, you fill in this same label in a form.

Lina's three workers. Let's walk through Lina's back office. On the left sits the researcher. When a wholesale inquiry arrives, it looks up the shop that sent it and checks whether this is a serious buyer. In the middle sits the writer. It drafts replies and quotes in Lina's friendly tone, using her real prices. On the right sits the clerk, the data entry worker. It writes workshop bookings to the bookings sheet, which feeds Lina's calendar, and new orders to the sales sheet. Each desk has its own small set of tools, and none of them can do the others' jobs. That separation is deliberate, and you'll see why by the end of this lesson.

Worked example: the research worker. Here's a real task. A message arrives from Green Leaf Gifts asking for a wholesale price on two hundred candles. The manager sends the research worker one question: is this lead worth a quote? The worker searches the web, reads the shop's website, and checks Lina's customer list to see if they've bought before. Notice that every tool only reads. The researcher can't email anyone or change a record, so the worst it can do is give a weak answer. It reports back a score from one to five, two or three reasons, and the links it used, so Lina can check its work in seconds.

Worked example: the writing worker. Next, the writing worker gets the original message plus the researcher's report. Its tools are Lina's price list, her product catalog and a few reply templates, so every number in the quote comes from a real source instead of the model's imagination. That matters, because language models will happily invent a price that sounds reasonable. Look at what's missing here: there's no send email tool. The writer produces a draft and stops. Sending is a separate step that you'll protect with approvals later in this module. A writer that can't send can't embarrass you in front of a customer.

Worked example: the data entry worker. The clerk is the only worker that changes real data, so it gets a guard in front of its tool. Before adding a workshop booking to the bookings sheet, it checks two simple rules: the email looks like an email, and the time falls within opening hours, nine to six. You don't need to write this code yourself. The pattern line only checks that the email has an at sign and a dot, and range nine to eighteen means a start time from nine in the morning to five in the afternoon. Read the two rows. Sara booked at ten with a proper email, so her row goes in. Omar typed his email without the at sign and asked for eight in the evening. Run it, and Sara is written while Omar is sent back with both problems listed. In a no-code tool, this guard is just a filter step placed before the write.

Building workers without code. You don't need Python to build any of this. In n8n, a popular no-code automation tool, each worker is one AI Agent step. You attach tools to it, for example a Google Sheets tool, an HTTP request tool, which fetches a web page or calls another service, or a calendar tool. Then you write a short description for each one, exactly like the labels you saw earlier. Then, in the worker's instructions, describe the report you want back, such as "reply with a score, reasons and links." Here's the shortcut: build one worker, test it, then copy it and swap the tools and instructions. Your second and third workers take minutes, not hours.

Common mistake: one worker with every tool. The most common mistake is handing every worker every tool, just in case. It feels flexible, but it backfires in two ways. First, the more tools a model sees, the more often it picks the wrong one, just like a new employee facing a drawer of forty keys. Second, it's risky. A writer that can also send emails, or a researcher that can also delete rows, can do real damage on a bad day. The fix is simple. Give each worker two to four tools, write clear labels, and make tools read-only whenever the job only needs to look things up.

Recap. Let's wrap up. A worker agent is a short job description, a language model, a small set of tools and a fixed report format. A tool is a labelled action, and the model chooses it by reading that label, so good descriptions matter as much as the tool itself. And finally, match the tools to the job. Researchers read, writers draft, and the one worker that changes data gets a check in front of every write. With that, Lina's morning inbox stops being a pile of chores and becomes a list of finished drafts and clean records waiting for her.

Your exercise. Now it's your turn. Pick one worker for a business you know, maybe your own or a client's. It could be a researcher for leads, a writer for customer replies, or a clerk for bookings. Write down two or three tools it needs, and for each one write the label: a name, one sentence saying what it does, and its inputs. Mark each tool as read-only or as one that writes data. Then, for every tool that writes, add one simple check that must pass first. Bring this list to the next lesson, where we'll pass work between these workers without losing details.