Agent Connect
The agent was the fast part. Making it secure and usable for others was the real work, and a shared layer meant doing that once instead of for every agent.
What I built
When I started experimenting seriously with AI agents, most of my experiments combined two kinds of work: predictable steps like fetching data, calling systems and formatting output, and an AI agent handling the parts that needed judgment. The fastest way to build these was in n8n, a workflow automation tool, where both kinds of steps can live in the same flow.
Most of these experiments started and ended with a conversation. But n8n only offers a simple test chat, not something you could put in front of a real user. At the same time, a few potential customers showed interest in agents I'd built. So I built Agent Connect: one chat portal where people can pick an available agent, have a conversation with it, and return to earlier threads.
Because the point was that other organizations could use it without building their own interface, I built it for that from the start. It's multi-tenant, users sign in with their Microsoft 365 account, and an admin layer controls which organization and which user has access to which agents. The portal itself only sends and receives messages, while each agent is a separate workflow behind it. Every agent experiment I built after that plugged straight into it.
What it revealed
The agent was the fast part. Getting an agent to do something useful took hours. Making it something another organization could safely use (sign-in, separation between customers, control over who sees which agent) was where most of the work went.
Separating the agent from the interface paid off immediately. Once the portal existed, each new agent only needed to handle the conversation, not everything around it. The cost of the next experiment dropped, and the enterprise concerns were solved once rather than every time.
What it means for a product organization
As building AI agents gets easier, the cost of an AI initiative moves from building agents to making them usable: identity, access, data boundaries and a decent user experience. That's the part that's easy to underestimate when planning AI work, and it's often what separates a promising pilot from something people actually use.
It also raises a platform question. If every team that builds an agent also builds its own way to secure it and put it in front of users, the same problem gets solved many times, usually unevenly. A shared layer makes every agent after the first cheaper and safer. Someone has to decide to build it and own it, and that decision is easier to make early than to retrofit.
Finally, separating the agent from everything around it is a design choice that keeps options open. The agent can change, the model behind it can change, and users don't have to notice.
What I'd test next
Putting a layer like this in front of real users in a real organization, and seeing how far it holds up against actual enterprise requirements such as audit logging, data residency and security reviews. And watching whether teams actually adopt a shared layer, or keep building their own.
See the other things I've built to test how AI changes product organizations.
Back to Fieldwork