Project: an agent team that turns a sales inquiry into a sent proposal

Slow proposals lose deals. Meet Nadia. She runs a small online candle shop, and more and more companies email her about corporate gift orders. One of those orders can be worth more than a week of normal sales. But every inquiry means checking the details, pricing it from her spreadsheet, writing a proposal and sending it. Last month two of them sat in her inbox over a busy weekend, and by Monday both clients had ordered somewhere else. Slow proposals lose deals. In this project lesson we'll combine everything from this module and build an agent team that turns an inquiry like hers into a sent proposal, with Nadia approving every one before it leaves.

What you will build today. Here's the plan for this lesson. First, you'll map the whole job, from an inquiry arriving to a proposal going out, onto a manager agent and a few worker agents, each with one clear task. Second, you'll pass a single shared case file between them, so details like the quantity or an attached logo never get lost in a handoff. Third, you'll add a checker that approves the draft or sends it back, and then your own approval, limits and a log, so the team is fast without being reckless. By the end you'll have a blueprint you can rebuild in a no-code tool.

The team blueprint. Here's the blueprint. Everything starts when a client's message lands in your inbox. Now let's add the whole team. The manager agent reads the message, decides what's needed and delegates. A pricing worker looks up costs in Nadia's price sheet, and that sheet is the only place prices may come from. A writer worker turns the facts into a proposal. A checker compares that proposal with the facts, using simple rules. And you sit at the end with the final say. Let's follow one inquiry through. The quantity goes to pricing, prices come back, the case file goes to the writer, and the checked draft reaches you.

The inquiry we will run. Here's the real inquiry we'll run. The client is Leo, office manager at Brightway Dental, a clinic with three branches. He asks for one hundred twenty gift boxes, each with one candle and the clinic's logo engraved on the lid, and he's attached the logo file. His deadline is December tenth, because the boxes are handed out at the clinic's holiday party. So what should the manager agent do first? It qualifies the lead, which means checking it's worth pursuing: is the order big enough, is the date possible, is anything missing? Here everything checks out, so the manager marks Leo as qualified and opens a case file.

One case file, passed along. This is the case file, the one record every agent reads and writes. Remember the handoff lesson: agents shouldn't retell the story to each other in their own words, because every retelling drops something. Instead, each agent reads the whole file and fills in only its own field. Right now total and draft are empty, written as null, which simply means nothing yet. The pricing worker will fill total, and the writer will fill draft. And look at the notes line. That logo file is exactly the kind of detail a quick summary forgets, and here it travels with the order all the way to the proposal.

Pricing worker: the sheet does the maths. Now the pricing worker. Its tool is Nadia's price sheet, and the sheet does the arithmetic, not the language model. A language model, the AI that writes text, is great with words but can slip on sums, like a friendly salesperson doing maths in their head. So the worker only writes in the quantity, and the sheet multiplies unit price times quantity. We fill it down for engraving and shipping. Orders over one hundred units get a ten percent bulk discount on the products, but not on shipping. And the grand total is two thousand two hundred fifty nine dollars, which goes straight back into the case file.

Writer and checker: send it back. The writer worker drafts the proposal from a template. But its template came from an old order, and it wrote one hundred boxes instead of one hundred twenty. This is why we have a checker. Notice that the checker doesn't need to be clever here. It compares the draft with the case file using plain rules: same quantity, same total, and a ship date before the deadline. On the first run it finds one issue, quantity differs, so the draft goes back to the writer with that exact note. The writer fixes it, the checker runs again, and this time it prints approved.

Your approval, limits and a log. Even an approved draft doesn't go out by itself yet. The team sends Nadia a short preview: client, quantity, total and the proposal itself. One tap on yes, and it's emailed to Leo and logged. If she says no, her note goes back to the writer, and the loop runs again. Add one hard limit too. Any total over five thousand dollars stops the automation and reminds her to phone the client, because big deals deserve a human voice. And the log records every step, with the time, the agent, what it did and the case, so when something looks odd you can see exactly where it happened.

Building it in n8n. You can build all of this without writing code in n8n, a visual automation tool where you connect boxes called nodes. A Gmail trigger starts the workflow whenever an email gets a sales inquiry label. The manager is an AI Agent node, and each worker is a small separate workflow it can call as a tool: pricing reads and writes the Google Sheet, writing fills a Google Docs template. The checker is a node with your rules. For approval, use Gmail's send and wait option, which pauses until you answer. And the log is just one more node that adds a row to a sheet.

Common mistake: the writer invents numbers. The most common mistake in this project is letting the writer do the pricing too. It feels simpler: one agent, one prompt, price it and write it. But the model will happily produce numbers that look reasonable and are wrong, maybe last year's engraving price or a discount you never offered. And if the checker only reads the draft, it has nothing true to compare against. The fix is the design you just saw. Numbers come only from the price sheet, they travel in the case file, and the checker compares the draft against that file, never against itself.

Recap. Let's recap. First, a manager agent plans and delegates, while each worker does one task with one tool: pricing with the sheet, writing with the template. Second, a single case file carries every detail between them, so the quantity, the deadline and Leo's logo all reach the final proposal. Third, a checker sends weak drafts back, and Nadia's approval, a limit on big orders and a log keep the whole team safe. The result is a proposal that goes out the same evening instead of after the weekend, and Nadia still reads every one before it's sent.

Your exercise. Now it's your turn. Rebuild this team for your own business or for a client you'd like to sell it to: a manager, a pricing worker with a real price sheet, a writer, a checker and your approval step. Then run three test inquiries. One normal order that should go all the way to your approval. One with no deadline, which the manager should catch and answer with a question. And one big enough to hit your limit. Save the log and note where each test stopped. Those three rows are your proof that the team works, and they make a great demo for a client.