Skip to content
ConsultEvo

Make AI Agents (New): What Changed and How to Design a Reliable Workflow

Make AI Agent (New) is an open-beta app in Make’s Scenario Builder. It combines an agent with configurable tools, allowing the agent to interpret an input, select from permitted tools, and return an output to the surrounding scenario.

That makes it useful for tasks such as interpreting a lead email, preparing a Gmail draft, and sending the draft link to Slack for review. It does not make an agent the right choice for every decision. Stable conditions are usually safer and easier to audit as ordinary filters, routers, or validation steps.

Make introduced the next-generation AI Agents concept in 2025 and announced the available experience on February 11, 2026. This guide focuses on the current app, what depends on plan or model, and how to design workflows with bounded tools, validated outputs, and clear ownership.

What are the next-generation Make AI Agents?

The current product name is Make AI Agent (New). In a scenario, you add the Make AI Agent (New) > Run an agent module, provide instructions and inputs, and configure the tools the agent may use. Modules before the agent can prepare data, while modules or routes after it can validate and act on the result. Make’s current AI Agent documentation hub and February 2026 product announcement describe the current product direction and setup context.

This is no longer only a proposed visual-agent roadmap. The original 2025 announcement described a future-oriented vision, including Scenario Builder integration, execution visibility, reuse, and adaptive routing. Current documentation describes an available open-beta app with a Reasoning tab, file handling, structured outputs, sharing, and a Library of Agents. Availability and behavior can change while the app remains in beta.

A deterministic workflow follows explicit conditions. For example, a router can send a lead to a known destination when its label equals Qualified. An agent is more appropriate when the input needs interpretation, such as deciding what an unstructured inquiry is asking for or extracting a defined set of fields from a document.

Execution steps, tool activity, inputs, context information, and applicable model reasoning can help a team inspect a run. They support troubleshooting and review, but they do not guarantee that a factual answer is correct, that reasoning is complete, or that structured output satisfies a business rule.

What is available now, and what depends on plan, provider, or model?

Make documents Make AI Agent (New) as an open-beta app and says its functionality and pricing may change. It is available on all plans when using Make’s AI Provider. Custom AI-provider connections are available on paid plans. Before designing around a provider, model, file type, or shared agent, check the current app reference and the capabilities of the selected provider and model.

The current app documents tools from modules, scenarios, and third-party MCP servers. The older Module Tools documentation describes a previous version of Make AI Agents and should not be treated as the complete reference for the current app.

The app provides a chat interface for testing and execution metadata. The Reasoning tab can show instructions and inputs, execution steps, tool activity, processing speed, context usage, fallback-connection use, token-related information, and model reasoning in applicable cases. The information shown depends on the model and provider. Make does not promise that every model exposes the same reasoning detail.

Structured response formats, including JSON or a custom data structure, help shape an output. They do not establish semantic correctness, enforce every allowed value, or prove that a downstream database will accept the data. Add deterministic validation before a write or consequential action.

Make documents binary JPG, PNG, GIF, and PDF inputs. Documented generated file formats include PDF, DOCX, TXT, and CSV, subject to provider and model support. A URL or base64 string is not automatically a usable file input without the appropriate download or conversion step. For unsupported document formats, Make documents a pattern using HTTP > Download a File, Make AI Content Extractor > Extract text from a document, and a text-mapping step before the agent.

Make also documents public sharing and a Library of Agents. Treat shared examples as starting points. Review their permissions, tools, prompts, knowledge sources, and destination actions before adapting them to an operational scenario.

A practical design rule: automate rules; delegate interpretation

Use a filter or router when a stable, auditable condition determines the outcome:

  • A required label is present.
  • An amount exceeds a fixed threshold.
  • A country is on an allowlist.
  • A record has a known status.
  • A file has an allowed MIME type.

Use an agent when meaning must be interpreted, such as inferring intent from an email, summarizing a document into specified fields, or selecting between a bounded set of research tools.

If a stable condition can make the decision, make it a rule. Use an agent when the input’s meaning must be interpreted.

The following comparison keeps the agent’s responsibility narrow and makes the fallback explicit.

Trigger or source Agent job Validation and action Fallback
Labeled lead email Interpret fit and propose a response Check source IDs, recipient, citations, and calendar scope; create a draft Sales or operations review
Downloaded supported file Extract named fields Validate types, required values, identity, and contradictions; write a record Document-operations review
Email, chat, form, or webhook Interpret intent and choose from limited tools Reject invalid actions and route approved outputs Workflow owner or business reviewer

For a new scenario, use the following chain. The sequence is an implementation recommendation, not a native Make template.

01Receive and identifyCapture the source event and a stable identifier. Keep the source application as the record of what arrived.
02Prepare and filterMap required fields and apply eligibility, format, and duplicate checks before spending an agent call.
03Delegate a bounded taskProvide defined inputs, permitted tools, and a requested output. The scenario owner controls the tool scope.
04Validate and choose an actionCheck required fields, allowed values, source identity, and review conditions before writing or sending anything.
05Route exceptions to an ownerSend malformed results, tool failures, and ambiguous cases to a named operator rather than treating them as successful output.

Pattern 1: qualify a lead and prepare a reviewable response

Make’s sales-outreach guided example is a documented pattern for a reviewable draft, not evidence of measured qualification accuracy. Its sequence is:

  1. Gmail watches labeled lead emails. The scenario maps the sender email, sender name, subject, body, date, and Gmail thread ID.
  2. Make AI Agent (New) interprets the inquiry. Configured tools include Make AI Web Search for research and Google Calendar availability checks.
  3. The agent proposes a qualification and response. The prompt supplies the company’s criteria and meeting criteria.
  4. Gmail creates a draft. The documented flow does not make direct sending the default action.
  5. Slack receives the draft link. A sales or operations reviewer can inspect the source email and proposed response before sending.

A proposed output contract could look like this. It is an editorial implementation example, not a Make-provided schema.

{
  "classification": "qualified | unqualified | needs_review",
  "rationale": "Short explanation tied to supplied criteria",
  "proposed_action": "draft_reply | request_information | route_to_owner",
  "source_message_id": "illustrative-message-id",
  "source_thread_id": "illustrative-thread-id",
  "citations": [
    {
      "source_url": "https://example.com/source",
      "claim_supported": "Claim supported by the source"
    }
  ],
  "requires_review": true
}

Before creating the draft, validate that the message ID and recipient match the triggering email, the proposed action is allowed, and research-derived claims have source URLs. Restrict calendar checks to the intended calendar, timezone, and business-hours policy. Route missing sender data, failed research, unsupported claims, or an unsuitable draft to the named reviewer. The scenario owner handles provider, permission, and mapping failures.

For duplicate prevention, store an event-level key such as source_system + source_message_id + workflow_version. If concurrent runs can process the same message, enforce that key with a destination database unique constraint and an atomic upsert or insert-with-conflict operation. A lookup followed by a create can race, and the Make example does not document a universal idempotency mechanism.

Two identifiers, two jobs

Use a thread-level Conversation ID when the agent should retain email context across runs. Use a separate message or event ID for duplicate prevention. Continuity and deduplication operate at different grains, so one identifier should not be assumed to do both jobs.

Pattern 2: turn a supported file into a validated business record

For file extraction, a trigger or download module retrieves binary data and maps it into Make AI Agent (New) > Run an agent > Input files. Make’s file-input guidance documents JPG, PNG, GIF, and PDF inputs. The selected provider and model must support the file.

The process should be:

  1. Download or receive the binary file and preserve its source file ID, name, MIME type, retrieval time, and checksum.
  2. Reject unsupported types or missing binary data before the agent runs.
  3. Ask the agent for explicitly named fields in a structured response.
  4. Validate the returned fields deterministically before writing a business record.
  5. Route incomplete, contradictory, or low-confidence results to a document-operations queue.

For an invoice, a proposed response might be:

{
  "document_id": "file_123",
  "supplier_name": "Example Supplier",
  "invoice_date": "2026-10-01",
  "total_amount": 1250.50,
  "currency": "USD",
  "requires_review": true
}

This schema is illustrative. Validate that required values exist, the date and amount parse, the currency is allowed, the returned document ID matches the source, and totals do not contradict other extracted values. Keep the original file ID, retrieval timestamp, and checksum outside the model-generated fields so provenance does not depend on the agent. Only write a normalized record after these checks.

For an unsupported format, Make documents a conversion route using HTTP > Download a File, Make AI Content Extractor > Extract text from a document, and text mapping before the agent. This is a documented conversion pattern, not evidence that every format is natively supported by Make AI Agent (New).

Pattern 3: preserve continuity and contain tool access

Conversation memory depends on the Conversation ID. When the field is blank, Make generates a unique ID per run, so previous communication is not remembered. Choose an ID at the intended continuity grain, such as a conversation thread or user, and avoid a broad key that could mix unrelated interactions.

Before enabling a recurring message workflow, list every configured module, scenario, or MCP tool and record whether it reads or changes data. Use the smallest set needed. Separate read access from write access where possible, and require a person to review consequential actions such as sending, deleting, paying, publishing, or changing a customer record.

A proposed recurring-message sequence could be an email, chat, form, or webhook trigger, followed by deterministic eligibility filters, the agent with limited tools, output validation, and a draft or review queue. The exact trigger and destination depend on the scenario; they should not be presented as a universal Make template.

Define terminal exception routes for permission errors, timeouts, missing inputs, malformed output, rate limits, and provider failures. Technical failures should reach the scenario owner. Messages requiring judgment should reach a named business reviewer. Do not assume Make supplies a universal approval gate, idempotency key, or transaction for downstream writes.

How to test, monitor, and improve the workflow

Test representative normal, ambiguous, incomplete, duplicate, and tool-failure cases in the app’s chat interface and through scenario runs. Inspect execution steps and available Reasoning-tab information to diagnose mapped inputs, tool calls, context usage, and processing metadata. Use these details as troubleshooting signals, not as proof that a factual claim is correct.

Track outcomes that matter to the team, such as accepted drafts, correction rate, exception rate, duplicate prevention, and time spent in human review. These are proposed operational measures, not Make-reported benchmarks.

Keep records at the correct grain:

  • Source event record: one row per Gmail message, webhook delivery, uploaded file, or other source event. A proposed unique key combines the source system, source event ID, and workflow version.
  • Agent-run record: one row per invocation, including the source event ID, run ID, attempt number, prompt or workflow version, and model or provider variant where useful.
  • Citation record: one row per cited source URL and claim. Do not collapse several citations into one daily or domain-level row.
  • Aggregate report: one row per entity, query set, model or engine variant, and reporting period. Keep it separate from individual events, runs, and citations.

When concurrent processing is possible, enforce uniqueness at the destination and use an atomic upsert or insert-with-conflict handling where available. Treat an already-existing unique key as an idempotent replay, and record separate attempts if retry analysis matters. This is an implementation recommendation, not a documented native Make idempotency feature.

Review exceptions regularly. Tighten a deterministic filter when the input should have been rejected earlier, clarify the task when interpretation is consistently ambiguous, narrow tool access when the agent has unnecessary reach, and remove the agent when the decision does not require interpretation.

When Make AI Agent (New) is a good fit

Use the agent when interpretation is valuable, the available tools and output are bounded, and a validation or review path exists. Do not use it as a substitute for simple rules, a system of record, or deterministic field validation. Start with a low-risk workflow that creates a draft or structured proposal, then expand permissions only after the exception path works.

Before the first rollout
  • Define the task, source event, and intended continuity grain.
  • List permitted tools and separate read access from write access.
  • Specify output fields, allowed values, and deterministic validation rules.
  • Name the owner for invalid results, tool failures, and judgment calls.
  • Choose an event-level duplicate key and enforce it at the destination.
  • Set an outcome measure such as correction rate or review time.
  • Confirm current beta, plan, provider, model, and file-format constraints.

If you are applying this pattern to an existing scenario, see Make automation consulting. For a bounded agent workflow, AI agent implementation support can help define the tools, validation, and operational ownership.