Make's AI Agent (New) module lets you build an agent on the same canvas as your other scenarios, no code required. This guide builds a property management agent that looks up maintenance tickets freely but only proposes a vendor payment over Slack, waiting for a manager's reply before a second scenario lets it actually process the payment. You'll configure the agent, add two tools, and test it in Make's chat panel. Budget 30-45 minutes on Make's free plan.
| Fact | Value |
|---|---|
| Tool | Make |
| Difficulty | Beginner |
| Time required | 30-45 min |
| Compatibility | Make account (Free plan works for testing), a connected Slack workspace, a maintenance tracker (Airtable or Google Sheets), browser only |
| Last updated | November 2026 |
What you'll build
You'll build a maintenance coordinator agent for a property management company. It can look up a maintenance ticket's status and assigned vendor whenever someone asks, and when a repair needs a vendor paid, it proposes the payment in a Slack message instead of processing it directly. Only after a property manager replies to that Slack message does a second scenario hand the conversation back to the agent, which can then call the actual payment tool.
Make's AI Agent (New) app gives you a Run an agent module you drop into any scenario. Its settings cover the AI provider and model, the instructions that define the agent's job, and a Conversation ID that ties multiple runs together so the agent remembers earlier context, such as which ticket it's discussing, across separate scenario executions. Other modules, built-in or from any of Make's 3,500+ integrations, become tools by clicking Add tool on the agent module; the Reasoning panel then shows each decision the agent makes, step by step, as it runs.
Make doesn't have a single built-in approval toggle per tool. Its own documented pattern for gating a risky action is to have the agent send its proposed output to a human for review through another tool, like a Slack message, and explain that extra step in the instructions. This guide builds exactly that: a propose-and-wait pattern using two linked scenarios and a shared Conversation ID, instead of a dedicated approval switch.
Prerequisites
- A Make account (the Free plan is enough to build and test an agent)
- A connected Slack workspace for approvals
- A maintenance tracker in Airtable or Google Sheets with ticket status and vendor info
- No coding experience required, just comfort filling in module settings on a canvas
Step-by-step guide
Plan the agent before you open the canvas
Write down, in plain language, what the agent's job is, which tools it needs, and exactly where a human must step in. For this agent: look up a ticket (always automatic), and propose a vendor payment over Slack and wait for a reply (always gated) before actually processing it. Having this on paper first makes the Instructions field in step 3 much easier to write well.
1Plan:2Job: maintenance coordinator for a property management company3Tool 1 (automatic): look up a maintenance ticket by ID, return status + vendor + estimated cost4Tool 2 (gated): propose a vendor payment in Slack, wait for a manager's reply before processing it5Gate mechanism: Slack reply re-invokes the agent with the same Conversation IDExpected result: A short written plan you can turn directly into the agent's instructions and tool list.
Create the scenario and add the AI Agent module
In Make, create a new scenario. Click the plus icon on the canvas, search for Make AI Agent (New), and click Run an agent to add it. This single module is where you'll configure the agent's model, instructions, tools, and memory in the following steps.
1Add module: Make AI Agent (New) > Run an agentExpected result: The Run an agent module appears on the canvas, ready to configure.
Configure the connection, model, and instructions
Open the module and set its Connection: pick Make's AI Provider on the Free plan, or your own OpenAI/Anthropic Claude connection on a paid plan. Choose a current model, then write the agent's Instructions describing its job and the approval rule in plain language. Set a Conversation ID mapped to the maintenance ticket number, so every run about the same ticket shares memory.
1Connection: Make's AI Provider (or Anthropic Claude on a paid plan)2Model: claude-sonnet-5-53Instructions: "You are a maintenance coordinator. Always look up a ticket before4 describing its status. If a repair needs a vendor paid, propose the amount5 and vendor in Slack and wait. Never say a payment was made unless the6 process_vendor_payment tool actually ran."7Conversation ID: {{ticket.id}}Expected result: The module shows a configured connection and model, with your instructions saved in the Instructions field.
Add the read-only tool: look up a maintenance ticket
Hover over the plus icon on the Run an agent module and click Add tool. Search for your tracker app (Airtable or Google Sheets), add its search/lookup action, and point it at your maintenance tracker. This tool is safe for the agent to call automatically since it only reads ticket data.
1Add tool: Airtable - Search Records (or Google Sheets - Search Rows)2Table/Sheet: Maintenance Tickets3Search field: Ticket ID4Returns: status, vendor, estimated_cost, unitExpected result: Asking the agent in chat about a real ticket ID triggers a visible tool call and returns its actual status and vendor.
Add the approval tool and the scenario that resumes after it
Add a second tool: Slack - Send a message, posting the proposed vendor and amount to a review channel and asking for a yes/no reply. This is Make's documented tool-output-validation pattern: the agent's instructions already tell it to wait after this tool runs. Then build a second scenario, triggered by Slack's New channel message event, that maps the reply's thread ID into the same Conversation ID and passes the reply text into another Run an agent call; this is what lets the agent continue and, on approval, call a real payment module (your accounting app or an HTTP action against your payments API).
1Tool (scenario 1): Slack - Send a message2Channel: #maintenance-approvals3Text: "Approve ${{amount}} to {{vendor}} for ticket {{ticket.id}}? Reply yes/no."45Scenario 2 (separate): Slack - Watch Channel Messages (trigger)6 -> Make AI Agent (New) > Run an agent7 Conversation ID: {{thread_id}} (same value as scenario 1's ticket.id)8 Input: {{message.text}}9 -> on approval, agent calls process_vendor_payment toolExpected result: A Slack message appears proposing the payment; replying 'yes' in that thread triggers scenario 2, which resumes the same agent conversation and lets it process the payment.
Test with the chat panel, then activate both scenarios
Before going live, hover over the Run an agent module and click Chat, or right-click it and choose Chat with Agent. Send sample requests covering a real ticket lookup and a full payment proposal, watch the Reasoning panel for each tool call, and fix any tool or instruction issues you see. Once both scenarios behave correctly end to end, including a 'no' reply correctly stopping the payment, turn both scenarios on.
1Test script:21. "What's the status of ticket MT-118?" -> expect Search Records call, no Slack message32. "MT-118 needs a $340 payment to Rosa's Plumbing" -> expect a Slack proposal message43. Reply "yes" in the Slack thread -> expect scenario 2 to fire and the payment tool to run54. Reply "no" on a different ticket -> expect the agent to acknowledge and NOT call the payment toolExpected result: All four test cases behave as expected in the Reasoning panel before you activate the scenarios for real traffic.
Complete working example
1# Make AI Agent spec: Property Maintenance Coordinator2# Scenario 1 holds the agent + lookup tool + Slack proposal tool.3# Scenario 2 resumes the same conversation after a Slack reply.45scenario_1:6 trigger: Webhook or manual Run (ticket request comes in)7 module: Make AI Agent (New) > Run an agent8 connection: Anthropic Claude (or Make's AI Provider on Free plan)9 model: claude-sonnet-5-510 conversation_id: "{{ticket.id}}"11 instructions: |12 You are a maintenance coordinator for a property management company.13 Always call look_up_ticket before describing a ticket's status.14 If a repair needs a vendor paid, call propose_vendor_payment to post the15 amount and vendor to Slack, then wait. Never say a payment was made16 unless process_vendor_payment actually ran in a later turn.17 tools:18 - name: look_up_ticket19 module: Airtable - Search Records20 config:21 table: Maintenance Tickets22 search_field: Ticket ID23 returns: [status, vendor, estimated_cost, unit]24 approval: none (read-only)25 - name: propose_vendor_payment26 module: Slack - Send a message27 config:28 channel: "#maintenance-approvals"29 text: "Approve ${{amount}} to {{vendor}} for ticket {{ticket.id}}? Reply yes/no."30 approval: this IS the approval step - the agent then waits for scenario_23132scenario_2:33 trigger: Slack - Watch Channel Messages (reply in the approval thread)34 steps:35 - map: thread_id -> conversation_id (must match scenario_1's ticket.id)36 - module: Make AI Agent (New) > Run an agent37 conversation_id: "{{thread_id}}"38 input: "{{message.text}}"39 tools:40 - name: process_vendor_payment41 module: HTTP (or your accounting app's create-payment action)42 config:43 url: "https://api.example-accounting.com/payments"44 method: POST45 body: { vendor: "{{vendor}}", amount: "{{amount}}", ticket_id: "{{ticket.id}}" }46 approval: only reachable after a 'yes' reply resumes this conversation4748test_cases:49 - input: "What's the status of ticket MT-118?"50 expect: look_up_ticket called, no Slack message sent51 - input: "MT-118 needs a $340 payment to Rosa's Plumbing"52 expect: propose_vendor_payment called, agent then waits53 - input: "yes" (Slack reply, scenario 2)54 expect: process_vendor_payment called with the proposed amount and vendor55 - input: "no" (Slack reply, scenario 2)56 expect: agent acknowledges, process_vendor_payment NOT called57Common mistakes
Why it's a problem: Using different Conversation ID values in scenario 1 and scenario 2
How to avoid: Map the Slack thread ID back to the same ticket ID (or vice versa) so both scenarios reference the identical Conversation ID. A mismatch starts a brand-new, context-free conversation.
Why it's a problem: Giving the agent the real payment tool directly in scenario 1 instead of only in the resumed scenario 2 call
How to avoid: If the payment tool is available before a human has replied, the agent can call it before anyone approves anything. Keep it reachable only from the conversation turn that follows a Slack reply.
Why it's a problem: Leaving Conversation ID blank and expecting the agent to remember the ticket across scenario runs
How to avoid: An empty Conversation ID generates a new, memoryless ID on every run. Always map it explicitly to something stable, like the ticket or thread ID.
Why it's a problem: Writing instructions that describe the tools but never state the approval rule itself
How to avoid: Say explicitly: never claim a payment happened unless process_vendor_payment actually ran. Without that line, the agent may narrate an action it never took.
Why it's a problem: Skipping the Reasoning panel during testing and only checking the final chat reply
How to avoid: The final reply can look correct even when the wrong tool ran or no tool ran at all. Check the Reasoning panel for the actual sequence of calls before trusting a test as passed.
Best practices
- Split any action that needs human sign-off into a propose-and-wait tool plus a second scenario that resumes the conversation after the human responds.
- Always set an explicit Conversation ID that both scenarios share, mapped to a stable value like a ticket or thread ID.
- Write the approval rule directly into the agent's instructions, not just into the tool descriptions.
- Use the Reasoning panel during every test run, not just the final answer, to confirm the right tools ran in the right order.
- Keep Steps per agent call and Maximum conversation history set to sane limits so a confused run fails fast instead of looping.
- Test a clear denial path (a 'no' reply) as carefully as the approval path before activating either scenario.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have a Make AI Agent (New) setup split across two scenarios: scenario 1 has look_up_ticket and propose_vendor_payment (Slack), scenario 2 resumes the same Conversation ID after a Slack reply and can call process_vendor_payment (spec below). Add a third tool that logs every approved payment to a Google Sheet for audit, called right after process_vendor_payment succeeds. [paste complete_code]
In Make's scenario editor, open the Run an agent module and use Maia (Make's AI assistant) to ask: 'Add a tool that checks if this vendor already has a pending payment proposal before creating a new Slack message, so we don't double-propose the same payment.'
Frequently asked questions
Do I need to know how to code to build an ai agent with Make?
No. Every step in this guide happens on Make's visual canvas: adding modules, filling in settings fields, and writing plain-language instructions. The only thing that looks like code is a mapped variable like {{ticket.id}}, and you just select it from a list rather than typing it by hand.
Does Make's AI Agent have a built-in approval toggle like n8n's Human review?
Not a dedicated toggle. Make's own documentation recommends the pattern this guide uses: add a tool that sends the agent's proposed output to a human for review, such as a Slack message, and explain that extra step in the agent's instructions.
What's the Conversation ID field actually for?
It ties multiple Run an agent calls together into one ongoing conversation, so the agent remembers earlier messages and tool results. Leave it blank and the agent generates a new ID with no memory on every single run, which breaks the two-scenario approval pattern in this guide.
Can I use OpenAI or Anthropic instead of Make's own AI Provider?
Yes, on a paid plan. The Free plan is limited to Make's AI Provider; paid plans let you connect your own OpenAI or Anthropic Claude account for the Connection field, which also unlocks prompt caching on supported Claude models.
What does this cost to run?
Make bills in credits and operations rather than a flat per-agent fee. The Free plan includes 1,000 credits a month; paid plans start around $12-16/mo (10,000 credits) and AI-provider actions can use more than one credit per call depending on the model and token volume.
Can someone set this up for me instead of building it myself?
Yes. RapidDev builds and hardens Make agents, including multi-scenario approval flows and the audit logging most tutorials skip. A free 30-minute consultation is the fastest way to scope your version.
Talk to an Expert
Our team has built 1,000+ apps. Get personalized help with your project.
Book a free consultation