Most AI agents I see in small businesses have the same problem. They're trying to be the whole company.
One agent, one giant set of instructions, every tool attached. It answers support questions, looks up orders, processes refunds, books calls and drafts proposals. And it works, sort of, until the instructions hit three pages and you change one line about refunds and somehow the booking behavior breaks. Nobody can tell you why. The agent can't either.
Make just shipped the fix that most teams were building by hand. Its AI Agents can now delegate. One agent acts as the foreman, the single front door for every request. It figures out what kind of job came in and hands it to a specialist agent built for exactly that job. Each specialist has its own instructions and its own tools. You can change the refund specialist without touching the order lookup specialist. The foreman collects the result and sends back one answer.
Make says it's available right now on every plan, free tier included. And with Make's big Waves conference in Prague next week, the 19th and 20th, I'd expect more on top of it shortly.
I've been building with it since it dropped. Here's my take.
What Make's AI Agents actually are
If you've used Make.com before, you know it as the visual automation tool. Boxes connected by lines, data flowing from one app to the next. Scenarios, in Make's language.
AI Agents sit on top of that. An agent is a model with a set of instructions and a list of tools it's allowed to use. The tools are the part that makes Make interesting, because any scenario you've built can become a tool. Your "look up an order in Shopify" scenario, your "create a contact in the CRM" scenario, your "check the calendar" scenario. The agent decides when to call each one, based on the request in front of it.
Most agent platforms make you rebuild your integrations inside the agent tool. Make lets you point the agent at wiring you already have, across the thousands of apps Make connects to.
Delegation adds one more layer. Now a specialist agent can be a tool too. The foreman's toolbox is mostly other agents.
What it does well
It uses what you've already built. If you've got a year of working Make scenarios, you're most of the way to an agent. That's a huge head start over starting fresh in a new platform.
Specialists stay small. A specialist with one page of instructions and three tools behaves far more predictably than a generalist with five pages and fifteen tools. When something goes wrong, you know which specialist to open.
You can mix models. The foreman doesn't need a flagship model. It's mostly sorting requests, which a small, cheap model handles fine. Save the expensive model for the specialist that has to read a contract or write something a client will see. With Anthropic's Haiku 5.5 landing last week at ten cents per million input tokens for normal length prompts, a cheap foreman just got cheaper.
It's visible. Make shows you each run: which agent got the request, which tools it called, what came back. When a customer asks why they got a weird reply, you can trace it in a couple of minutes.
The free tier is real. You can build and test the whole pattern before paying anything, which is exactly how you should evaluate any agent tool.
Where it trips
Delegation adds a hop, and hops add failure points. The foreman can route to the wrong specialist. In my testing, most misroutes came from requests that touched two jobs at once: "Where's my order, and can I return the blue one?" Write explicit rules for mixed requests (more on that below), or the foreman picks one and drops the other.
Costs stack quietly. Every agent call uses credits, and a foreman calling a specialist calling three scenario tools is several calls for one customer message. It's still cheap per message, but watch the usage page for the first two weeks before you send real volume through it.
Instructions still matter more than the tool. Make gives you the structure. It doesn't write good job descriptions for your specialists. A vague specialist with delegation is still vague, just in a smaller box.
Testing is manual. There's no built in way to replay fifty past messages through a new version of an agent and compare the results. You'll build that yourself. Instructions below.
Your conversations live somewhere else. Make sits in the middle. Your helpdesk, email or CRM is still the front door.
The first build I'd put into production
The support crew. One foreman, three specialists. This is the pattern that pays back fastest for most businesses with customers who email questions.
The foreman: Front Desk. Small, cheap model. Its only job is to classify the request and hand it off. It never answers a customer directly.
You are Front Desk. You don't answer customers. You decide who should.
Read the customer message and decide which specialist handles it:
ORDERS: anything about the status, contents or delivery of an existing order.
RETURNS: anything about returning, exchanging or refunding.
BOOKING: anything about scheduling, rescheduling or availability.
HUMAN: complaints, anything legal, anything about a billing error, anything angry, anything you're unsure about.
If a message covers two specialists, send it to each one with only the part that's theirs, then combine both answers into one reply.
Never guess. If the message doesn't clearly fit, send it to HUMAN.
That "two specialists" line fixed most of the misroutes I mentioned. Same goes for "never guess."
Specialist one: Orders. Tools: your "look up order by email" scenario and "look up order by number" scenario. Instructions tell it to confirm the order with the customer's email before sharing any details, to give the tracking link and expected date, and to hand anything unusual back to HUMAN.
Specialist two: Returns. Tools: the order lookup and a "create return request" scenario that drafts the return in your system without approving it. Instructions include your actual return policy pasted in full. It can explain the policy and start a return. It can never approve a refund. A human does that.
Specialist three: Booking. Tools: "check availability" and "create booking request." If you book through Go High Level, those are two small scenarios against its calendar. Instructions say it can offer the next three open slots and hold one, but the confirmation goes out from a human or after the customer replies yes.
The output step. Front Desk's combined reply doesn't go straight to the customer for the first two weeks. It lands as a draft in your helpdesk or inbox, labeled with which specialists handled it. A human reads, edits if needed and sends. When you're barely touching the drafts anymore, let ORDERS send on its own first, since it's the lowest risk, then BOOKING, then RETURNS last.
Build time, if your lookup scenarios already exist: an afternoon. If they don't, figure a day.
FROM THE AI NEWSROOM
The AI Workflow Blueprint
The exact systems behind everything in this issue. The audit sheets, the routing logic, the templates and the review cadences, built out step by step so you can copy them straight into your own stack. One time, forty seven dollars.
Get the Blueprint for $47
.....
How to test it before it touches a customer
Since there's no built in replay, make one.
Collect fifty real past messages. Pull them from your inbox, a mix of easy and hard. Include at least five mixed requests and five angry ones.
Write the right answer for each. Not the full reply, just which specialist should handle it and the key fact the reply must contain. "RETURNS, must mention the 30 day window." Put them in a sheet.
Build a test scenario. A Make scenario that reads each row, sends the message to Front Desk, and writes back which specialists were called and the draft reply.
Score it. Routing right or wrong. Key fact present or missing. Anything said that shouldn't have been.
Run it once before launch and again every time you change any agent's instructions. That last part matters. Delegation shrinks the blast radius. It doesn't get rid of it. A tweak to Front Desk can reroute everything.
To get a second opinion on the drafts that look borderline, I paste a handful into two different models through Galaxy.ai and ask each to grade them against the right answer. When both flag the same draft, it's worth fixing.
What it costs to run
I won't quote plan prices here because Make adjusts them often enough that whatever I write will be stale by spring. What I'd do instead is measure your own cost per message, which is the only number that matters.
During the two week draft period, note your credit usage at the start and the end of each day, and count how many customer messages went through the crew. Divide one by the other. That's your cost per handled message.
Then compare it to the alternative. If a person spends four minutes on a typical reply and their time costs you thirty dollars an hour, every message costs two dollars in labor. If the crew handles it for a few cents and a ten second human review, the math isn't close.
If your cost per message creeps up, check the foreman first. It's usually calling a specialist it doesn't need, or calling two when one would do.
Who should use it, and who should skip it
Use it if you already run Make scenarios, your customers ask the same five kinds of questions over and over, and you want agents built on top of systems you own. That's most service businesses and small online stores.
Use it if you've built one big agent that's become fragile. Breaking it into a foreman and specialists is the most reliable fix I know of, and Make makes the split easy.
Skip it if you have no automations at all yet. Start with plain scenarios. An agent with nothing to call is a chatbot with ambitions.
Skip it if everything you do lives in one platform with its own agent builder and you're happy there. If your whole business runs in Go High Level, its built in AI tools may be enough, and adding Make in the middle is one more thing to maintain.
Skip it if you need it to handle money end to end. You can build that, but you shouldn't, at least not this year. Let agents prepare and request. Let people approve.
The verdict
Make's AI Agents were already a solid way to put a model on top of the automations you've built. Delegation turns them into something better: a way to build a small crew instead of one overworked generalist.
The crew model is how you'd staff a front desk if you were doing it well. Somebody at the desk who sends people to the right room, a couple of pros who each do one thing well, and a boss for the weird stuff. Make now lets you build exactly that, using the setup you already have, without a developer.
It's got rough edges. Routing still fails on messy requests, testing is on you, and the costs need watching for the first few weeks. But for a business that already runs on Make, it's the most practical agent upgrade available right now, and it's free to try. I'm keeping it in my stack.
FROM THE AI NEWSROOM
The AI Business Accelerator
For operators who would rather build it with someone than build it alone. The full stack, installed alongside you, with the decisions made in the room instead of guessed at. Ninety seven dollars.
Join the Accelerator for $97
.....
This week
Open your inbox and sort your last fifty customer messages into piles. Count how many land in each.
Take the three biggest piles. Those are your specialists.
Check whether you already have a Make scenario for the main lookup each specialist needs. Build the missing ones first.
Set up Front Desk with the instructions above, adjusted to your three piles, and run the fifty message test.
Keep every reply in drafts for two weeks. Then let one specialist at a time send on its own, lowest risk first.
Jordan
The AI Newsroom | Practical AI for people with a business to run.

