Make.com is useful for AI workflows where the input is messy, the task requires interpretation, or more than one outcome could be acceptable. However, a nondeterministic workflow should not mean an uncontrolled workflow. The most reliable design uses AI for a defined judgment task and deterministic steps for validation, routing, record updates and other business actions.
In practice, using Make.com for nondeterministic automation means separating interpretation from execution. An AI module might classify an enquiry, rank possible responses or extract meaning from an unstructured message. Filters, data stores, routers and approval steps then decide what the system is allowed to do with that result.
The right starting point is not a prompt or a module. Define the business state you are trying to identify, the acceptable outputs, the owner of the next decision and the conditions that require review. Once those are clear, Make.com can provide a visible, testable operating path around an inherently variable AI response.
What nondeterministic automation means in Make.com
Traditional automation is deterministic. Given the same input and conditions, it is designed to follow the same path. A filter checks a value, a router selects a route and an integration writes a known field.
AI-driven automation introduces variability because a language model interprets language rather than matching every input against a fixed rule. The same customer message may produce different wording, rankings or explanations. That variability can be useful when the task involves ambiguity, summarisation, categorisation or generating options. It becomes a problem when the workflow has no clear definition of an acceptable result.
Nondeterministic automation should vary in its interpretation, not in its control boundaries.
Make.com is therefore best treated as the orchestration layer around the AI step. The scenario can receive an event, prepare the input, ask the model to perform one defined job, validate the response, route it according to business rules and record what happened. The model may suggest a result, but the surrounding workflow should determine what happens next.
Decide whether the task needs AI at all
Not every variable process requires a language model. Begin by asking whether the decision can be expressed as a stable rule using available fields. If a lead should be routed to a region based on postcode, or an invoice should be escalated when its value exceeds an approved threshold, ordinary Make.com filters and routers are usually more suitable.
AI becomes more appropriate when the information needed for the decision is contained in free text, documents or inconsistent human language. Examples include identifying the reason behind a support request, extracting requirements from an email, grouping similar feedback or producing several draft options for a person to review.
Adding AI to a process that already has clear rules increases variability without adding useful judgment. Use AI where interpretation is the bottleneck, not where a filter would be clearer.
A useful diagnostic question is: What specific judgment is the AI being asked to make, and which part of the outcome must remain controlled? If the answer is broad, such as “manage the customer” or “improve the process,” the job is not yet defined well enough to automate.
Define the business state before designing the scenario
A Make.com scenario should move a record or request from one meaningful business state to another. A message might start as “new and unclassified,” become “classified and awaiting owner,” and then become “assigned,” “resolved” or “escalated.” These states are more useful than describing the workflow as a series of technical module executions.
For the AI step, define four things:
- Input: the text, document or structured data the model can use.
- Job: the single interpretation, extraction, ranking or drafting task it must perform.
- Acceptable output: the labels, fields, options or response structure the workflow can handle.
- Next owner: the person, team or system responsible for the next business decision.
This definition prevents a common failure mode: a model returns an interesting answer, but nobody knows whether it should update a CRM, create a task, notify a team or wait for review.
A CRM stage should represent a meaningful business state, not simply the fact that an AI module has run.
For example, an AI classification of “possible renewal risk” should not automatically change an account to “at risk” unless the organisation has defined what that state means, who owns it and what evidence is required.
A practical Make.com design sequence
Use the following sequence to keep an AI-enabled scenario understandable and testable.
This sequence keeps the AI step narrow. It also makes it possible to replace the model, revise a prompt or change a routing rule without redesigning the entire process.
Design prompts for useful variation
A prompt for nondeterministic automation should not merely ask for a clever answer. It should describe the decision context and the limits of the response. State the role of the task, the information available, the possible categories or output fields and what to do when the evidence is insufficient.
For example, a support triage task might ask the model to identify one primary category, list relevant evidence from the message and return an uncertainty flag when more information is needed. It may also request a suggested reply, but that draft should be separate from the routing decision so a writing variation cannot silently alter priority or ownership.
- Use a constrained set of labels where downstream routing depends on them.
- Ask for structured output that can be validated before it reaches another system.
- Separate factual extraction from recommendations and generated wording.
- Require an explicit “unknown” or “needs review” outcome when the input does not support a confident result.
Prompt quality is not a substitute for process design. A detailed prompt cannot resolve an undefined owner, ambiguous business state or missing escalation rule.
Use guardrails around the AI step
Guardrails should be implemented in the scenario, not left entirely to the model. Make.com can use deterministic modules to check whether the response is complete and safe to pass to the next stage.
Useful checks include whether a required field exists, whether a category belongs to the approved list, whether an identifier matches the source record and whether the output contains data that should not be sent onward. A failed check should have a visible route, such as a review queue or exception record, rather than simply stopping without ownership.
- Validate the response structure before mapping fields into another system.
- Keep automatic actions separate from suggestions that require approval.
- Define a fallback for missing, contradictory or low-confidence information.
- Prevent duplicate processing with an event identifier or idempotency check where needed.
- Log enough context to investigate a result without storing unnecessary sensitive data.
Human review is most effective when it is designed as a normal route, not an emergency exception. A reviewer should see the original input, the AI suggestion, the reason for the route and the action they need to take. Their decision should update the business record so the workflow has a clear outcome.
Test variation before production use
Testing one successful example is not enough for a workflow whose output can vary. Create a test set containing clear inputs, incomplete inputs, contradictory information, long messages, unusual wording and cases that should be escalated. Run the same input more than once to observe whether the variation affects the route or only the wording.
Evaluate the complete business outcome, not just whether the model response sounds plausible. Ask:
- Did the response fit the allowed structure?
- Did the router choose the correct business path?
- Was ownership assigned clearly?
- Could a reviewer understand why the item was escalated?
- Did the automation create duplicate records or actions?
- Was the final state visible in the system used for reporting?
A useful test result is not only “the answer was correct.” It is evidence that the workflow reached an acceptable state or safely stopped when it could not.
Monitor the workflow as an operating process
Once live, monitor the parts of the process that affect decisions and workload. Track volumes, validation failures, review rates, routing outcomes, duplicate events and the time taken to reach a final state. These measures help distinguish a model problem from a process problem.
For example, a high review rate may mean the model needs improvement, but it may also indicate that the categories are too broad, the source data is incomplete or the confidence threshold is poorly chosen. Review a sample of both automatically processed and escalated items. Capture human corrections where they can improve the prompt, the categories or the upstream data.
Keep a record of meaningful changes to prompts, model settings, validation rules and routes. Without change visibility, a later increase in errors can be difficult to explain.
Example: triaging an ambiguous sales enquiry
Consider a hypothetical business receiving enquiries through a website form and email. Some messages contain a clear product request, while others combine questions about pricing, implementation and support. A rigid keyword workflow may miss the main intent.
A Make.com scenario could capture the message, retrieve the associated company record and ask an AI module to identify the primary enquiry type, extract requested capabilities and flag missing information. The response would then be validated against approved categories. Clear cases could create or update a CRM task for the appropriate team. Messages containing multiple competing intents or insufficient information could go to a review queue with the extracted evidence attached.
The important design choice is not that AI made the classification. It is that the workflow defined what classification means, who owns the next step and when the system must not act automatically. If the process later changes, the routing rules and business states can be revised independently of the wording prompt.
Connect the scenario to the wider operating system
An AI scenario is only useful if its result appears where the team already manages work. If an output is stored only in a scenario log, it may be difficult to act on, report on or audit. Map important outputs to the system of record, such as the relevant CRM, service platform or work management system.
For organisations reviewing their wider architecture, [ConsultEvo’s CRM consulting service](https://consultevo.com/services/crm/) covers CRM structure, pipeline design, automation and integrations. The purpose of that work is not to add an AI step for its own sake. It is to ensure that records, ownership, workflow states and reporting support the decisions the business needs to make.
Broader examples of connected automation and operational systems are available in [ConsultEvo’s client work portfolio](https://portfolio.consultevo.com/work/). The relevant lesson is that automation creates more value when it connects data, decisions and ownership across a process rather than operating as an isolated experiment.
When Make.com nondeterministic automation is a good fit
This approach is a strong fit when there is meaningful unstructured input, several acceptable outputs and a clear way to evaluate the result. Suitable tasks may include classifying enquiries, extracting structured data from documents, ranking opportunities for review, drafting internal summaries or suggesting next actions.
It is a weaker fit when the action has a high impact but no review path, when the source data is inaccessible or unreliable, or when the decision can be expressed more simply with deterministic rules. In those cases, improve the process definition or data foundation before adding AI.
The more consequential the action, the less acceptable it is to let an unvalidated AI output directly change the business state.
Make.com can help coordinate a flexible AI step, but it cannot decide what the organisation considers acceptable risk, who owns an exception or which metric proves that the process is working. Those decisions belong in the operating design before the scenario is built.
Frequently asked questions
What is nondeterministic automation in Make.com?
It is an automation pattern that uses AI to interpret inputs or generate options where the output may vary, while deterministic workflow steps control validation, routing, ownership and system actions.
How is nondeterministic automation different from standard automation?
Standard automation aims to produce the same result from the same conditions. Nondeterministic automation allows variation in interpretation or generated content, so it needs defined acceptable outputs, validation and exception handling.
Should every AI result in Make.com be reviewed by a person?
No. Low-risk, well-tested outputs can often be processed automatically. Human review is appropriate when the input is ambiguous, the consequence is significant, the validation fails or the workflow cannot establish a reliable business state.
How should a Make.com AI workflow be tested?
Test repeated runs with clear, incomplete, contradictory and unusual inputs. Evaluate routing, ownership, duplicate prevention, validation failures and final business states, not only whether the generated text appears reasonable.
What should be logged in a nondeterministic workflow?
Log a reference to the source event, the relevant input context, the AI output, validation result, selected route, assigned owner and final decision, while following the organisation's data retention and privacy requirements.
Design AI automation around a real operating process
If your Make.com scenario is producing variable outputs but ownership, validation or reporting remain unclear, ConsultEvo can help define the process and design a more reliable automation system.