Your team already built their own AI agents. Ban them, argue with them, or invite them in?
A company gets excited about AI. They start talking to us, and in parallel they buy a few Claude seats for the keenest people. A month later the analyst has an agent for reports, the recruiter has one for screening applicants, the marketer has one for posts. When we bring the platform in, somebody in the room says: "We already have this. Honestly, ours works just as well."
We hear this more and more, and we think it is a good sign. Below: why arguing with homegrown agents is pointless, how earlier waves like this were handled, and what we offer companies instead of a ban.
This is not an objection, it is a stage
The phenomenon has a name: shadow AI. It is the direct continuation of shadow IT. Employees brought Dropbox, messengers and their own phones into companies long before IT approved them. No company beat that wave with a ban. The winners put a management layer over the homegrown tools and made the sanctioned path easier than the do-it-yourself one.
A person who built their own tool treats it like a child. Psychologists call it the IKEA effect: things assembled with your own hands are valued above what they are objectively worth. That is why "our system is twenty times bigger" earns respect but not a migration. Size says nothing about authorship. We tested this on ourselves and we no longer argue that way.
How earlier waves were handled
A few practices that became standard worldwide and transfer to agents almost word for word.
Personal devices and the management layer. When employees brought personal phones to work, companies did not confiscate them. A management layer appeared above the phones: who is connected, what they can see, what gets wiped when someone leaves. In this picture a homegrown agent is not a rival to the platform. It is a device that needs the same layer.
The paved road. Platform teams at Netflix and Spotify do not forbid engineers from doing things their own way. They build a paved road: the sanctioned route is faster, and if you drive off it you own the consequences. A homegrown agent stays allowed, but without a log, without permissions and without shared context, and that is the author's responsibility. The argument about quality turns into a conversation about accountability.
Citizen developers and the center of excellence. Microsoft went through the cycle with Power Platform: thousands of homegrown apps, then managed environments, data policies and a registry of who built what. The main lesson: builders are not scolded. They get a sandbox inside the platform and the status of author.
The model gateway. There is already a market for "one entrance" to every model and connector: logging, keys, spend, a filter for personal data. The market has accepted that companies need a connector of connectors. We add what a gateway lacks: the shared context of the company and the alignment of people with agents.
An open protocol for tools. The MCP protocol lets an agent from one vendor use tools from another. When a platform exposes its connectors through that protocol, "we wired the job board straight into Claude" becomes "we wired it into Claude through the platform": same agent, same experience, with a log and permissions attached.
What we went through ourselves
We are not theorists here. About a hundred and fifty people in our own company work in corporate Claude. We walked the same road: first the excitement, then dozens of personal agents, then three problems that cannot be solved inside a single chat.
- Access. Who may connect the CRM, who may connect accounting, who approved it.
- Connectors. Every employee connected their sources again, each in their own way.
- Shared context. The analyst's agent did not know what the salesperson's agent knew, and the director knew neither.
That is how we understood that personal agents need one more layer above them, where all of this is wired in. That layer is what we build.
Five questions instead of an argument
When someone shows us a homegrown agent, we no longer compare. We ask questions the homegrown tool usually cannot answer.
- Who else in the company can use this, besides the author?
- What happens to the agent when the author goes on holiday or leaves?
- Where do candidate, customer and supplier data go, and who can see that?
- Who can look at what the agent did yesterday and undo it?
- How does the agent learn what sales, accounting and the director know at the same time?
The third question stops the conversation most often. Applicant data from a job board sent straight to a foreign cloud with no log is a conversation about personal data and regulation, not about answer quality. It is better held before an audit than after.
What we offer instead of a ban
Keep your agent. Bring it into the platform. It gets channels, the company's memory, permissions and an action log, and you remain its author. That is the paved road: it is more comfortable than the detour.
For this the platform has, and keeps adding:
- a "bring your own agent" entrance, where the prompt and tools of a homegrown agent become a platform skill signed by its author;
- platform connectors available to an outside agent through the open protocol, with the same logs and permissions as inside;
- a "who went where" screen that the company's security officer and lawyer can read on their own;
- a sandbox for builders inside the company, so the next agent is assembled with us from day one.
We believe every company with more than one agent needs alignment between them. Banning homegrown agents is pointless and comparing yourself to them is useless. The way forward is to invite them in and make our road the most comfortable one.