How do you build AI automation in Make.com without it breaking quietly?

The short version

• A Make scenario with an AI module in it is still mostly plumbing, and the plumbing is where it breaks.
• Build the scenario without the model first: if it cannot move the data reliably, a model only hides the problem.
• Model output is text until something checks it, so validate against a schema before it reaches a system of record.
• Operations, not tokens, are usually what makes a Make scenario expensive, and loops are where they disappear.
• An unhandled error ends the run, so every module that talks to another system needs an error route and a human who hears about it.

Where does the model sit in a Make scenario?

In the middle, as one module among many. A Make scenario is a trigger followed by a chain of modules that pass bundles of data along, and an AI module is just a call to a model with a friendlier form around it. It reads what the previous module produced and hands text to the next one. Nothing about it is special to Make.

That framing matters because it tells you where the work is. Calling a model is the easy part. The hard part is the trigger firing when you expect, the connector staying authorised, the pagination being handled, and the field in the CRM still being called what it was called in March. Those are plumbing problems, and they are most of the job.

So give the model a narrow job. 'Read this email and tell me which of these five categories it belongs to' is a job a model does well and you can check. 'Handle this support ticket' is not a job, it is a department. The narrower the step, the easier it is to test, and the less of your process disappears inside a prompt nobody can read.

Why do teams start with Make rather than writing code?

Because the first version works the same afternoon, and for a lot of processes that is the correct trade. You get connectors, OAuth handling and a visual record of what the automation does, without hiring anybody. For a process that runs a few hundred times a month and touches three systems, that is often enough forever.

Automation at this end of the market is not unusual. An online survey of 508 US owners and operators of companies with fewer than 500 employees, fielded in May 2026 by Centiment for Zapier, found 76% were automating work. US Census Bureau figures from its Business Trends and Outlook Survey, covering December 2025 to May 2026, show AI use concentrated in larger firms, with businesses of at least 20 employees the biggest users.

The reason to say that out loud is that the thing you are building is normal, and so are the failure modes. Make itself commissioned a survey of more than 1,200 business decision-makers internationally, published in October 2025, framed around turning AI enthusiasm into real results. That is the vendor's own way of saying enthusiasm has been running ahead of outcomes. The difference between a scenario that earns its keep and one that quietly stops working is almost never the model.

How do you build a Make AI automation step by step?

Build the version with no AI in it first. If Make cannot reliably pick up the record, find the right customer and write the result back, a model will not fix that. It will just make the failure harder to see.

Then the order that saves the most time:

1. Pick one process with a trigger you can name out loud: a form submission, a new row, an inbound email to one address.
2. Write down what a correct result looks like, in one sentence, before you open Make. That sentence becomes your test.
3. Build the scenario end to end with the AI step replaced by a fixed value, and the final write switched off.
4. Run it over real historical data and fix the mapping problems you find, because there will be mapping problems.
5. Add the model call. Ask for JSON, name the fields you want, and keep the prompt in one place.
6. Parse the output and validate it. Anything that fails validation goes to a human queue, not to the next module.
7. Add an error handler to every module that talks to another system.
8. Switch the write on for a narrow slice: one mailbox, one customer segment, one day of the week.
9. Watch it for a week with a short report telling you how many runs happened, how many went to review and how many failed.

What should the model decide, and what should Make decide?

The model decides things that need language or judgment. Make decides everything else. Classification, extraction, summarising and drafting a reply belong to the model. Which branch runs, what counts as urgent, who gets notified and what gets written to the database belong in the scenario.

The reason is readability. A router with a filter that says priority equals high is something you can look at and reason about, and somebody who is not you can change it safely. A prompt ending with 'and if it seems urgent, notify the on-call engineer' buries a business rule inside a paragraph of English, where it cannot be tested and will not be found by the next person.

It is also how you keep the model away from permissions it should not have. If the model returns only a category and a confidence score, the worst case is a wrong category and a human fixes it in a second. If the model decides what to write and where, the worst case is an invented value sitting in a system of record, and you will find it weeks later when somebody reconciles something.

Who decides what?

How do you get output you can actually map to fields?

Ask for JSON, then check that you got it. Name every field in the prompt, say what type it is, say what to return when the answer is not in the input, and give one worked example. Put a parse step after the model with the schema written out, so a malformed response fails at the parse rather than three modules later when a date field contains an apology.

Pin down whatever you can. Low temperature for extraction and classification. A fixed list of allowed values rather than free text, so 'high', 'High' and 'urgent' do not become three categories by the end of the month. An explicit nulls policy, because a model asked for an invoice number that is not in the document will often produce one that looks right.

Keep the prompt in one place. A data store record, or a single variable module at the top of the scenario, is enough. The alternative is the same instructions pasted into four modules, three of which get updated the next time somebody changes the wording.

How do you stop the scenario failing quietly?

By deciding, per module, what should happen when it errors, because the default is that the run stops and repeated failures can switch the scenario off. Make gives you error handler routes for exactly this, and which one you pick is a business decision rather than a technical one.

Resume with a safe default where a missing enrichment should not block the write. Ignore only where the step is genuinely optional. Break to park the bundle and retry it later, which is what you want for a rate limit or a service that is briefly down. Rollback where a half-finished write is worse than no write at all.

Then add the two things people skip. First, somewhere for failures to be seen: a message to a channel a human reads, carrying the record id, not just a line in the execution history nobody opens. Second, idempotency. Store the id of every record you have processed in a data store and check it at the top of the scenario, so a retry or a double-fired webhook does not create a second invoice.

Where does the cost actually go?

Into operations, not tokens. Make charges by module execution, so cost scales with the number of modules multiplied by the number of bundles passing through them. A twelve-module scenario processing two hundred records has done a great deal more work than the diagram suggests.

Iterators are where it disappears. A loop over a hundred line items runs every module inside it a hundred times. Filter before the loop rather than after. Aggregate before an expensive call rather than making one call per item. Use a webhook instead of a polling trigger where the source supports it, because a poll runs on schedule whether there is work or not.

Model spend is usually the smaller line, and it is the one everybody watches. Check both against real volume before you go from one mailbox to all of them, because the shape of the bill changes when the record count does.

How do you test a step whose output is not deterministic?

With a small set of real examples and the right answer written by hand. Twenty to fifty is enough to start. Run them through the prompt, count how many come back correct, and keep the number. Re-run the set after every prompt change. It is dull work, and it is the only thing that tells you whether a change helped or merely felt better.

Look at the shape of the failures as well as the count. A classifier that sends 5% of emails to the wrong queue is an annoyance somebody fixes in a second. An extractor that invents a plausible figure in 5% of cases is a different problem, because nothing downstream will flag it. The same accuracy number can mean either of those.

Set the threshold before you measure. Decide what accuracy would make this worth shipping, decide what happens to everything below your confidence line, and build the review queue for it. A queue that routes uncertain cases to a person is not a failure of the automation. It is the thing that makes shipping the automation safe.

When is Make the wrong tool?

When the scenario stops fitting on a screen. Visual automation is excellent up to a point, and past that point you are maintaining a program in a format you cannot diff, review or test properly.

The concrete signals: branching that needs more than a couple of routers, the same scenario copied and edited for five different customers, logic you would want unit tests around, a queue with retries and backoff, or latency that matters on every request. Also anything where you need to know exactly what changed last Tuesday and who changed it.

The usual answer is not to throw Make away. Keep it for the trigger and the connectors, which are the parts it is genuinely good at, and move the logic into a small service it calls over HTTP. You keep the fast integration and you get code review, tests and version history for the part that encodes your rules. It is also fine to decide a process is not worth automating at all: if it runs twice a month and takes four minutes, the scenario will cost more in maintenance than the process costs in time.