Agentic Golden Paths: From Paved Roads to AI Agents That Walk Them With You

A golden path used to be a template, a pipeline and a good README. In an AI-native team, the path can also have guides: agents that know the rules, do the boring steps, and hand the work to the next agent. This post explains how.

1. The Classic Golden Path, in One Minute

A golden path is the recommended, ready-made way to do a common engineering task, such as creating a service, setting up CI/CD or deploying. It bundles tested templates, tools, config and good practice into one flow.

• Optional, not forced. It wins because it is the easiest road.
• Why teams use it: faster onboarding, less to remember, the same standards everywhere, fewer repeat questions, security built in.
• Four principles: optional, transparent, extensible, customizable within limits.
• How to measure it: adoption, developer satisfaction, and efficiency (time to first deploy, cycle time, support load).

Sources

• Spotify Engineering, "How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem" (2020), where the term comes from.
• Netflix, the "paved road" idea for internal tooling.
• Jellyfish, "How to Build Golden Paths Your Developers Will Actually Use"
• platformengineering.org, community articles on golden paths and internal developer platforms.

2. Why the Classic Path Is Not Enough Anymore

The classic path is static. Someone writes the template and the docs, and then they slowly go stale. Developers still have to read, search and ask. AI-native teams work differently:

The principles stay the same. The path is still optional, transparent, extensible and customizable. What changes is that the path now talks back.

3. The Big Picture

There are three layers:

1. Supply: a knowledge base that feeds every agent.
2. Agents: role-based agents that each own one part of the path.
3. Flow: a spec-driven process that moves work from idea to customer.

flowchart LR
    DEV([Developer]) --> AG
    KB[(Knowledge Base)] --> AG
    subgraph AG[Role-based Agents]
        direction LR
        ON[Onboarding] ~~~ SP[Spec] ~~~ BU[Builder] ~~~ RV[Reviewer]
        QA[QA] ~~~ RT[Release Test] ~~~ DE[Deployer] ~~~ OB[Observability]
    end
    AG --> CUS([Customer])
    AG -. lessons .-> KB
                

4. The Supply: A Knowledge Base

Every agent is only as good as what it knows. The knowledge base is the single source of truth that all agents read from.

Out of scope: how to build the knowledge base (storage, indexing, retrieval, access control) is not covered in this post. We assume it exists and is well structured.

What it should hold:

Rule of thumb: if an agent had to guess, the knowledge base has a gap. Agents should report those gaps.

5. The Agents and Their Roles

Each agent has one job, a clear input and a clear output. Small, focused agents are easier to trust, test and replace.

The Observability Agent and Its Sub-Agents

Production is noisy, so the Observability Agent splits the work:

flowchart LR
    P[Production signals] --> SUB
    subgraph SUB[Observability Agent]
        direction TB
        L[Logs] ~~~ T[Trace] ~~~ M[Metrics]
        S[SLO] ~~~ C[Cost] ~~~ U[User Impact]
    end
    SUB --> R[Health report + rollback advice]
                

The coordinator combines their signals into one answer: is this release healthy, and should we roll back?

Other Agents You Can Add

• Security Agent: checks dependencies, secrets and risky changes in trunk code.
• Docs Agent: updates docs and changelogs from merged specs.
• Incident Agent: opens the incident, gathers context, drafts the postmortem.
• Platform Health Agent: reports when teams leave the path often. That usually means the path needs to change.

6. How the Agents Work Together

You have two main options.

Option A: Composable Agents in One Framework

All roles live in one system and share skills and workflows. Mitra is an example: a set of agent personas (Analyst, Architect, Engineer, Designer and more), each with its own skills and review workflows, running inside Claude Code and similar tools.

• Good for: small and medium teams that want one place to manage all agents.
• Pros: shared context, one setup, easy to add new roles.
• Cons: one framework to maintain, and a larger blast radius if it breaks.

Option B: Standalone Agents That Talk to Each Other

Each role is its own agent, for example a separate Claude Code session per role. Agents pass work along through a messaging layer, such as Claude Code channels or a team chat. An orchestrator, either a dedicated Claude agent or another model like Grok, controls the order and the handoffs.

• Good for: larger teams, or when different teams own different agents.
• Pros: agents can be updated, scaled and replaced one by one.
• Cons: you need clear message formats, retries and good logs.

flowchart LR
    subgraph A[Option A: Composable]
        direction TB
        F[Framework e.g. Mitra] --> AP
        subgraph AP[Personas]
            A1[Spec] ~~~ A2[Builder] ~~~ A3[Reviewer]
        end
    end

    subgraph B[Option B: Standalone + orchestrator]
        direction TB
        O[Orchestrator: Claude or Grok] <--> CH{{Message channel}} <--> BP
        subgraph BP[Agents]
            B1[Spec] ~~~ B2[Builder] ~~~ B3[Reviewer]
        end
    end
                

Tip: start with Option A. Move a role out as a standalone agent once it is stable and needs to scale on its own.

Handoff Rules (for Both Options)

Every handoff should carry the same basic package:

Agents should never pass "trust me". They pass proof.

7. The Spec-Driven Flow: From Day One to the Customer

The spec is the spine of the agentic path. Every agent reads it, checks against it, and updates it if reality changes. For more on this, see Spec Driven Development Part 1 and Part 2.

flowchart LR
    A[Onboard] --> B[Spec] --> G1{{Human ✅}} --> C[Build + Review] --> G2{{Human ✅}} --> D[QA + Release Test] --> G3{{Human ✅}} --> E[Deploy] --> F[Observe] --> CUS([Customer])
    F -. lessons .-> B
                

Step by Step

Humans Stay in Charge

Agents do the work. Humans own the decisions. Three gates always need a person:

1. Spec approval: are we building the right thing?
2. Merge approval: is this the right code, and can someone explain it?
3. Release approval: is it safe to ship now?

For trunk code, the risky shared parts, add stricter human review. For leaf code, agents can carry more of the load. See How to Review Code When AI Writes Most of It.

8. Onboarding: The Biggest Quick Win

Onboarding is where the agentic path pays off first.

The new hire learns the path by walking it, with an agent explaining each step, not by reading about it.

9. Keeping the Classic Principles

The four classic principles still apply. Here is how they look with agents:

10. Measuring the Agentic Path

Keep the classic metrics and add a few agent-specific ones.

Dashboards show what happened. Talking to developers shows why.

11. How to Start

Do not build eight agents at once.

1. Pick one painful path. "New service to first deploy" is a good first choice.
2. Write the knowledge base pages for it: standards, template, runbook, environments.
3. Add two agents: Onboarding and Deployer.
4. Add the Spec Agent and make specs the starting point.
5. Add Reviewer and QA once the specs are stable.
6. Add Observability with one or two sub-agents (Logs and Metrics first).
7. Measure, listen, and grow one agent at a time.

flowchart LR
    V1[v1: KB + Onboarding + Deployer] --> V2[v2: + Spec] --> V3[v3: + Reviewer + QA] --> V4[v4: + Release Test + Observability] --> V5[v5: + Security, Docs, Incident]
                

12. Risks to Watch

Many of these risks are about the system around the model, not the model itself. Harness Engineering covers that side in more depth.

13. Takeaways

• The classic golden path is still the base: optional, transparent, extensible, customizable.
• The knowledge base is the supply. Without it, agents guess.
• Role-based agents walk the path with the developer, from day one to the customer.
• Specs connect every step and every agent.
• Start composable (for example, with Mitra). Split agents out when they need to scale.
• Humans approve the spec, the merge and the release.
• Measure adoption, speed, quality, trust and cost, and keep improving.

14. Read More

• Mitra: composable AI agent personas
• Why Spec Driven Development, Part 1: The Three Problems
• Why Spec Driven Development, Part 2: The Framework
• How to Review Code When AI Writes Most of It
• Harness Engineering
• Claude Code Best Practices