AI Agents for Platform Teams: Service Catalogs and Golden Paths

Every platform team hits the same wall eventually. The service catalog says 38 services. Anyone who has been on the team more than six months knows it is closer to 47, plus a handful of zombie repos nobody has decommissioned. Ask which team owns the billing-events service and you get three different answers in the same Slack thread, and one of them is wrong. Ask how long it took the last new hire to ship their first change to production and nobody can tell you, because nobody is tracking time-to-first-deploy, they are tracking a gut feeling that onboarding "feels slow." The golden path for spinning up a new service exists, technically. It lives in one senior engineer's head, and if that engineer is out sick or in back-to-back meetings, the answer for anyone else is "ask in #platform-questions and wait." None of this is mysterious. It is what happens when a platform team ships internal tooling and never budgets time to document it, govern it, or measure whether it actually works. AI agents for platform teams need to close exactly this gap: turn tribal knowledge into a catalog people trust, turn one person's mental model into a golden path anyone can follow without a Slack ping, and turn a vague sense that onboarding is slow into a number you can track quarter over quarter.

Why ChatGPT and Cursor cannot fix a service catalog nobody trusts

Ask ChatGPT or Claude.ai how to build a service catalog and you get a reasonable, generic answer: adopt a schema, maybe evaluate Backstage, write some docs, assign owners. It is not wrong. It is also useless for the actual problem, because the generalist has no access to your 47 repos, cannot tell you which nine of them have no owner field filled in, and cannot tell you that the deploy pipeline links in the catalog point to a Jenkins instance you decommissioned eleven months ago. A generalist chatbot answers the question you typed. It does not go read your GitHub org, cross-reference it against your on-call rotation, and flag the drift. That drift, not the absence of a schema, is the actual reason engineers stop trusting the catalog within two quarters of building it.

Cursor and GitHub Copilot solve an adjacent but different problem. They are excellent at completing the YAML for a single catalog entry once you have opened that file and started typing. What they cannot do is decide the schema in the first place, audit which of your 47 services are missing entries, or notice that three teams have each invented their own incompatible format for the same field. Autocomplete operates at the file level. A service catalog is a cross-repo governance problem: who owns updating an entry when a service changes hands, what happens when a PR ships a new service without one, how stale is too stale before the catalog gets ignored entirely. An editor plugin has no view across your organization's repos and no mechanism to enforce a governance model even if you handed it one. It will write a beautiful individual entry and leave the systemic rot exactly where it was.

The golden path problem is the same shape wearing a different hat. A golden path is not a wiki page, it is the opinionated, supported, tooling-backed way to do a common task like standing up a new service. If that path only exists as institutional knowledge in one engineer's head, it is not a golden path, it is a bus factor of one. Neither a generalist chatbot nor an autocomplete tool can extract that knowledge, formalize it into templates and concrete steps, and wire it into the CI pipeline and infrastructure tooling so the path is enforced rather than merely suggested. That requires an agent that treats platform work as its actual job: reconnaissance across the whole developer workflow, a defined catalog schema with governance, a golden path with real templates, and an audit that produces a number, not a vibe.

Pave: the platform engineer built for exactly this

Pave is the Tonone platform engineer, purpose-built for developer experience, golden paths, service catalogs, environment management, and internal tooling: it exists to remove friction for the team that actually has to use the platform, not to add another dashboard nobody opens. Where a generalist tool gives you a schema to copy, Pave reads your actual repos first. Two related Tonone agents come in at the edges of this work: Relay, the DevOps engineer who owns CI/CD, deployment pipelines, and GitOps, gets dispatched when a golden path needs a working pipeline template behind it rather than a documentation page describing one. Forge, the infrastructure engineer who owns cloud services, networking, and IaC, gets dispatched when the golden path for "create a new service" needs an actual Terraform module or IaC scaffold, not just a checklist that says "provision infrastructure" and leaves the how unspecified.

Tonone's Pave builds service catalogs and golden paths that make platform decisions legible to every engineer on the team, not just the one who happened to build the tooling.

Reconnaissance before anything gets built

Before Pave proposes a catalog schema or a golden path, it runs pave-recon: a platform reconnaissance pass that inventories every developer tool, environment, build system, and workflow currently in use. This is the step generalist tools skip entirely, because they have no access to run it. For a platform team, this means Pave actually opens the 47 repos, checks which ones have catalog entries and which have gone stale, checks which teams have their own undocumented deploy process, and produces a concrete list of what is missing rather than a theoretical framework for what a catalog should contain.

A catalog schema with a governance model, not just a spreadsheet

pave-catalog builds the actual service catalog: the schema (what fields every service entry needs, owner team, tier, on-call contact, repo link, deploy pipeline link, runbook link), a set of starter entries populated from the recon pass, and, critically, a governance model. Governance is the part most homegrown catalogs skip, and it is the reason they rot. Pave's catalog output specifies who updates an entry and when: does a PR that adds a new service fail CI if the catalog entry is missing, does the owning team get a monthly nudge to confirm the entry is current, what happens when a service is deprecated. Without an enforcement mechanism, a catalog is a snapshot that starts decaying the day it ships. With one, it stays trustworthy because staleness has a cost someone actually pays attention to.

A service catalog nobody enforces is a snapshot. Pave's pave-catalog skill ships a governance model alongside the schema so the catalog stays current after the first month.

Turning one engineer's head into a golden path everyone can follow

pave-golden defines the golden path itself: the opinionated, supported way to do a recurring developer task, producing concrete steps, templates, and the actual tooling behind them, not a wiki page describing intent. For "create a new service," that means a scaffold repo, a CI pipeline template (where Pave hands off to Relay's relay-pipeline for the actual pipeline build), and an infrastructure module (where Pave hands off to Forge's forge-infra for the IaC scaffold). The golden path is only golden if following it is faster than improvising, which means the templates have to actually work, not just describe the intent behind the ideal process.

Measuring developer experience instead of guessing at it

pave-audit is where the qualitative complaint ("onboarding feels slow") becomes a number. It measures onboarding time, build speed, deployment friction, and developer satisfaction, producing a baseline you can re-run after you ship the catalog and golden path to prove the investment moved something real. This is the step that turns platform engineering from a cost center defended on faith into a function that reports a before-and-after number to engineering leadership.

A worked example: fixing onboarding at a 45-engineer platform

Take a platform team of six supporting 45 product engineers across what the org chart says is 38 services. Two new hires joined last month. One of them, three weeks in, still had not shipped a change past staging, because the golden path for "add an endpoint to an existing service and deploy it" was a mix of a two-year-old Notion doc, a Slack thread from March, and a fifteen-minute call with the one engineer who remembered how the deploy pipeline actually worked. Nobody had a number for how long onboarding should take. The platform lead's honest answer to "how long until a new hire ships to prod" was "depends who they sit near."

Pave starts with pave-recon. The output is blunt: 38 services in the org chart, 47 repos with active deploys, nine of which have no catalog entry at all, four of which are zombie repos still receiving alert pages for services that were merged into other services eighteen months ago. Fourteen months since the catalog was last meaningfully updated. Three separate, incompatible deploy processes across teams, only one of which is documented anywhere a new hire could find it.

Pave, Platform Recon: Onboarding Friction
─────────────────────────────────────────────────────────
Catalog: 47 active repos, 9 missing owner + on-call fields,
         4 zombie repos still paging on-call. Last full update:
         14 months ago.
Deploy:  3 incompatible deploy processes across teams. Only 1
         documented. No CI check blocks a new service shipping
         without a catalog entry.
Baseline (pave-audit, cohort of 5 hires, last quarter):
         Time-to-first-deploy:      median 6.0 business days
         Time-to-first-merged-PR:   median 1.5 business days
         DX survey, "I can find who owns X": 2.1 / 5
─────────────────────────────────────────────────────────
Recommendation: pave-catalog (schema + governance) then
pave-golden ("add endpoint + deploy" path), dispatch
relay-pipeline for the CI template and forge-infra for the
shared service scaffold. Re-run pave-audit after next hire
cohort ships.
──────────────────────────────────────────────────────
After (pave-audit, cohort of 5 hires, next quarter):
         Time-to-first-deploy:      median 1.5 business days
         Time-to-first-merged-PR:   median 0.5 business days
         DX survey, "I can find who owns X": 4.3 / 5

With recon done, pave-catalog produces the schema, owner team, tier, on-call contact, repo link, deploy pipeline link, runbook link, and a governance rule: any PR creating a new service fails CI unless the catalog entry ships with it, and every entry gets a quarterly staleness check owned by the team that owns the service. pave-golden then defines the actual golden path for "add an endpoint and deploy it," a scaffold with concrete steps instead of a Notion doc, dispatching Relay's relay-pipeline skill to build the real CI pipeline template behind the path and Forge's forge-infra skill to produce the shared service scaffold as an IaC module so a new service is provisioned consistently instead of by hand each time. Four weeks later, the next cohort of five new hires ships. pave-audit re-runs the same measurements: median time-to-first-deploy drops from 6.0 business days to 1.5, and the internal survey score for "I can find who owns X" moves from 2.1 out of 5 to 4.3. That is the difference between a platform team that believes it improved onboarding and one that can show a VP of Engineering the before-and-after number.

Tonone's pave-audit skill turns "onboarding feels slow" into a measured baseline, time-to-first-deploy, build speed, deployment friction, that platform teams can re-run and report on.

Pave vs the alternatives for platform work

The comparison below is specific to platform engineering tasks: building and governing a service catalog, defining a golden path with working templates behind it, and measuring developer experience with a real number instead of a guess. This is not a fair fight for a generalist chatbot or an autocomplete tool, because neither was built to operate across an organization's repos and workflows in the first place.

Install and try

Tonone is free and MIT-licensed. Install it once and all 100 agents, including Pave, Relay, and Forge, are available in your Claude Code session. You pay only for the Claude Code token usage during the work itself.