How to Set Up AI Agents in Make.com: Tools, Prompts and Testing

What an AI Agent does in Make.com

A conventional Make scenario follows a defined path. A trigger starts the scenario, filters evaluate conditions and modules perform known actions. An AI Agent adds a decision layer. Given instructions and input data, it can interpret the request, select from available tools and produce a response or structured result.

In this context, a tool is an action or capability exposed to the agent. It might retrieve a CRM record, search a data source, classify text, create a task or pass information to another scenario. The agent does not automatically gain access to every module in your account. Its useful and safe operating boundary is the set of tools you deliberately provide, together with the instructions and permissions around them.

This distinction matters because agent flexibility can introduce ambiguity. A workflow that needs the same calculation every time is usually better served by normal Make modules. An agent becomes more appropriate when the input is variable, language-based or difficult to handle with a long list of rigid filters.

Decide whether an agent is the right component

Before opening the Make builder, write down the business state the automation must change. For example, the input may be an unstructured customer email and the desired state may be a CRM record with a category, owner and next action. This gives the agent a defined job rather than a vague instruction such as “manage customer requests.”

A useful diagnostic question is: what decision is the agent allowed to make, and what decision remains with the workflow or a person? If the answer is unclear, the setup is not ready. The agent may need to classify a request, but a downstream filter can decide whether a record update is permitted. This separation makes errors easier to detect and correct.

Prepare the Make.com workspace

Access to AI Agent functionality depends on the Make environment, account settings and available features. Sign in to the relevant organization and review the AI or agent settings available to your team. If the feature is not visible, check the current Make documentation, plan restrictions and administrator permissions before changing the scenario design.

Also decide where the agent will be developed and where it will run. A playground or testing area is useful for experimenting with prompts and tool selection. A production scenario should have a named owner, a known trigger, defined error handling and a way to review the agent’s outputs.

Create an AI Agent with a specific operating job

Depending on the Make interface, an agent can be created while configuring an AI Agent module or through an AI-focused workspace such as a playground. The navigation and labels may change, but the design decisions are consistent:

1. Name the agent by its business responsibility. “Inbound request classifier” is more useful than “Assistant 1.”
2. Describe the input. State where the request comes from and which fields or context are available.
3. Define the allowed outcome. Specify the categories, structured fields or actions the agent can return.
4. State the boundaries. Explain what it must not do, what data it must not expose and when it must stop.
5. Define uncertainty handling. Require a clear fallback such as “needs review” rather than an invented answer.

Keep the first version narrow. An agent that classifies requests and proposes a next action is easier to test than one that classifies, updates several systems, sends messages and handles exceptions all at once.

Write prompts that describe decisions and boundaries

The system prompt should explain the agent’s role, operating context and limits. It should not contain a long collection of aspirations that cannot be checked. A practical prompt normally covers the task, available context, decision rules, tool use, output format and escalation conditions.

For example, an agent handling incoming service requests might be instructed to identify the request type, assign one approved priority, use a lookup tool only when a matching record is present and return a review status when key information is missing. The downstream scenario can then route the structured result.

Tool descriptions should answer three questions: what does this tool do, when should it be used and what information does it require? A tool called “Update record” is ambiguous. A description such as “update the existing support record after the request has been classified; do not create a new record” gives the agent a more useful boundary.

Ask the agent to return predictable fields wherever possible. A structured result might include category, confidence or review status, record identifier and recommended next action. Treat these outputs as data for the scenario, not as a final business decision unless the process explicitly allows that.

Assign tools with least-privilege access

Tools determine what the agent can do. Start with read-only tools and add write actions only when the business case is clear. A lookup, search or retrieval action is easier to control than an action that changes a CRM record or sends an external message.

For every proposed tool, document:

• The business purpose of the tool.
• The input fields it requires.
• The records or systems it can access.
• The conditions under which it may be called.
• The result returned to the agent or downstream scenario.
• Whether a person must approve the resulting action.

Do not expose multiple tools that perform nearly the same action unless the distinction is obvious. Similar tool names increase the chance of an incorrect selection. If an action has an irreversible or externally visible consequence, place a deterministic validation step or human review before it.

This is especially important for CRM and operational workflows. A clean pipeline depends on meaningful business states, visible ownership and controlled transitions. If an agent can update any field at any time, reporting may become less reliable even when individual tasks appear successful. For broader CRM process design, see ConsultEvo’s CRM consulting service.

Build the surrounding scenario around business states

The agent is only one part of the automation. The surrounding Make scenario should validate the input, supply relevant context, route the result and record what happened. A simple operating sequence is:

Consider a hypothetical example. A shared inbox receives supplier messages. The agent identifies whether each message is an invoice question, delivery issue or general request. It can search an approved supplier record and return a category and suggested owner. A normal Make router then sends delivery issues to the operations queue. It does not let the agent send an external response until the required order reference is present.

This design keeps interpretation flexible while keeping state changes and ownership visible. It also makes the workflow easier to report on because the CRM or operations system records a meaningful outcome rather than an opaque AI response.

For a broader view of connected operational systems, the Commerce and Operations Intelligence Platform portfolio example illustrates the relationship between operational data, reporting and AI-assisted access without treating AI as the whole system.

Test AI Agents before production use

Testing should evaluate decisions and actions, not just whether the agent produces fluent text. Use the playground or test interface to send representative inputs, then run the complete scenario with controlled data. Include normal requests, incomplete requests, ambiguous wording, duplicate records, tool failures and attempts to request actions outside the agent’s role.

For each test, inspect:

• Which tool the agent selected and why.
• Whether it supplied the correct inputs.
• Whether the output matched the expected structure.
• Whether the scenario blocked an unsafe or incomplete action.
• Whether ownership and business state were updated correctly.
• Whether the logs provide enough context to investigate a failure.

Change one variable at a time where possible. If the agent chooses the wrong tool, improve the tool description or reduce the available choices before adding more prompt text. If it returns the wrong category, review the examples and decision rules. If the scenario performs an incorrect write action, fix the deterministic guard as well as the prompt.

Monitor the agent after launch

Launch does not remove the need for operational ownership. Review execution history, tool calls, failed runs and escalations during the early operating period. Track practical signals such as manual rework, records routed for review, incorrect tool selection and actions blocked by validation.

Set a review rule for prompt and tool changes. A change to a tool description can alter behavior just as meaningfully as a change to the system prompt. Record what changed, why it changed and which test cases were rerun. This creates a small but useful change history for the automation.

If the workflow becomes difficult to understand, reduce the agent’s scope. More tools, more instructions and more connected systems do not automatically create a better operating system. For help designing the surrounding automation and ownership model, see ConsultEvo’s systems and automation services.

ConsultEvoClient Work: Automation, CRM and Operations SystemsA portfolio of operational problems addressed through connected systems, automation, data, AI and custom applications.→

Practical setup sequence

Use this sequence when configuring a new Make.com AI Agent:

1. Write the business outcome and the state that should change.
2. Decide whether interpretation is needed or a normal scenario is sufficient.
3. Create an agent with one clearly named responsibility.
4. Define allowed outputs, uncertainty handling and escalation rules.
5. Add the smallest useful set of tools, beginning with read-only access.
6. Place deterministic validation before important writes or external messages.
7. Test realistic, incomplete and adversarial inputs.
8. Assign an owner for monitoring, review and future changes.

The result should be an automation that is easier to explain than the prompt alone. A colleague should be able to see what the agent decides, what the scenario controls and who owns the outcome. That is the standard to aim for when setting up AI Agents in Make.com.