Make AI Agents: What They Do and How to Use Them in Workflows

Make AI Agent (New) runs inside a Make scenario through the Run an agent module. It can interpret context and select configured tools, while ordinary Make modules remain responsible for fixed rules, authorization checks, and system updates.

The useful question is not whether an agent can replace a workflow. It is where contextual judgment belongs inside a workflow that still has explicit inputs, outputs, validation, and exception handling. This guide explains the documented product behavior and shows how to design bounded, testable patterns for triage, document intake, and multi-step operations.

Use the simplest control that can reliably perform the task: deterministic modules for known conditions, an AI step for interpretation, and an agent when context affects the choice among a limited set of permitted tools. High-impact actions should pass through deterministic validation and, where appropriate, human approval.

What are Make AI Agents, and what changed?

Make AI Agent (New) is configured in the Scenario Builder. A scenario trigger supplies data to Run an agent; the agent follows its instructions, uses configured tools when needed, and returns information to downstream scenario modules. Make documents tools that can include app modules, scenarios, MCP tools, and other agents.

Make announced an earlier vision and early-access waitlist on October 16, 2025. The live page for the next-generation announcement displays February 11, 2026. The current product story places agents on the scenario canvas alongside deterministic automation, with in-canvas chat testing, file handling, execution information in supported cases, and a Library of Agents. See the historical vision announcement, the current announcement, and the agent setup guide.

Make provides access to thousands of integrations. That breadth does not prove that an agent will select the correct tool, produce accurate results, or suit a particular production process. Those questions require workflow-specific testing. Make’s reasoning or execution view is also provider and model dependent. Treat it as product-provided execution information, not as a guarantee of correctness or unrestricted access to private chain-of-thought.

When should a workflow use an agent rather than a rule?

Start with the shape of the decision. Structured data with an unambiguous condition usually belongs in a filter, router, or other deterministic module. Unstructured text or documents that need interpretation may suit an AI step. An agent becomes more useful when the task depends on context and may require selecting one option from a defined set of tools or routes.

Trigger or task	AI job	Validation and fallback	Action
Known security condition	None	Fixed filter and mandatory escalation route	Send to the approved security queue
Ambiguous support message	Classify the message and propose one permitted route	Check identifiers and allowlisted values; send conflicting cases to review	Update the ticket or create a task after approval
Invoice PDF	Extract defined fields	Check required values, currency, and arithmetic; send mismatches to accounts payable	Create a staging record, then write to accounting if approved
Context-dependent operation	Select one permitted scenario tool	Validate inputs and return structured success or failure	Continue the parent scenario or open an exception route

For example, a support inbox can send known account-security terms through fixed filters. Remaining ambiguous messages can go to an agent that returns a category and one permitted next step. A validation route checks the ticket identifier, category, action, duplicate status, and escalation policy. A human queue receives unresolved or conflicting cases. Only a validated proposal reaches the ticket-update module.

For help deciding where this boundary belongs in an existing process, see AI agent consulting.

How to build a Make AI Agent into a scenario

Define the job before selecting tools. A useful contract states what starts the scenario, which fields the agent receives, what decision it may make, and what downstream modules need back. Avoid broad instructions such as “manage support” when the actual requirement is “classify an ambiguous message and propose one allowed route.”

1. Define the trigger and task. Identify the source event, required identifiers, input text or binary file, and the single bounded decision.
2. Configure instructions and minimal tools. Describe when each tool should be used, what inputs it requires, and what it returns. Make documents app modules, scenarios, MCP tools, and other agents as possible tools. When an individual module is added as a tool, Make can create a supporting scenario automatically.
3. Specify a usable result. Request fields with known types and allowlisted values rather than a free-form paragraph that another module must interpret.
4. Test before activation. Use the in-canvas chat to submit representative requests. Inspect tool outputs and errors, then test normal, ambiguous, duplicate, and failure cases before enabling a live trigger.

A scenario exposed as a tool should have explicit inputs and outputs and a concise description that tells the agent when to call it. Return a structured status such as success, business_rejection, or technical_error rather than relying on a conversational summary. The status taxonomy is a recommended design choice, not a built-in Make field set.

For scenario architecture and operating controls, see Make automation consulting.

What files can Make AI Agents handle?

Separate one-time input files, generated output files, and persistent knowledge or context files. They are different capabilities and have different documented format lists.

Knowledge or context files have separate format lists. Do not infer that a format accepted as knowledge can also be sent as a direct run input. For unsupported input such as DOCX, Make documents a conversion pattern using Make AI Content Extractor to extract text before passing it to the agent. See the file-input guide.

In an invoice workflow, a preceding app event or file module supplies the binary PDF and source event ID. The agent extracts specified fields. A downstream route checks required values, date format, allowed currency, and arithmetic before creating a staging record. A DOCX file follows the conversion path instead of being mapped directly as an input file.

{
  "source_event_id": "email_78421",
  "invoice_number": "INV-1048",
  "supplier_name": "Northwind Parts",
  "invoice_date": "2026-04-12",
  "currency": "USD",
  "subtotal": 240.00,
  "tax": 19.20,
  "total": 259.20,
  "review_status": "needs_review"
}

The contract above is illustrative. A useful gate checks that the source event, invoice number, date, currency, and total exist; that the currency is allowed; and that subtotal plus tax equals total under the business’s rounding rule. Missing fields and mismatches go to an accounts-payable reviewer. Store the source file reference and extraction timestamp so a later correction can be tied to the original observation.

Build a validation gate before the agent can change business data

Keep an agent proposal separate from approved CRM or ERP state. The agent can return a structured proposal such as the following:

{
  "source_event_id": "ticket_52901",
  "entity_id": "cust_203",
  "classification": "delivery",
  "proposed_action": "create_task",
  "evidence_excerpt": "Two items arrived damaged.",
  "confidence": 0.91,
  "requires_review": true,
  "agent_run_id": "run_20260412_0842"
}

This is a proposed contract, not a built-in Make schema. In a CRM triage scenario, the trigger receives the event, deterministic filters handle security conditions, and the agent proposes a category and permitted action. A validation route then checks:

• The source event and target record identifiers are present and correctly typed.
• The classification and proposed action belong to approved allowlists.
• The target exists and the requested state transition is permitted.
• The source event has not already been processed.
• Deletion, financial changes, legal commitments, and externally visible messages receive the required approval.

Only the approved action reaches the CRM write module. Save the original event reference, proposal, validation result, reviewer identity when applicable, and final before and after values. These are recommended controls, not automatic Make features. For controlled system-of-record updates, CRM systems consulting may be relevant.

Use the correct grain for duplicate prevention

An inbound event and an agent run are different records. Use the source system’s stable event ID as the event-level idempotency basis where available, and retain a separate run ID for every execution. If two runs process the same event, the run records should remain distinguishable even when the event-level action is rejected as a duplicate.

Do not rely on a lookup followed by create when concurrent runs can occur. Two runs can both fail to find a record before creating duplicates. For important uniqueness guarantees, use a destination with an enforced unique key or a transactional upsert, if the selected integration supports those semantics. Verify the actual behavior of the destination rather than assuming that a Make search or data store lookup is race safe.

Illustrative grains and keys include:

• Event record: source_system + source_event_id, one row for each inbound email, webhook, ticket, or file event.
• Agent run: agent_version + source_event_id + agent_run_id, one row for each execution attempt.
• Citation or extracted evidence: agent_run_id + citation_index or a canonical source reference plus a content hash, one row per evidence item.
• Aggregate report: an entity, reporting period, model variant, and aggregation version, kept separate from raw observations and CRM contact or deal events.

The exact fields are implementation recommendations. Their purpose is to prevent a daily summary, a raw event, and a CRM update from being treated as the same row.

How to share an agent workflow and use the Library of Agents

The Library of Agents is a categorized source of cloneable examples and starting points. Inspect each listing before relying on its connections, permissions, safeguards, or scope. The library index does not establish that every example is a complete production implementation.

Public scenario sharing lets recipients inspect and copy a scenario, but credentials are excluded. Current sharing documentation also says AI Agents, data stores, data structures, and subscenarios can appear as empty modules in a copied scenario. A shared link is therefore a workflow-structure handoff, not a fully configured environment that a recipient can necessarily activate immediately.

What should teams check before regular use?

Run a controlled pilot with representative inputs. Record the selected provider and model, agent version or prompt version, run ID, credit usage, outcome, exception type, and human review time. Make documents different credit behavior for agent runs, chats, tools, knowledge, input files, and AI-token use. Do not use a universal per-run cost without specifying the provider, model, file, and current credit rules. Check the current AI Agent credit guidance before estimating volume.

Set acceptance criteria for the actual task. Useful measures include required-field completeness, exception rate, review time, duplicate rate, and incorrect-action rate. Compare the pilot with an agreed baseline before increasing volume or permissions. Use Make’s error-handling options to distinguish retryable technical failures from business-rule rejections that need a person.

For consequential workflows, keep the operating boundary explicit: the agent interprets and proposes, deterministic modules validate, and an authorized person resolves cases that the workflow cannot safely settle. Product behavior, provider support, file limits, credits, and sharing behavior can change, so check current Make documentation and the selected provider and model before deployment.