Everyone at Polygon builds their own agents now. And the best thing we did to help them was get out of the way

Parvez is an Engineering Manager at Polygon with multiple teams reporting to him. Every day, he gathered incident-related discussions from six or more Slack channels, stitched them into a report, and prioritised the ones that actually meant a real incident.

He asked our team to automate the manual steps he was doing for that. We did, creating an agent for him ad hoc at first. Then we found a smarter way to connect all sources at once and enable everyone to create their own agents themselves. That’s how we became platform maintainers. Today, our small team runs the Agent Platform at Polygon and doesn’t build a single agent for anyone anymore.

Our helping became our full time job

We spent about 3 days developing Parvez’s agent: we gathered the data sources, prototyped in a small dev environment, and verified it worked through a few days of back and forth with him. Once it went live, the agent was doing the work autonomously for him and his department, but the maintenance landed in our team: reviewing its new PRs, instructing the rest of the platform team on it, stewarding it. From then on, it was a few hours per week, forever, sitting with us. Then Gordon and Marc came to us as well with new agent ideas.

Parvez wanted to gather all incident signals in Slack and fill in a report automatically, Marc wanted an Agentic Executive Assistant pulling live from Mail, Slack, and Calendar to organise his day to day, while Gordon wanted to scan our PRs and repos for leaked secrets. They were all pretty identical cases in ideation and launch, but they all needed to be tackled and maintained by us on their own.

Two different agents, same wiring in sources

We took Parvez’s agent as the example and started brainstorming how to standardise our live agents deployed internally. We found ourselves repeating the same or pretty similar steps we used for the first agent. We slowly scratched the surface of a new problem.

It was actually so hilarious that it clicked: every agent needed Jira wired up, same for Google Docs, etc. Two different agents, same wiring in sources: each one had to be connected to the sources it needed, and each source had an MCP (a protocol allowing agents to connect to it) that we had to manually connect to the agent. Although some of the agents had the same connections in common, we needed to repeat that step for every agent.

Funny how I even created a skill (instructions for my coding agent to execute a certain action if it recognised the pattern) to help me repeat the manual step of connecting the source to the agent, thinking that that was the bottleneck. The bottleneck was not wiring in the sources for each agent. It was our time consistently spent wiring up agents and deploying them one by one.

Another problem was that most of the users requesting agents were people outside of engineering. Are non-engineers and non-developers expected to know how to code an agent? No, and they don’t need to.

We needed to give our colleagues more tools to move with their own feet. They needed to be more independent on that, for us to scale and serve everyone.

The Platform team needs an Agent Platform

An agent conducts actions automatically for you, on its own. To work well, it needs verified and updated info. Like most companies, all of this internal data is scattered across different sources, e.g. Slack, Calendar, Jira. A context layer is the place that condenses all the relevant information about Polygon. It answers: if I need to work at Polygon, what do I essentially need to know? What is the latest decision on topic X? Where do I find it? Who is responsible for it? It holds your latest decisions, the historic strategic ones, incidents, brand context.

An agent plus a context layer is a match made in heaven: an agent can perform autonomously, based on the updated info from the context layer. The third ideal requirement is agent hosting. That’s what the platform does to allow you to launch, test, and maintain your agents all in one place, without needing to host them externally.

We realised we needed a platform to manage all this: a place where we and our colleagues would feel comfortable and safe creating agents, experimenting with them, feeling empowered. A place to access relevant info securely, based on your access level (e.g. I’m an engineer, I shouldn’t be able to access exec Google Drive docs, and nor is my agent). One single place of truth, instead of repeating manual steps ad hoc for each user.

It was as simple as this: the Platform team needs an Agent Platform.

We had to get out of the way

We found the ideal provider in Glean. Glean is both a context layer that respects each user’s permissions and has its own agent platform built in. It manages source connections through MCPs or custom connections, e.g. to Slack, Drive, Jira, and has a clear UI where users can start prompting their agents’ use cases, test them in real time, and launch them when ready. It also provides visibility into the tools each agent needs to run successfully, and lets you select different model providers for the tasks. Users are now sitting at the steering wheel: they are actually empowered, they feel what they can and cannot do, they troubleshoot, prototype their agents, and launch when they feel ready. The people closest to the domain are sitting closest to the knowledge.

We changed our role: from actively developing agents, deploying them internally, and building an ad hoc cloud platform to manage them one by one, to maintaining the platform for them. We get involved whenever a data source needs connection or some of the tools are not working as expected, and we still provide first-class help. We set aside developing a custom platform that could not scale as fast as we wanted. The difference is we can now serve hundreds of users at once, not each one individually. And that is proven by 12 agents running across the org, 11 in the works, and 605 runs in the last month.

Now we are still a small team on the platform, but an entire company capable of building agents.