What 100+ Platform Teams Taught Us About AI Discovery

If your organisation has a handful of services, an AI agent can figure out what is available by reading a couple of READMEs. If it has hundreds of platform teams, each owning some slice of infrastructure, data movement, compliance, and security, that same agent is lost. Not because the capabilities do not exist. Because there is no reliable way to find them, understand them, and trust which one is the right one to use. 

We have spent the last six months fixing this in three stages, and we are still in the middle of the third. The central lesson is not about models. It is about the layer between the agent and the organisation: the catalog of capabilities the agent is allowed to use. 

This is a progress report, not a victory lap. But the failure modes we have hit are structural, and they will find any large organisation that gives agents access to a big internal platform. 

The business pressure 

Discovery decays through neglect. The original problem was tribal knowledge. A developer who needed to push data to a streaming topic, check a pipeline’s status, or onboard a data asset for compliance deletion had to ask around: wikis, chat channels, whoever remembered which team owned what. 

A page written when a platform team owned three services does not get updated when they own thirty. Every AI agent pays this tax by guessing. 

Adoption creates a second-order problem. We mandated that every platform capability team publish a structured skill, often backed by an MCP server, into a central catalog. It worked. Teams engaged seriously, kept improving their skills, and usage grew. 

Then the overlap started. Teams doing exactly what was asked of them occasionally built capabilities that duplicated something another team already exposed, under a different name and shape. Success produced the very ambiguity the catalog was meant to eliminate. 

Trust is the real currency. When an agent cannot tell which of two plausible capabilities is canonical, it guesses. Sometimes it guesses wrong, and the wrong skill reads from a stale or secondary source. 

Each wrong guess teaches the organisation’s engineers not to trust the agent. Trust, once lost, is far more expensive to rebuild than any catalog. 

The practical playbook 

Mandate structured, centralised skill publishing. Every platform capability team publishes a skill into one central repository: a clear description, invocation details, and ownership metadata, structured well enough that both a developer and an agent can answer ‘what exists, and how do I use it.’ 

Require delegation to be declared, not buried. This is the counterintuitive lesson. When a skill wraps another team’s capability, that dependency must be visible as metadata, for example a delegates_to field naming the underlying capability, plus a note explaining the reshaping. The standard to enforce is not ‘don’t wrap.’ Wrapping is fine and often useful. The standard is ‘don’t reimplement.’ Going around the owning team to derive the same fact through a different path creates two sources of truth for one underlying thing, with no guarantee they stay in sync. 

Review for ownership, not similarity. Semantic similarity checks would not have caught our overlap: the two skills did not sound alike. They only revealed themselves as the same fact once you traced both down to what was actually queried. A sharper review question is checkable: does this skill produce its answer by calling the team that owns the resource, or by independently deriving that fact itself? 

Treat the catalog as a graph, not a list. Once delegation is declared consistently, the catalog stops being flat. You can ask what has been built on top of a given capability and see every team that layered a wrapper over it. That makes this failure mode visible before it reaches production. 

Plan for the arbitration moment. Governance will never cover every existing capability. Agents will keep facing two plausible skills for one request. Whether the answer is an arbitration step that notices similarly scoring matches and asks for disambiguation, or something closer to ranking, this is a distinct problem from governance and it is still unsolved. Name it on your roadmap rather than hoping the catalog converges on its own. 

Evidence in practice 

Here is the shape the problem took for us directly. I own a capability that moves data from our data lake into a streaming platform, which under the hood triggers a batch pipeline on a Spark cluster. Naturally, users of my capability want to know whether their job succeeded, and if not, why. 

So I built a status check into my skill. Reasonable on its own. 

Except a separate platform team owns the batch scheduler itself, and they already expose an execution-status capability that answers exactly this, given a pipeline ID. Different name, slightly different output shape, same underlying fact. 

Neither team did anything wrong in isolation. From my side, ‘did my pipeline succeed’ is a natural thing to expose in my domain’s language. From the scheduler team’s side, they own the source of truth for execution status. But now two skills can answer the same question, and an agent choosing between them has no reliable signal for which one is canonical. 

The honest version of what I built is a thin wrapper that calls their execution-status API and reshapes the answer for my consumers. Declaring that explicitly, as metadata on the skill, is what lets a reviewer, the catalog, or the agent itself tell the difference between an honest wrapper over a shared source of truth and an independent reimplementation that can quietly drift. 

Action plan 

First 15 days: stand up the central skill repository and require every platform team to publish at least their highest-traffic capability with a structured description. You will learn more from the first fifty skills than from any design document. 

Days 15 to 45: add the delegation declaration to the submission template and start reviewing new skills for the ‘don’t reimplement’ standard. Backfill declarations for the most-used existing skills, starting where overlap is already suspected. 

Days 45 to 90: build the graph view of the catalog and run your first overlap audit: which capabilities have two or more claimants, and which ones are wrappers versus reimplementations. Put the arbitration problem on the roadmap with an owner, even if the solution is not yet clear. 

Closing 

Stage one taught us that discovery decays through neglect, and centralising it into agent-readable skills fixes that cleanly. Stage two taught us something less obvious: discovery can also degrade through success, with every team doing exactly what was asked and still producing an agent that cannot confidently tell which of several plausible answers is real. Stage three, the one we are living in, is about teaching the system to be honest about which facts a capability actually owns versus which ones it is relaying on someone else’s behalf. 

The organisations that learn this early will have agents their engineers trust. The rest will have very fast guessers. 

Rajesh Gomathinayagam

A data engineering and analytics professional with 20+ years of experience in IT, I currently focus on platform infrastructure and the emerging challenges of making AI agents work reliably across large organizations.