What Can This Agent Access for Each of Your 200 Clients?
Thread AI Editorial · September 10, 2026
The agent had been running in production for the better part of a year, reconciling disputed transactions for the company's own operations team. It read a merchant's transaction history, checked it against the card network's response codes, and recommended whether to accept or escalate a dispute. One team built the agent, and offered it up to two other teams to use, and the access boundaries between them were the same kind of boundaries one might expect to be drawn between employees on different teams at the same company.
After internal successes, product leaders asked: Could they turn the agent into a paid feature for clients? The case rested on timing because the company would be selling a product in a space adjacent to the one they played in, and the window to be early wouldn't stay open long.
The architecture review that followed surfaced important and hard-to-solve blockers to release. No client should ever see another client's transaction history, but the system couldn't tell Client A from Client B unless something told it whose data it was allowed to touch. One reviewer asked who audited access boundaries. Another reviewer asked how usage would get billed if 200 client accounts started calling the same agent at different volumes.
Nobody in the room had immediate answers, but by the second hour the whiteboard held a thorough and comprehensive list:
whiteboard · hour two
per client, all four
- Auth per client, so a request can be tied to who sent it.
- Access scoped per client, so one client’s data can’t surface in another’s session.
- Usage metered per client, because someone has to bill it.
- A way to change one client’s limits, without redeploying for the other 199.
Tool to Platform
One owner and one agent had made a useful tool; 200 clients in front of the same agent made a platform.
One owner, one agent
Three teams at one company, with the boundaries one would expect between colleagues.
200 clients, the same agent
… 200
Two hundred accounts that were never inside the walls, each owed an answer of its own.
The most important question that came from the whiteboard review was: What can this agent access and do for each of those 200 clients?
It's tempting to consider exposing an internal agent to customers as an incremental step past running it internally, especially when there is market signal driving an urgency. However, every access question the internal version answered once now needs an answer per client, and every one of those per-client answers needs to be provable to an auditor or a client's own security team. "The model was told not to" doesn't hold up as an excuse for failure.
Per-tenant isolation decides whether one client's data can ever appear in another client's session, whether a client's usage can spike and degrade someone else's response time, and whether a client can be onboarded or offboarded without a deploy touching everyone else on the platform.
The Layer Underneath
The agent logic worked well for its original purpose and provided clear value internally. What the original chosen framework never needed was the infrastructure layer underneath. That layer should exist on any serious stack, and somebody still has to assemble and wire it together.
What the agent logic covers
Read the merchant’s transaction history, check it against the card network’s response codes, and recommend whether to accept or escalate the dispute.
What sits underneath — left to the builder
That assembly work is a systems integration project measured in quarters, and multiple quarter timelines are one of the main things that dampen market entry. A team can scope the agent logic with real confidence because the logic is visible and known. The tenancy layer reveals the true size of the work one client at a time, yet the window for the market opportunity doesn't hold while it does. The clients weighing this product are weighing others, and the company that puts a working, provable product in front of them first sets the terms. A launch date that slips because the client count went from one to 200 can slide past the opportunity entirely.
Q1
Q2
Q3
Q4
Market window
Agent logic
Tenancy layer
From Day One
When these layers are built into the agent design from the start, even if the goal is to build purely for internal products, the agent tool becomes a scalable and sharable product across an organization.
And if it's already there and already provable, if you do decide to launch externally, the big question from that architecture review gets answered before anyone has to ask it out loud. That is what moving up the stack actually requires: the confidence to put a net-new product in front of clients who were never inside the walls before, without spending the runway rebuilding what a platform should have handled from Day One.
The Series
This is Post 3 of six, and the first of two about moving up the stack. Read the thinking behind this series in the manifesto.
Your Customers' Regulators Will Ask What the Agent Did – and Why
For companies whose customers already depend on their product, adding AI means answering to those customers’ regulators too. This post follows a claims software company that ships an agent to review insurance claims, then can’t explain one of its denials to a state examiner because the reasoning was never recorded when the decision was made.
The Demo Was the Easy Part
Businesses that run their operations on a product hold every new feature to the same service commitments. This post follows an insurance software company whose overnight deploy leaves quote requests stalled mid-decision while every health check stays green, because nothing recorded where each request stopped or how to resume it.
What Can This Agent Access for Each of Your 200 Clients?
Turning an internal tool into a product for a new market pays off if it ships while the opportunity is still open. This post follows a company that plans to sell its internal dispute-reconciliation agent, then learns that keeping each client’s data, billing, and limits separate could take quarters to build, long enough to miss the opening.
A 97% Success Rate Is a Liability
Teams moving fast into unfamiliar territory often launch first and plan to iterate later. This post follows a company building its first logistics product, whose exception-handling agent slips from 99% to 97% success as volume grows, leaving 1,500 failed runs a day with nothing built to handle them.
Assembled by Your Team, Owned by Your Team, Forever
Codifying expertise lets a firm reach clients its experts will never have time to serve. This post follows a pay-consulting firm that turns its partners’ methodology into an agent product for 40 clients, then finds that keeping each client’s limits in place has it staffing like an infrastructure company.
The Day the Ship Date Stopped Moving
Turning a playbook into a product means answering to every client’s reviewers. This post follows a life sciences consultancy that builds a supplier-review agent in weeks, then watches its launch date move three times as the client’s quality, security, and audit teams each ask what the agent did, and why.