The Golden-Path Concierge turns "can I get a service for my team?" into a validated invocation of a paved-path template your platform team already ships: the agent extracts parameters, the schema and policy engine decide what is allowed, and the template does the provisioning.
The agent never invents infrastructure — it fills in blanks on infrastructure you already blessed. This is the agentic front door platform teams are bolting onto scaffolders like Backstage, Port, and GitLab project templates.
Ticket filed. Dana, a senior product engineer at a retail platform company, needs a small returns-eligibility API for the payments team. The platform team has a golden path for exactly this — a blessed template with the standard Dockerfile, deployment manifest, alerting rules, and CI config. Her ticket sits in a queue behind fourteen others.
A platform engineer spends 45 minutes on it — mostly re-asking Dana what the ticket already said: service name? team? internal or partner-facing? how many replicas?
Dana gets a repo. Except under deadline pressure she had already done what half the engineers at the company do: copied refund-service from eight months ago and renamed things.
That copy carries a deprecated base image, an alert route pointing at a disbanded team, and a replica count tuned for a service with 40x the traffic.
The paved road is there, but the on-ramp is a ticket queue, so people cut across the grass. The platform team estimates 30% of "new service" requests are stale copies — golden-path drift becomes its own reliability program.
9:40 am. Dana types into the platform channel: "Need a returns-eligibility API for payments — internal only, low traffic, call it returns-eligibility." The concierge answers in ninety seconds — but look carefully at what it did, because it is deliberately narrow. It did not design a service.
Dana's tech lead approves the PR at 9:52; the registry records the new service, its owner, and its provenance.
Twelve minutes, ticket to paved-path service, and by construction the result is current: latest base image, correct alert route, replica count from the template's defaults — because the only thing generated fresh was five parameter values.
And when Dana's teammate asks the concierge for the same service "plus a public S3 bucket for logs," the concierge does not improvise a bucket. Public storage is not a parameter of the golden path, so the request comes back as a refusal with the policy reason and the escalation path: off-path infrastructure needs a platform request; here is the form. The agent's inability to be creative is precisely what makes it deployable.
The concierge inverts the usual agent risk model — instead of an agent that can do anything being restrained by prompts, it is an agent that can only fill in a template's parameters, restrained by schema, re-validation, and policy. Creativity lives in the template authors; the agent is a form-filler with good manners.
Client-safe by design — the parameter-extraction step runs against an approved tenancy (Claude on AWS Bedrock, Azure OpenAI) or locally via Ollama, with team names, registry hostnames, and internal image paths replaced by placeholders before any request text is prompted; every guard layer (re-validation, policy gate, render, PR) is deterministic local code. Full setup is in the build guide below.
Blue = AI-added step · Amber = human control point · Gray = your existing tools.
| Step | Who acts | What changes | Why it matters |
|---|---|---|---|
| Engineer asks in natural language | Requester | Intent expressed in one sentence, in chat, at the moment of need | The on-ramp moves to where engineers already are — no ticket queue, no form hunting |
| Concierge extracts parameters | AI agent | The sentence becomes candidate parameters, schema-constrained at generation time | NL→structured is the only truly AI-shaped step; everything after is deterministic |
| Code re-validates against the schema | Concierge (deterministic code) | Out-of-range or malformed parameters are rejected mechanically | Defense in depth: structured output narrows failure; re-validation eliminates trusting it |
| Policy gate: quota, naming, tier rules | Your policy engine | Allowed requests proceed; off-path or over-quota asks get a refusal with the reason | Governance becomes a readable "no with a why," not a silent queue rejection |
| Template renders | Your existing scaffolder | The blessed, current golden path is instantiated — nothing invented | Kills copy-paste drift: output is always the latest reviewed template |
| Output lands as a PR | Concierge, under its own identity | A reviewable diff with request, parameters, and policy verdict attached | The Everything-Ends-in-a-PR adapter applies unchanged — same gate, same audit |
| Human approves and merges | Tech lead / CODEOWNERS | One judgment call on a pre-validated, pre-policied diff | Human attention spent on "should this exist?", not on YAML mechanics |
| Registry records the service | Platform | Owner, provenance, parameters recorded at birth | The service catalog is complete by construction — no after-the-fact inventory hunts |
| Component | In this lesson's build | In your stack |
|---|---|---|
| Event source | You running concierge.py "need a service..." | Chat command in Slack/Teams, a Backstage or Port self-service form, an issue template |
| Context stores (read) | templates/microservice/ + params.schema.json + registry.jsonl | Your scaffolder's template repo (Backstage software templates, GitLab/Cookiecutter templates), service catalog, quota records |
| Action interface (allowlisted writes) | Render into services/<name>/ on a new agent/* branch — nothing else | Scaffolder invocation + PR creation via a bot account; zero cloud credentials on the concierge |
| Approval channel | You reviewing the branch before merge | PR review with CODEOWNERS (platform team owns services/*), merge queue |
| Verification | Schema re-validation + policy checks + rendered files reviewed in the diff | Same, plus required CI on the PR: lint, kubeconform, OPA/Conftest policy suites |
| Audit sink + identity | registry.jsonl + commits authored as concierge@agents.local | Service catalog entry with provenance + bot-account commit history + policy-decision logs |
The concierge always emits a PR; a human always merges. Because the blast radius is already bounded by the template and the policy gate, this pattern starts one rung higher than most — the schema did the de-risking that other patterns buy with weeks of advisory mode.
Auto-merge on green checks, for one request class only — e.g. sandbox-tier services for teams under quota. Encode the class in the merge rule.
Production-tier or partner-facing services stay human-merged, however good the track record looks.
Review cadence: monthly, jointly with the template owners: sample five requests end-to-end, review every refusal (refusal quality is UX — a bad "no" sends people back to copy-pasting), and check the registry against reality.
Every refusal is a product signal. If the concierge keeps refusing the same off-path ask, that is your users telling you what the next golden path should be.