Team Management & Roles in Macha: Admin vs Member

Macha keeps this deliberately simple. Your account is an organization — one shared workspace that holds your connectors, agents, knowledge sources, Studies, and a single pooled credit balance — and everyone you invite joins that organization with one of two roles: Admin or Member. This guide walks through inviting people, what each role can and can't do, and how to assign access the safe way so you get collaboration without handing every new hire the billing keys.

If you've managed roles in Zendesk, Slack, or a GitHub org, the mental model will feel familiar — it's the same least-privilege idea, just pared down to the two roles most support teams actually need.

The model: one organization, two roles

Everything in Macha is scoped to your organization. That's the unit that owns the work and pays the bill, so team management is really about answering one question: who is allowed inside this organization, and at what level?

There are two answers, and the split is builders vs. users — not "account owner vs. everyone else." This is the part people get wrong, so it's worth stating plainly (it's spelled out in the Team docs):

• Admin — full access to everything in the organization. Admins build and operate: create, edit, and delete agents; connect and manage integrations; create custom tools; set up triggers; and use agents and chat. Admins also own the account — they invite and remove teammates, manage billing and the subscription, and change organization settings.
• Member — a use-and-view role. Members can use agents and chat with them, and they can view agents, connectors, and tools read-only. They cannot create, edit, or delete agents, connectors, tools, or triggers, and they cannot manage team members or billing.

The mental model that actually holds: Admins configure the product; Members consume it. The docs put it directly — "assign the Member role to people who only need to interact with agents, and reserve Admin access for team leads or operations staff who manage the setup." So a support lead or ops owner who builds and tunes agents is an Admin; an agent who just needs to chat with a deployed agent or look at how something is wired is a Member. You can have more than one Admin — and for most teams, you should (more on that below).

Macha's role model is intentionally lean — two roles, not a twelve-row permission matrix. The trade-off is that it's coarse: there's no "can build agents but can't see billing" middle role yet. If you need someone to build, you make them an Admin. See the watch-outs before you plan around it.

Inviting your team

Team management lives in Settings → Team. As an Admin, you invite someone by email; the invite goes to their inbox, and when they accept and sign in they appear in your organization's member list. Each person's role — Admin or Member — is shown as a badge on their row, and you set or change it right there from the member list (you can switch anyone between Admin and Member at any time).

A few practical notes that save headaches later:

• Default new people to Member, then promote with intent. It's tempting to make everyone an Admin "so they're not blocked." Resist it — switching a Member to Admin later is one click on their row, and keeping the powerful account controls (and all the build/configure access) in a small, known group is the whole point. Remember that anyone who needs to build agents has to be an Admin, so promote deliberately.
• One organization, shared resources. Anyone you invite immediately shares the org's connectors, knowledge, and credit balance. There's no per-member sandbox — a Member's agent runs draw down the same credits as everyone else's. That's a feature (no silos) and a thing to be aware of (see watch-outs).
• Each person gets their own profile. Individual identity and personal preferences live on the per-user Profile, separate from the shared organization settings — so removing someone cleanly revokes their access without touching the org.

What only Admins can touch

Admin-only covers two very different kinds of thing, and it's important to see both. The first is everything that builds or changes the product; the second is the account-level controls you'd never want a brand-new teammate to touch.

Building and configuring agents

This is the surface the original framing of "members do the work" gets wrong. Per the Team docs, creating, editing, and deleting agents — plus connecting integrations, creating custom tools, and setting up triggers — is Admin-only. Members can use a deployed agent and view how it's wired, but they can't change it. So anyone on your team who actually designs, tunes, or ships agents needs the Admin role; there's no separate "builder" role that stops short of billing.

Billing, plans, and the credit balance

Your subscription, payment method, plan, credit top-ups, and usage alerts are Admin territory. Because Macha bills on a shared credit balance (credits are spent per AI action — roughly 0.5–9 credits depending on the model, with the default GPT-5.4 Mini at 1), the person who controls billing also effectively controls the team's runway. Keeping that with Admins means a Member can't accidentally change the plan or expose the card.

Organization settings

The organization's name, identity, and account-wide configuration are Admin-only. These are the settings that define the workspace itself rather than any single agent — exactly the kind of thing you want behind a role gate.

Privacy and data management

Data-handling preferences and account-level data controls live under privacy settings, and they're Admin-governed. Anything that affects how the whole organization's data is treated should sit with the people accountable for the account — not with every operator.

Team management itself

Finally, the power to invite, remove, and re-role teammates is Admin-only — the recursive part of any sane permission model: only the people with full control can grant or revoke control. Members can't manage the team at all.

What Members can do (and can't)

Be precise here, because it's the part that's easy to assume wrong. According to the Team docs, Member is a use-and-view role, not a builder role. A Member can:

• Use agents and chat — interact with deployed agents and run them on day-to-day work.
• View the setup read-only — see agents, connectors, and tools to understand how things are wired, without the ability to change them.

A Member cannot:

• Create, edit, or delete agents, connectors, custom tools, or triggers.
• Manage team members (invite, remove, or change roles).
• Manage billing or the subscription.

In other words, Member is the right role for people who only need to interact with your agents — frontline staff using a deployed agent, a stakeholder who wants to look at the configuration, a reviewer checking outputs. The moment someone needs to actually build or change something, they need Admin. That coarse split is the deliberate trade-off in Macha's model: it keeps role-based access control simple, at the cost of a middle "builder without account access" tier (see watch-outs).

Assigning roles the safe way

Two roles is a small surface, but a few well-worn access-control habits still pay off. These aren't Macha-specific rules — they're the same practices Microsoft, GitHub, and the broader RBAC literature recommend for any team tool, applied to Macha's model.

Default to Member; grant Admin only to people who build. Follow the principle of least privilege: start everyone as a Member, and promote to Admin only when someone genuinely needs to build, configure, or own the account. Because Admin is all-or-nothing in Macha — building access and billing access come together — granting it is a real decision, not a default. People who only use or review agents should stay Members.

Keep at least two Admins. A single-Admin organization is a liability — if that person is on leave or leaves the company, nobody can manage billing, settings, or the team until you sort out access. ShareGate makes the same point about Teams ownership: always have at least two owners so a workspace is never orphaned. Two to three Admins is the sweet spot for most support teams.

Review access on a schedule. Quarterly is a reasonable cadence: open Settings → Team, scan the list, and confirm everyone there still needs to be — paying special attention to who holds Admin. Access reviews that focus on exceptions and outliers catch the contractor nobody remembered to remove.

Offboard immediately, not eventually. When someone leaves the team, remove them from the organization the same day. Because Macha is org-scoped with a shared credit balance, a stale account isn't just a security gap — it's standing access to spend your credits.

Watch-outs: when two roles isn't enough

Honesty matters more than a tidy pitch, so here's where Macha's model has edges you should plan around.

• The roles are coarse — there's no "builder without billing" middle tier. Because building agents is Admin-only, anyone who needs to create or tune an agent must be a full Admin, which also hands them billing, organization settings, and the power to remove other people. If you want a teammate to build agents but not see the credit card, the two-role model can't express that today. Manage it by team convention, or use a separate organization for sensitive separation.
• There's no granular, per-agent permissioning. Every Admin can edit every agent in the organization — you can't lock a production agent so only certain Admins can change it. Members, by contrast, can't edit any agent. If per-agent ACLs are a hard requirement, raise it before you scale the team.
• The credit balance is shared and pooled. Any teammate's agent runs — including a Member simply using or chatting with a deployed agent — spend the same org credits. That's great for a single team working toward one goal, and a reason to be deliberate about who has access if you're cost-sensitive. Admins can monitor usage and manage the balance in billing.
• Admin is genuinely powerful. An Admin can change the plan, edit the payment method, and remove other people — including other Admins. Treat the Admin role as the trusted inner circle, not a convenience setting.
• Roles govern one organization — but you can have several. If you genuinely need to separate two business units, two brands, or production from a sandbox with different people in each, that's a job for multiple organizations, not roles. A single Macha login can belong to many organizations, and per the docs nothing is shared between them — each org has its own agents, connectors, tools, data, and billing — so you switch between fully isolated workspaces. The two roles always operate inside one organization.

None of these are dealbreakers for the teams Macha is built for — a focused support or CX org running AI agents on top of Zendesk, Freshdesk, Gorgias, or Front. They're just the boundaries of a deliberately simple model, and it's better to know them up front.

FAQ

How many roles does Macha have? Two: Admin and Member. Per the Team docs, Admins have full access — building and managing agents, connectors, tools, and triggers, plus billing, organization settings, and team management. Members are a use-and-view role: they can use agents and chat, and view the setup read-only, but cannot create, edit, or delete anything or manage team and billing.

How do I add someone to my Macha organization? As an Admin, go to Settings → Team, enter the person's email, and click Invite. They'll get an email invitation, and after they accept and sign in they'll appear in your member list. From there you set or change their role (Admin or Member) using the badge on their row. See the docs for the current step-by-step.

Can a Member build or edit agents? No. Building and configuring — creating, editing, or deleting agents, connectors, custom tools, and triggers — is Admin-only. Members can use and chat with deployed agents and view the setup read-only, but they can't change it. Anyone who needs to build agents must be an Admin.

Can a Member see billing or change the plan? No. Billing, the subscription, the payment method, and usage are Admin-only. Members can use agents and view the product, but can't touch account-level controls.

Can I have more than one Admin? Yes — and you should. Keeping two to three Admins means the account is never stranded if one person is unavailable or leaves.

Do team members each get their own credits? No. Macha uses a single shared credit balance for the whole organization, so any teammate's agent usage — including a Member chatting with a deployed agent — draws from the same pool. Admins manage and monitor that balance in billing.

Can I give someone build access without billing access? Not with the two roles today. Building agents requires Admin, and Admin also includes billing, organization settings, and team management — there's no "builder only" middle role. If you need that separation, manage it by convention or use a separate organization, and flag the requirement to us.

Can I restrict a teammate to just one agent? Not with roles today. Members can't edit any agent, and every Admin can edit every agent — there's no per-agent permissioning. If you need that kind of isolation, use a separate organization. It's worth flagging to us if granular per-agent permissions are a requirement for you.

Get your team set up

Team management in Macha is a five-minute task: invite your people to Settings → Team, keep most of them as Members, name two or three Admins, and put a quarterly access review on the calendar. That's the whole playbook — collaboration without the over-granted account that bites every growing team eventually.

If you're just getting started, spin up a 7-day free trial, no credit card required, connect your helpdesk, and invite the people who'll build your agents with you. For the full reference, see the Macha docs, or read more capability walkthroughs on the blog.

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