Read the latest Day Two post: What Can This Agent Access for Each of Your 200 Clients?Day Two Series: Post 3 is live. Learn more
Day Two
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. Client A's agent couldn't see Client B's transaction history, and the system didn't know there was a Client A or a 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 agents 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.
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 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
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.
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.
The first of two anonymized composites about protecting an installed base. A product customers already depend on, and the work of making it more adaptable without destabilizing the contracts, SLAs, and processes built around it.
The second moat composite. Same archetype, different pressure: an overnight deploy leaves forty minutes of requests frozen mid-decision behind green health checks, and the layer beneath the agent loop turns out to be the real build.
The first composite about catching a window. An internal dispute-reconciliation agent gets pitched as a paid feature for 200 clients, and the architecture review asks who tells it whose data it may touch. The tenancy layer decides whether the window stays open.
The second stack composite. Another route into a new market, and the operational questions that show up once speed gets the prototype built and production has to keep it running.
The first composite about codifying expertise. Methodology that lives in a few senior leaders, reaching clients that those people will never have time to serve, so people and product sell together.
The second playbook composite, closing the series. A different organization, the same tension: doubling down on human capital while turning part of the playbook into product.
