AI agents for non-technical teams: a rollout

Why AI agents for non-technical teams is a provisioning problem

Rolling out AI agents for non-technical teams is a provisioning problem, not a model problem. The people who will get the most value from connected tools will never open a JSON file. Think of a sales manager checking pipeline, an HR coordinator pulling an employee record, a finance analyst reconciling payments. Ask them to edit a config, paste a client ID, or restart a process, and the rollout stops. It reaches the people who were going to figure it out anyway, and never the people it was meant for.

This generalizes beyond any one vendor. Any MCP-based agent gateway has to solve the same split. MCP itself does not define identity, consent, or permission scoping. It only defines how a client discovers and calls tools. Something has to sit in front of the protocol and own those three things. The framework below is one user-facing action, with everything else centralized. That is the shape the split takes when it is done right, and it is testable against any gateway.

So the rollout has one fixed shape: one thing a person does, and everything else an admin decides centrally. The one thing is adding an address to their chat client and signing in. Everything else is decided in the admin console: which tools exist, which role can reach them, which argument is locked. Those decisions can be made before or after the person signs in, and changed without touching their laptop.

Three definitions before the detail, because the rest of this post depends on keeping them separate:

• MCP: the Model Context Protocol, the open standard an AI client uses to discover and call tools. MCP defines the wire format, not who's allowed to call what.
• Endpoint: the single HTTPS address a client sends those calls to.
• Grant: the record of a person's consent, made once in a browser, that ties an AI client to that person in one organization. The grant is where authorization actually lives; MCP has no native concept of it.

What a salesperson actually does on day one

One address, one sign-in, one consent screen. Elaichi serves MCP at https://api.elaichi.ai/mcp, the same string for every organization and every person. There is no per-user, per-team, or per-toolbox URL to generate and distribute. There is no client ID, secret, or header for anyone to look up.

The person pastes that address into their client. The client registers itself through OAuth dynamic client registration (RFC 7591). That mechanism lets a client obtain its own OAuth client credentials at connect time, so no credential has to be created by hand. The browser then opens Elaichi's own consent screen. There the person picks their organization and approves what the client may do. Which organization, person, and tools the client reaches comes from that grant, not from the URL.

The address carries no token. The access token travels only in the Authorization header. So there is nothing sensitive in the string you would paste into an onboarding doc. That is a meaningful difference from gateway designs that encode a tenant or user ID directly into the URL path.

Setup steps for each client live in the Elaichi app under Connect your AI client. Longer walkthroughs are in the Claude setup post and the ChatGPT one.

Clients, as of this writing: Claude, ChatGPT, Cursor, Microsoft Copilot, or the Elaichi Agent inside the app. Elaichi keeps no list of approved MCP clients. Any client that supports OAuth dynamic client registration, PKCE with S256, and a browser sign-in can connect. Every client goes through the same registration, sign-in, and consent. What differs is only where the client's own settings take the address, so test your client before you promise it to a team. Microsoft Copilot reaches Elaichi through a Copilot Studio agent that adds the endpoint as a tool, with OAuth set to Dynamic discovery. The product team confirmed that on 2026-10-21. This list changes as clients ship native MCP support, so check the setup docs linked above rather than treating this paragraph as current indefinitely.

How to curate toolboxes per department

A toolbox is a named list of tool entries, each one a connector tool pinned to a connection. Curating per department means deciding two things. First, which toolboxes a team's people can run. Second, which connectors and tools their role may reach at all. These are two different mechanisms, and mixing them up is the single most common rollout mistake:

A toolbox shared with a team at the use level runs each entry on the connection pinned into it. The authority is whoever pinned that connection. Everyone on the team acts through that one identity on the third-party side.

A template is the other pattern. Share it at the use level and each person stamps their own copy, picking their own connection for each app. Calls then run on their own account in the third-party app, under that app's own permissions for them individually. A single shared toolbox cannot do this, because its entries are locked to the connections pinned in them. The same per-person pattern is what connecting AI to a CRM depends on, since a rep's assistant should see exactly the records that rep can see.

Decision rule:

Sharing one setup across a team covers both patterns in full detail.

At consent, a person chooses between "Everything I can use" and "Only the ones I pick." The first covers their own toolboxes and system toolboxes for every connected app, including ones added later. The second option names between one and 50 stored toolboxes, and it is re-checked on every call. It is the narrowest grant shape available at the client. Default to it for a first department rollout.

One catalog, two kinds of connector

Elaichi's connector catalog holds two kinds of connector. The difference matters for what you can promise a team:

Both kinds arrive through the same endpoint and the same tool-calling surface. The same restriction rules, the same OAuth scopes, and the same audit log apply to both. A native MCP connector does not get a separate security model just because the vendor wrote the server. An organization on the Gold plan can also register its own remote MCP server as a connector, under the same rules.

Practically, you never have to tell a sales team that HubSpot works one way and Linear another. They ask, the tools get found, and the rules you wrote hold either way. Browse the 650+ connectors in the catalog.

Read-only first, then write tools one at a time

Start every team read-only. Not because the model is reckless. A bad read costs you a wrong answer; a bad write costs you a wrong state change. The failure costs are asymmetric, and permissions should reflect that asymmetry before anything else.

The mechanism is a restriction rule. A restriction targets a role or one member, never a team and never the whole organization. It names whole connectors or individual tools. Two shapes, with opposite default behavior:

The trap runs in both directions. An incomplete allow rule blocks more than you intended; an incomplete block rule blocks less. A read-only allow rule on Stripe also needs allow rules for every other app that role uses, or those apps go dark too. Allowlist versus blocklist sets out which approach fits which team size and risk tolerance.

The console helps here. Each tool on a connector's page is labeled Read only or Makes changes. The block-rule tool picker offers three presets: Block deleting, Block all changes and Block everything. Do not lean on the label alone. Gmail's "Send a draft" tool (gmail_drafts_send) sends an existing draft and is still labeled Read only. Labels describe the tool's effect category, not a guarantee of harmlessness.

Timing matters for incident response. A restriction or role change takes effect about two minutes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Revoking a share and disconnecting an account are effective on the next call as well. No cached grant outlives any of these actions.

Where the approval actually happens

Most rollout plans get this sentence wrong: Elaichi has no per-call approval step over MCP. The person's OAuth grant is the approval. They chose once, on Elaichi's own consent screen, what that named client may do. Every call that passes the grant's scope check runs as already approved. There is no second gate waiting at call time on Elaichi's side.

If a person sees a confirmation prompt in Claude or ChatGPT, that prompt belongs to the client, not to Elaichi:

• Claude has its own approval step for connector tool calls, with Always allow, Needs approval, and Blocked settings (Anthropic's connectors documentation, checked October 2026).
• ChatGPT may show an approval card before a supported action runs, depending on the app permission setting and the action's context (OpenAI's app permissions documentation, checked October 2026).

Tell your teams in advance which behavior they will see per client. This is the single most common week-one support question, and it has nothing to do with Elaichi's own access rules.

The approval card people usually have in mind belongs to the Elaichi Agent. That card carries Deny, Always allow and Allow once, prompts per call on deletes, and lets a person edit arguments before approving. The Agent is a Black-plan feature, covered in the Elaichi Agent post. Approvals inside workflows are a separate Black feature, covered in the workflows post.

So a non-technical team that needs a human in the loop at call time has exactly three options, in order of strength:

1. Don't give that role the tool at all. This is enforced on Elaichi's side whatever the client does, and it is the only option that survives a client switch.
2. Use the Elaichi Agent's per-call approval card. It works, but only inside that client.
3. Rely on the third-party client's own prompt. Behavior varies by client and can change without your input, per the Claude and ChatGPT links above.

One more control is set in advance, not at call time. Frozen parameters lock an argument on the calls that run through a specific toolbox entry. A tool can be pinned to one folder, one channel, or one account. The AI can see short frozen values in the tool description and cannot change them. They apply only to calls through that specific entry. A member who can reach the underlying connection directly still has the unfrozen version of the tool.

The questions week one brings

Four questions, in roughly this order, with the actual mechanism behind each answer:

"I can't find the tool." Connected tools are never listed individually in the client's tool list, however few there are. The client finds them with search_tools and runs them with read_tool or execute_tool. Search is lexical, not semantic. Tell people to type tool-ish phrases, such as "create deal", rather than full sentences. If a tool is restricted for them, search still surfaces it, flagged, with a note on how to request access. MCP tools not showing up covers the rest of the diagnostic ladder.

"It said I'm not allowed." A refused call returns in-band as a structured reason, not a generic error screen, so the model can relay why instead of guessing. The message states whether the block comes from the person's role or their own account-level setting. It also says an admin can lift it through an access request. The person files the request from the client. Only an admin, under Governance, Access requests, can approve it. Approving creates a one-person access grant for that connector or tool. It does not change the person's role and does not touch anyone else's access.

"It says I need to reconnect." A grant's scopes never change after initial consent. If the person unticked a scope at the consent screen, reconnecting is the only fix. It works only if the client re-requests that scope on reconnect. Fixing OAuth errors covers the remaining sign-in failure modes.

"Who can see what I did?" In Elaichi, one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Anyone can read their own activity. The org-wide view requires the audit permission, held by Org Owner, Org Admin, and Auditor. Auditor is a free seat, which means a compliance reviewer costs nothing beyond the time to set it up.

A rollout can reach week four with the tools connected and nobody using them. The cause is usually one of three, and none of them is the model. Pilots stall when the AI cannot reach the apps people work in, when nobody trusts the answers, or when nobody owns the rollout after launch.

When this is not the right tool

Some operations teams want a fixed, deterministic sequence that runs the same way every time. They do not want a model deciding which tool to call next. An automation builder such as n8n or Zapier fits that job better than a chat client with tools. The distinction is agency. An MCP-connected chat client lets the model choose which tool to call and in what order, based on the conversation. An automation builder runs a predetermined graph regardless of what is said. The comparison with n8n sets out which job each is for in more detail.

Zapier also ships its own MCP surface, built around a different unit. In Zapier MCP the per-person unit is the server, not the address: each user creates and owns their own servers on the Zapier account, one server can serve several of that user's MCP clients, and the endpoint URL is shared (Zapier's MCP security documentation, checked November 2026). Elaichi's unit is the grant behind one shared address instead.

And if one person wants their own apps in their own chat client, you may not need a control plane yet. With no one else involved and no role-based access to manage, the overhead of grants, toolboxes, and restrictions does not pay off. It starts paying once there is more than one person to govern. That case has its own post. The case for central provisioning starts the moment several teams, several apps, and a leaver policy are in the same sentence. At that point, per-person configuration stops scaling linearly and starts scaling combinatorially. Budgeting that moment is its own exercise: what AI access costs per employee works the arithmetic for 50 and 200 people.

For the week-one admin work in order, see the setup checklist. For scenarios by department, see the use cases page.