AI for support teams, scoped to what they handle

AI for support teams is the strongest case in the company for an assistant, and the weakest case for broad access.

The strong case is the shape of the work. A single customer question routinely needs four systems: the ticket, the customer's record, what they bought, and whether the thing they are complaining about is actually broken. An agent spends a real fraction of their day moving between tabs assembling context before they can write two sentences. That is exactly what an assistant is good at.

The weak case is the same shape from the other side. Support is often the largest team with the highest turnover, working in systems that hold customer records and, in some organizations, payment history. Giving twenty people broad programmatic access to all of that is the thing your security lead will correctly stop.

These are not in tension if access is a property of the person rather than of the connection. Here is the arrangement, in the order you would build it.

Step one: connect the systems AI for support teams needs

Four systems cover most of it. Exact names will differ; the shape does not.

• The helpdesk. Zendesk, Intercom, Freshdesk, Front or Help Scout.
• The CRM, for who the customer is and what they are worth. Salesforce or HubSpot.
• The billing or order system, for what they bought and what they paid. Stripe is the common one.
• Engineering's tracker, for whether a reported bug is known. Jira or Linear.

Each one is connected once, by whoever administers it, and shared with the support team. Not by each agent under their own account.

That last point does more than save twenty setup sessions. It means the credential belongs to somebody who is still here, the connection appears in one list rather than twenty private ones, and adding a new agent is adding them to a team rather than walking them through four authorizations.

Step two: decide what support is not allowed to do

This is the step with actual thinking in it, and it is best done before anyone is using the thing.

Two kinds of rule.

Block entire systems that are not part of this job. Payroll. The HR system. The production infrastructure. One rule per connector, and it keeps applying when those systems gain new tools later, which is the advantage of blocking at the system level.

Block individual operations inside systems support does need. This is where the real policy lives:

• On the helpdesk: block delete and merge. Reading, replying, tagging and status changes stay.
• On the CRM: block delete, and block bulk update. Reading a contact is the point; rewriting a hundred of them is not.
• On billing: block refund and cancel. Reading a charge answers almost every support question. Issuing money is a different job with a different approval.
• On the tracker: block delete and block transitions on anything outside the support project.

A useful way to decide: if a wrong call would need a human to unpick it, block it. Reading is recoverable. Replying to the wrong ticket is embarrassing and recoverable. Deleting is not.

The mechanical reason this is stronger than a warning in a prompt: a restricted tool is never advertised. The model does not see it in the list and does not know it exists. There is no instruction to ignore, because there was no instruction.

Step three: freeze what should not vary

Larger support organizations usually have more than one of something. Two helpdesk workspaces after an acquisition. A sandbox alongside production. A public knowledge base and an internal one.

Blocking is the wrong instrument here, because the team needs the tool. What they do not need is the ability to point it somewhere else.

Freeze the argument. The workspace identifier on the shared search tool is pinned to the support workspace. Two things happen: the parameter is removed from the schema the model sees, so it cannot be set or hallucinated, and the value is forced at execution, so passing it anyway changes nothing.

This is also the cheapest way to make a dangerous tool safe rather than absent. A file search frozen to the support folder is a working tool that cannot read the folder next to it.

Step four: check it from the agent's side

Have somebody on the support team open their client and look at their tool list.

That list is the ground truth. A restricted tool is not advertised, so what they see is exactly what they can reach. Thirty seconds of looking will tell you whether your rules say what you meant, and this is reliably the step that catches the mistake.

The mistake to look for specifically: an allow rule that names nothing denies everything. If you created an allow rule and saved it before filling it in, the support team's tool list will be empty, and it will be empty for a reason that reads as a bug.

Four shapes that come up daily

Four shapes that come up constantly, all of which are ordinary once the setup is done.

Catch up before replying. "What do we know about this customer?" pulls their past conversations, recent orders and current plan from three systems into a paragraph, before the agent types a word. This is the one that saves the most time and needs the least access, since it is all reads.

Check the claim before answering it. A customer says the site was down at ten. Rather than asking engineering, the agent asks what the monitor shows for that page and how response times looked over that hour, and replies with facts. Support answering its own infrastructure questions is worth more than it sounds, mostly in interruptions not sent.

Draft from the actual thread. Pull the customer's message and attachments, draft a reply to what they actually asked, and move the thread when it is handled. The draft is a starting point, and it is a better starting point than a blank box because it has read the history.

Find the record behind a wrong answer. A customer reports something odd, the agent looks up the exact record by id, sees what it contains, and fixes or escalates. Narrow, high-value, and the reason read access to the data store is worth granting even when write access is not.

More of these, by team and by connector, are on what teams do with Elaichi.

Three things that will come up in week one

"A tool disappeared." Almost always a cached tool list. Most clients hold what they were told at connection time; a new conversation or a reconnect refreshes it. If it is genuinely gone, check whether a restriction now covers it, and note that a change to a role or a restriction takes about two minutes to take effect rather than being visible at once.

"Can I get access to just this one thing?" Yes, and resist doing it by widening the team's rules. A person-level rule replaces the role's rules for that person entirely rather than layering on top, which means it has to restate what still applies. That is more work and it is the right kind of work: the exception is readable on its own, and it does not quietly widen the team.

"Who deleted that?" Every tool call is recorded, succeeded or failed, naming the operation, the account actually reached, and whether the actor was a person or an assistant. When the question is whether the agent did it or the customer did, the trail answers it rather than starting a conversation about it. That record shape is described in what an AI audit log has to capture.

Scaling past one team

Support is usually the first team connected, and the arrangement that works for one team does not automatically survive the second and third.

Systems get shared, restrictions do not. The CRM that support reads is the same CRM that sales writes to. The connection is one connection, shared with both; what differs is the rule set per role. If you find yourself connecting the same system twice so that two teams can have different access, something is wrong with how the rules are being written, not with the connection.

Tiers inside a team are roles, not exceptions. Support agents, support leads and the two people who can issue refunds are three different jobs. The instinct is to give everyone the agent rules and write person-level exceptions for the rest. That produces a growing exception list nobody reviews. Three roles is cleaner, and because a person holds exactly one, the answer to what a support lead can do is one document.

A second workspace is a frozen argument, not a second connection. Teams acquire second helpdesk instances, sandbox environments and regional accounts. Connecting each separately multiplies the credentials to maintain. One connection with the workspace frozen per shared toolbox gives the same boundary with one credential behind it.

New tools arrive on their own. Connector catalogs gain tools as vendors ship APIs. A rule that blocks specific tool names does not cover a tool that did not exist when the rule was written. Where the intent is that a team has no business in a system at all, block the system, because that keeps applying.

The order that matters

Connect the systems once. Decide what support cannot do, before anyone is using it. Freeze what should not vary. Then check the tool list from an agent's seat.

Teams that do those four in that order tend not to have an incident. Teams that connect first and govern later spend the following month narrowing from a default that people have already built habits around, which is a harder conversation than the one you get by narrowing first.

The reasoning behind the rules is in the governance mechanics. The finance version of this post, which has a different risk profile, is your finance team in Claude.