How to Share Reusable AI Agents Across Teams in Make

Introduction

Most teams build their first Make AI agent for one job, then watch the same job come up again in another scenario, another team, and another client. Rebuilding the agent each time wastes the one asset that should compound: the tested prompt, the tool setup, and the guardrails that already work. Make’s next generation of AI agents, announced in October 2026, was designed to fix exactly that. Agents now live inside the scenario builder, and Make describes them as assets to share across scenarios, teams, and clients instead of one-off experiments. This tutorial shows you how to do that: share inside one team, reuse one agent across many scenarios, move it to another team or client, and govern it so every copy stays consistent.

Quick answer

In Make, an AI agent belongs to a team, so team members can use it. Reuse it across scenarios with the Run an agent module, and across teams or clients by duplicating it or exporting and importing the scenario blueprint.

Evidence

The sharing story is not a workaround. It is the product direction. In its October 2026 announcement, Make invited users to “build AI agents you can share across teams and workflows, orchestrating processes across 3000+ apps,” combining adaptive AI decision-making with transparent automation on one visual platform. The companion post on the next generation of agents states the point even more directly: “Share them across scenarios, teams, and clients so more collaborators can benefit from your agents.” That is the sentence to design around.

The underlying access rule is simple and worth memorizing. Make’s help center states: “AI agents are shared across all team members, like connections. If you’d like to have a private agent, use a team where you’re the only member.” This help page is flagged as reflecting the previous version of Make AI Agents, but the October 2026 announcement confirms the same shareability for the new generation, and adds the Library of Agents: ready-made examples for workflows such as inventory management, research, triage, and reporting. Two hard numbers anchor this tutorial, both current as of October 2026: agents orchestrate across 3000+ apps, and an imported scenario blueprint must stay below 2 MB or Make cannot save the scenario. If you have already built agents in the scenario builder, this tutorial extends that work: our guide to building next-gen Make AI Agents in the scenario builder covers the first build.

Prerequisites

Before you start, gather this:

• A Make account with access to AI Agents in your organization. The next generation agents rolled out in stages, so if your workspace still shows the older AI Agents tab, the team sharing rules in Step 2 still apply.
• One working agent to share, or a clear job description for the template you will build.
• Team admin rights, or an admin who can invite members to the team that owns the agent.
• A test record for every scenario the agent will serve, so you can verify each copy after sharing.
• A naming convention for agents and blueprint files, decided before you share anything.

Step 1: Design the agent for reuse before you share it

A reusable agent differs from a personal assistant. It has one job, named in its system prompt, and it takes variable inputs from the scenario that calls it instead of hard-coding client names, sheet IDs, or inbox addresses. Follow these rules while building the template:

1. Give the agent a single responsibility, such as triaging support tickets or drafting weekly reports. Agents that try to do three jobs accumulate contradictory instructions and break in a second team’s context.
2. Put every client-specific or team-specific value in the scenario inputs, not in the system prompt. When the scenario calls the agent, it passes the values the agent needs, which is what makes the same agent work for the next team without editing.
3. Keep the tool list minimal. Give the agent only the apps and modules the job requires, and prefer read-only tools for the first shared version. Add write tools later, after the team has tested the agent’s decisions.
4. Add an approval step before any external action. The agent can draft a reply, a ticket update, or a report, but a person or a filter should approve it before it leaves Make. This guardrail is what makes other teams trust your agent.
5. Test the agent with the in-canvas chat and the Reasoning panel before sharing. The Reasoning panel shows which tools the agent called and why, so you can catch a bad instruction before other teams inherit it.

An agent that passes these five checks is a template. One that does not is a draft, and sharing a draft multiplies its problems.

Step 2: Share the agent inside one team

This is the simplest sharing path, and it requires no export at all. Because an agent belongs to a team, every member of that team sees it in the AI Agents tab in the left sidebar, with options to create, duplicate, configure, and delete agents.

1. Open your organization and switch to the Users tab, named Org Users on Enterprise plans.
2. Click the +Invite user button.
3. In the Invite user dialog, enter the invitee’s email and name, select a role, select the team that owns the agent, and click Save.
4. The invitee receives an email invitation. Once they accept, the agent appears in their AI Agents tab.
5. To remove someone, open their entry in the Role column and select None. Make removes the user from the team role, which effectively removes them from the team.

Roles determine what a member can do with the team’s data, so assign the lowest role that still lets the person do their job. A teammate who only needs to run scenarios should not hold a role that lets them delete the shared agent. If you need a private agent after all, create a team where you are the only member and move the agent there, since there is no per-agent visibility switch.

Step 3: Reuse one agent across many scenarios

Sharing inside a team is only half the value. The other half is calling the same agent from many scenarios, so one improvement reaches every workflow that uses it.

1. Open the scenario that needs the agent and add the Make AI Agents module Run an agent.
2. In the Agent field, select your shared agent.
3. Add tools to the agent call as the scenario requires. You can attach a scenario as a tool by choosing an existing one or creating a new one, and it must end with a Return outputs module if the agent needs its result back.
4. Save the scenario and run it once with a test record, checking the Reasoning panel to confirm the agent chose the tools you expected.
5. Repeat for each additional scenario. Every scenario now references the same agent, not a copy.

This reference model is powerful and dangerous in equal measure. Editing the shared agent’s prompt or tools changes the behavior of every scenario that calls it, which is what you want for a bug fix and what you do not want for an experiment. Before any experimental change, duplicate the agent in the AI Agents tab and point your test scenario at the duplicate. Promote the duplicate to the shared name only after it passes testing.

Step 4: Share the agent with another team

When the receiving team is in the same organization, duplicating the agent is the fastest path. Open the AI Agents tab, duplicate the agent, and place the copy in the target team. Teammates there will see it immediately and can adapt its prompt and tools without touching your original. The trade-off is that the two copies evolve independently: a fix in the original does not reach the duplicate, so this path suits teams that genuinely need different behavior.

If both teams should stay in sync, do not duplicate. Keep one canonical agent in one team, and let the second team call it through a shared scenario, or expose the scenario through another route, such as the Make MCP server. Our tutorial on turning Make scenarios into callable MCP tools explains the exposure step. Choose duplication when divergence is acceptable, and a single canonical agent when consistency matters more.

Step 5: Hand the agent to a client with a blueprint

Clients usually live in a different organization, so team membership is not available. The supported handoff is a scenario blueprint: a JSON file describing the scenario’s modules, mappings, and layout, without carrying credentials.

1. Finalize the scenario that hosts the agent. Replace every client-specific value with a scenario input or a labeled configuration module at the start, so the client can swap values in one place.
2. Export the blueprint from the scenario menu. Save the file with a versioned name, such as ticket-triage-agent-v1-2026-10-27.json.
3. Send the file to the client. The import must happen in their own organization, so the scenario will run on their operations quota, not yours.
4. The client creates a new scenario first, then opens the three dots in the upper-right corner of the Scenario Builder and selects Import blueprint. Importing into an unsaved scenario discards its changes, so starting fresh matters.
5. The client selects the JSON file and clicks Save. The imported blueprint must be below 2 MB, and the client should then configure their own connections, make any necessary edits, and schedule the scenario.
6. The client reconnects every app module with their own credentials. Connections never travel inside a blueprint, so every module touching an external app needs attention. Webhook URLs regenerate on import, so update the sending service with the new URL.
7. Run the scenario once with a test record, check every module output, then turn on scheduling.

Document the handoff in one page: what triggers the scenario, where errors are reported, how to pause it, and which blueprint version the client runs. When the master version changes, send a new dated blueprint and a short changelog rather than editing the client’s copy by hand.

Step 6: Start from the Library of Agents when it fits

Make’s Library of Agents gives you ready-made agent examples built for real workflows, not demos, covering inventory management, research, triage, and reporting. Each example shows how deterministic automation and agentic reasoning work together. Use a library agent as your template when its job matches yours, then adapt the prompt, tools, and guardrails to your data, and test it with the in-canvas chat before sharing. A library agent saves you the blank canvas, but not the testing. The team that deploys an untested template owns its mistakes.

Step 7: Govern the shared agent

Sharing without governance produces copies nobody trusts. Put these five rules in place before the second team adopts your agent:

1. One owner per agent. The owner approves prompt changes, reviews Reasoning panel logs after incidents, and decides when a new version ships.
2. One naming convention. Prefix agent names with their domain, such as support-ticket-triage or sales-lead-qualifier, and never reuse a name for a different job.
3. One changelog. Every prompt or tool change gets a dated line: what changed, why, and which scenarios were tested.
4. One versioned blueprint export per release. Export after every approved change, and keep at least the previous version as your rollback.
5. One test before every release. Run the agent against a fixed set of test records, including one malformed input, and confirm the outputs before the new version reaches other teams.

Troubleshooting

A teammate cannot see the agent

The usual cause is team membership, not a bug. Confirm the teammate is a member of the team that owns the agent, not just of the organization: organization roles do not grant team membership, and this mismatch also causes permission errors when activating scenarios. Ask an admin to check the team’s member list, add the teammate with the right role, and have them refresh the AI Agents tab. If they still cannot see it, check they are in the correct organization, since users can belong to more than one.

An imported blueprint shows disconnected modules

This is expected behavior, not corruption. Blueprints carry module configuration but never credentials, so every app module needs reconnecting in the importing organization. Click each highlighted module, authenticate with the importing team’s account, and remap variables that reference the old organization. Check webhook modules specifically, because their URLs regenerate on import, and update the sending service before turning on scheduling.

The blueprint import fails or the scenario cannot be saved

First check the file size. Make requires imported blueprints to stay below 2 MB, and a scenario over the limit cannot be saved. Split a large scenario into smaller ones, for example by moving a branch into its own scenario, then export again. If the size is fine, confirm the file is valid JSON exported from Make, not hand-edited. Re-export a fresh copy, import it into a new scenario, and reconnect the modules before other edits.

An edit to the shared agent broke several scenarios at once

That is the reference model working as designed, and the fix is process, not a setting. Roll back by importing the previous dated blueprint into a test scenario, verifying the outputs, and reapplying only the intended change. Going forward, duplicate the agent before experimenting, point test scenarios at the duplicate, and promote it only after it passes the fixed test set from Step 7. If you cannot afford that discipline, give each scenario its own duplicated agent and accept that fixes must be applied several times.

The agent behaves differently after a client handoff

Check the model and the connections first. A client who connects a different AI provider model, or reconnects an app with an account that sees different data, will get different behavior from the same prompt. Compare the model setting and system prompt with your master copy, run the same test record on both sides, and read the Reasoning panel to find where the runs diverge. Most post-handoff differences trace to data or model differences, not to the blueprint itself.

Conclusion

Reusable agents repay the effort of building them once, then pay out every time another team, scenario, or client adopts them. The rules are short: keep agents in the team that should see them, reuse one agent across scenarios through the Run an agent module, hand clients a versioned blueprint instead of access to your organization, and govern the shared copy with an owner, a changelog, and a dated export. For a broader platform comparison before you commit a team to Make, see our n8n versus Make comparison for AI agents. Build the template once, test it properly, and let every team benefit from the same tested agent.

Frequently asked questions