Connecting Multiple Accounts of the Same Tool (Multi-Instance Connectors)

Macha's multi-instance connectors remove that wall. You can link more than one account of the same tool to a single Macha workspace — two Zendesk accounts, three Stripe accounts, a Shopify store per brand — and each one gets its own credentials and its own name. Your agents can then act on the right account, and Macha makes sure the AI never confuses one for another. This post is a deep-dive on how that works, when you actually need it, and where the sharp edges are.

A quick reminder on what Macha is, because it matters here: Macha is an AI agent layer that sits on top of the helpdesk you already use (Zendesk, Freshdesk, Gorgias, Front) and wires in your commerce, knowledge, and comms tools. It is not a helpdesk itself. So "connect multiple accounts" isn't about logging into two inboxes — it's about giving your agents authenticated reach into several copies of the same system at once.

Why teams end up with more than one of the same tool

This is more common than the typical single-tenant onboarding flow admits. A few patterns we see constantly:

• Agencies and BPOs. A support agency manages five clients, each on its own Zendesk. The agency wants one place to build and run agents, not five disconnected logins.
• Multi-brand companies. A parent brand keeps a separate Shopify store and a separate Gorgias per sub-brand to keep catalogs, themes, and reporting clean.
• Regional or legal separation. A business runs a EU Stripe account and a US Stripe account for tax, payout, and data-residency reasons — same product, two ledgers.
• Post-acquisition reality. You bought a company. They had their own Zendesk. Merging two production helpdesks is a multi-quarter project nobody wants to rush, so for now there are simply two.
• Sandbox plus production. A test Zendesk instance alongside the live one, so agents can be validated before they touch real customers.

None of these are edge cases — they're the normal shape of a growing operation. Zendesk's own guidance on running one or multiple instances acknowledges that organizations legitimately split into separate instances when departments have different processes, security needs, and workflows. The question was never should these accounts exist — it's whether your AI tooling can keep up with the fact that they do.

How multi-instance connectors work in Macha

There are two pieces to the feature, and the second is the one that quietly does the hard work.

1. Connect multiple accounts — each with its own credentials and name

When you add a connector, Macha doesn't treat the connector type as a singleton. You can add a second Zendesk, a third Stripe, a second Shopify, and each instance is a fully independent connection with:

• its own credentials — Macha's connectors authenticate per-account (Zendesk via OAuth or API key, Stripe via API key, Shopify and Freshdesk and Gorgias via API key, Front via API token), so each instance carries its own auth and its own permission scope; and
• its own name — a human-readable label you set, like "Acme EU Stripe" or "Client: Northwind Zendesk," so you can tell them apart at a glance.

That naming step isn't cosmetic. It's the handle everything downstream uses — the connectors list, the agent's tool picker, and the disambiguation the AI relies on.

2. Automatic disambiguation — so the AI knows which account to use

Here's the problem multi-instance creates, and the part Macha solves for you. If you connect two Zendesk accounts, you now have two search_tickets tools, two update_ticket tools, two of everything. An LLM handed two identically-named tools has no reliable way to choose between them — that's a recipe for an agent replying on the wrong account.

When Macha detects more than one instance of the same connector type, it automatically disambiguates:

• Tool names are auto-suffixed with the account, so the model sees distinct tools rather than two collisions.
• Tool descriptions are tagged with the account name, so the model has explicit context — "this one operates on Northwind Zendesk" — when it decides which tool to call.

You don't configure any of this. Connect a second account and the suffixing and tagging happen on their own; connect only one and tool names stay clean and unsuffixed. The result is that an agent with reach into two Zendesks can be told, in plain language, "handle Northwind tickets here and Acme tickets there," and the tool layer makes that instruction actually resolvable.

Putting it together in an agent

Because every instance is just another set of tools, building a multi-account agent is the same flow as any other Macha agent — you pick which tools (and therefore which accounts) an agent can touch. You can scope tightly:

• One agent per account — a dedicated agent for each client/brand/region, each given only that account's tools. Clean blast radius, easy to reason about.
• One agent across accounts — a single triage agent that can read from several accounts and route or answer, leaning on the disambiguated tool names to act on the correct one.
• A router with sub-agents — a front-door agent that delegates to per-account specialist sub-agents (Macha agents can call other agents as tools), which keeps each specialist's tool list short and its instructions focused.

A worked scenario: an agency with five client Zendesks

Concretely, picture a support agency. They connect five Zendesk accounts to one Macha workspace, naming each after the client. Macha suffixes every Zendesk tool per client and tags the descriptions. The agency then builds one specialist sub-agent per client — Northwind Support, Acme Support, and so on — each scoped to only its own client's tools and knowledge sources. A top-level router agent receives the work and delegates to the right specialist.

The payoff: the agency runs all five clients from a single control plane, agents can't accidentally cross client boundaries because each one only holds one client's tools, and onboarding a sixth client is "add a connector, clone an agent," not "stand up a new system." That's the difference between multi-instance being a platform capability versus a spreadsheet of logins.

This is also where Macha's positioning pays off versus helpdesk-native AI. Zendesk's own documentation notes that an advanced AI agent can be connected to only one Zendesk account at a time — vendor-bundled agents are typically single-tenant by design. Macha sits a layer above, so one workspace reaching several accounts is the normal case, not a workaround.

Keeping multiple accounts healthy

More accounts means more credentials to keep alive, and Macha has connector-management tooling that earns its keep once you're running several:

• Test connection verifies a connector's credentials with a single click, across all connector types — so you can confirm each of your five Zendesks is actually authenticated before an agent goes live on it.
• Reconnect flow handles expiry without breakage: API-key connectors show a reconnect form when auth fails, and OAuth reconnects keep the same connector ID — no tools stripped, no agents broken. You re-auth one account without disturbing the other four.
• Token-refresh locking prevents OAuth refresh race conditions (it backs Zendesk, Google, and Shopify), which matters more, not less, when several instances of the same provider are refreshing tokens concurrently.

These aren't multi-instance features per se, but they're what make multi-instance survivable in production: every account is independently testable and independently re-authable.

Watch-outs — when multi-instance is the wrong tool

This feature solves a specific problem, and it's worth being honest about its edges:

• It is not a merge. Multi-instance keeps your accounts separate and lets agents reach all of them. If your actual goal is to consolidate two Zendesks into one, that's a data-migration project — multi-instance connectors won't do it and aren't meant to.
• Credentials still need real scopes. Each instance authenticates independently, so each account needs an API key or OAuth grant with the permissions your agents require. Five clients means five sets of credentials to provision and rotate.
• Disambiguation helps the model; it doesn't excuse vague instructions. Auto-suffixing makes the right tool selectable, but an agent told "answer the ticket" with five accounts in scope can still pick wrong. For anything sensitive, prefer one-account-per-agent (or per sub-agent) over one agent holding everything — tight tool scoping is the real guardrail.
• Tool lists get long. Two accounts double the tools an agent could see; five quintuple them. Long tool lists dilute model focus. The sub-agent pattern exists precisely to keep each agent's tool list short.
• Plans cap integrations. Each connected account counts toward your plan's integration allowance, so a fleet of accounts is a Professional/Enterprise shape rather than a Starter one. See the pricing page for current limits.

Where it fits in Macha

Multi-instance connectors are part of Macha's integrations layer — the same connectors that let an agent read a Shopify order or refund a Stripe charge, now usable more than once each. If you run a single account of everything, you'll never notice the feature is there; tool names stay clean and nothing changes. The moment you connect a second account of the same type, Macha shifts into multi-account mode automatically. For the full connector walkthrough, see the docs, and if your stack is Zendesk-heavy, the Macha on Zendesk page covers the helpdesk side.

FAQ

Can I really connect two of the same tool, like two Zendesk accounts? Yes. You can link multiple instances of the same connector — two Zendesk accounts, three Stripe accounts, a Shopify store per brand. Each instance is an independent connection with its own credentials and its own name.

How does the AI know which account to act on? Automatically. When more than one instance of a connector type exists, Macha auto-suffixes the tool names with the account and tags each tool's description with the account name, so the model can tell the accounts apart and call the right one.

Do I have to set up the disambiguation myself? No. It's automatic. With a single account, tool names stay clean and unsuffixed; add a second account of the same type and Macha applies suffixing and tagging on its own.

Is this the same as merging two helpdesks into one? No — and that's important. Multi-instance keeps the accounts fully separate and simply lets your agents reach all of them. Consolidating accounts is a data-migration project, which is a different thing entirely.

What's the cleanest way to run many accounts? Scope tightly: give each account its own agent (or sub-agent) so each one only holds one account's tools. A top-level router agent can then delegate to the right specialist, which keeps tool lists short and prevents cross-account mistakes.

Does each account need its own login or API key? Yes. Each instance authenticates independently (Zendesk via OAuth or API key, Stripe/Shopify/Freshdesk/Gorgias via API key, Front via API token), so every account carries its own credentials and permission scope.

Try it

If you've been running your AI agents around the fact that you have more than one of the same tool, you don't have to anymore. Start a 7-day free trial, no credit card required, connect your accounts — as many of each as you need — and let Macha keep them straight. More on the blog, or dive into the connector docs for the full setup.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.