AI Agents for Scaleups: The Golden Path Playbook for Series A/B Engineering Teams

A Series B company doubling headcount from 45 to 95 engineers in nine months does not have an engineering culture problem on day one. It has one by month six, when four new squads have each independently decided how to set up a local dev environment, how to structure a Dockerfile, and how a service gets from a merged PR to production. Nobody made a bad decision. Every squad lead made a reasonable decision in isolation, under deadline pressure, with no time to check what the squad next door was doing. The result by month nine is five different CI configurations, three ways of managing environment variables, and a new hire's time-to-first-deploy that has quietly crept from two days to nine. This is not a hiring problem or a talent problem. It is the absence of a golden path, and it is the single most predictable failure mode of the $1M-to-$10M ARR stage, the point where topic authority in engineering practice needs to replace ICP-era improvisation.

Why a generalist chatbot and an autocomplete tool both miss this

Ask ChatGPT or Claude.ai "how should we standardize our deploy process across teams" and you get a competent, generic answer: use CI/CD, containerize your services, adopt infrastructure as code. It is not wrong. It is also not useful, because the actual problem at a 95-person scaleup is never the absence of knowledge about best practices, every squad lead already knows what a Dockerfile is supposed to look like. The problem is that six squads independently applying good judgment produce six incompatible outcomes, and no generalist chatbot has visibility into what those six outcomes actually are. A generalist tool answers the question you typed. It cannot read your actual repositories, compare the CI configs squad by squad, and tell you that platform-team's GitHub Actions workflow diverged from growth-team's Buildkite pipeline eleven weeks ago and nobody noticed until an incident postmortem surfaced it.

Cursor and GitHub Copilot solve an entirely different layer of the problem. They are fast, context-aware autocomplete inside a single file, in a single repo, for a single engineer. That is exactly the wrong altitude for a scaleup's real pain. The engineer sitting in Cursor writing a new service's Dockerfile is not going to autocomplete their way into consistency with four other squads' Dockerfiles, because Cursor has no concept of "the other squads." It optimizes the file in front of it. It has no mechanism for producing a template that every future service scaffolds from, no mechanism for auditing existing services against that template, and no mechanism for onboarding a new engineer onto a documented, supported path rather than whatever the last engineer who joined that squad happened to improvise. The gap is architectural, not a matter of prompting harder.

What a platform engineer does at this stage, and where Pave fits

Tonone's Pave is the platform engineer: developer experience, golden paths, service catalogs, environment management, and internal tooling, built to remove friction for the team that actually exists today, not the team from the founding pod era. Pave's job is not to write more features. It is to look at how engineers currently create a service, set up an environment, and ship a change, and to produce the opinionated, documented, tooled version of that path so the next squad does not have to reinvent it. Two related agents matter here. Relay owns CI/CD, GitOps, and deployment execution, the pipeline mechanics that a golden path has to standardize on. Warden owns IAM, secrets, and hardening, the security posture that has to be baked into the golden path rather than bolted on after an audit finding. Pave defines the path; Relay and Warden supply the deployment and security substance that path is built around.

Tonone's Pave builds the golden path, the opinionated, supported, documented way to create a service, set up an environment, or ship a change, so new squads onboard to one system instead of inventing their own.

Defining the golden path

The pave-golden skill is where this work starts. You point Pave at the actual state of the codebase, the CI configs currently in use, the environment setup scripts (or lack of them), the Dockerfiles that already exist across services, and it produces the golden path: concrete steps, templates, and tooling for the common developer tasks that every squad performs, creating a new service, deploying a feature, standing up a local environment. This is not an abstract best-practices document. It is a scaffolding command a new squad runs, a template repo they fork, a documented sequence they follow, with the tooling to enforce it rather than merely recommend it.

Auditing developer experience before it's a fire

pave-audit measures the thing most Series B engineering leaders only find out about during an incident retro: onboarding time, build speed, deployment friction, and developer satisfaction, quantified rather than assumed. It is the diagnostic step that tells you time-to-first-deploy has drifted from two days to nine before a new hire's exit interview tells you the same thing six months later. Run it quarterly as squads scale and you catch fragmentation while it is still a one-week fix, not a company-wide re-platforming project.

Cataloging what actually exists

pave-catalog builds the service catalog, the schema, starter entries, and governance model that answers "what services do we have and who owns them" without a spreadsheet someone maintains by hand and nobody trusts. At 95 engineers across nine squads, this question stops being rhetorical. It becomes the difference between a five-minute answer and a two-day archaeology project when an on-call engineer needs to know who owns the billing-adjacent service that just started erroring.

A worked example: Voss Analytics, Series B, 45 to 112 engineers in 14 months

Voss Analytics raised a $38M Series B and grew from 45 to 112 engineers across 14 months, adding nine new squads. By month ten, the VP of Engineering pulled the numbers and did not like what she found. Three CI stacks were live in production: the original platform team used GitHub Actions, a squad hired from a Buildkite shop brought Buildkite with them, and a squad formed from an acquihire kept the Jenkins setup they already knew. Onboarding time for a new engineer to their first production deploy averaged 9.4 days, driven almost entirely by which squad they landed in and whether that squad had documented anything. Two squads had no Dockerfile at all, running services directly on EC2 instances someone had hand-configured eighteen months earlier and nobody wanted to touch. A pre-SOC2 security review found four different secrets-management approaches across nine squads, ranging from a shared Vault instance to, in one case, secrets committed to a private repo.

The VP brought this to Pave with a single brief: define one golden path for creating a new service, deploying it, and setting up a local environment, and make it the default every new squad onboards to. Pave ran pave-audit first, quantifying what the VP suspected: 9.4 days median time-to-first-deploy, three incompatible CI stacks, four secrets patterns, zero service catalog. It then ran pave-golden against the two best-performing squads' existing setups, the platform team's GitHub Actions pipeline and the newest squad's already-solid Docker Compose local dev environment, rather than inventing something new from scratch. The output specified a template repository with a standardized multi-stage Dockerfile, a single GitHub Actions pipeline definition that every service inherits from, a one-command docker compose up local environment, and an explicit handoff point to Relay for the CI/CD execution and Warden for secrets and IAM baseline.

Pave, Golden Path Scope: Voss Analytics
Audit: 9.4d median time-to-first-deploy, 3 CI stacks (GH Actions,
Buildkite, Jenkins), 4 secrets patterns, 0 service catalog.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Golden path: new service creation
  Template repo, forked via one CLI command.
  Multi-stage Dockerfile (build, test, runtime), pre-hardened.
  Single GH Actions workflow, inherited, not copy-pasted per repo.
  Service auto-registers into the catalog on first merge.
  Owner: Pave (template), Relay (pipeline execution).

Golden path: environment setup
  One command: `make dev`. Docker Compose, seeded data, hot reload.
  Parity check against staging config, flagged on drift.
  Owner: Pave.

Golden path: deploy
  Merge to main triggers Relay's pipeline: build, test, deploy,
  rollback plan attached automatically.
  Secrets resolved from single Vault instance, no repo secrets.
  Owner: Relay (pipeline), Warden (secrets, IAM baseline).

Migration: 9 existing squads, staged over 6 weeks.
  Newest 3 squads (least legacy debt) migrate first, weeks 1-2.
  Platform team's existing GH Actions becomes the shared base, weeks 3-4.
  Legacy Jenkins squad migrates last, weeks 5-6, highest debt.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Result after 6 weeks: time-to-first-deploy 9.4d -> 1.6d.
Next: warden-harden pass on the shared template, then
pave-catalog to register all 9 squads' services.

Six weeks later, time-to-first-deploy for a new engineer dropped from 9.4 days to 1.6 days, because the new hire's first task is now "fork the template, run make dev, open a PR," not "find whoever set up the Jenkins job eighteen months ago and ask them what half the environment variables mean." The nine squads did not lose autonomy over their product logic. They lost the option to independently reinvent the parts of engineering that were never differentiated work in the first place: how a Dockerfile gets built, how a pipeline resolves secrets, how a local environment gets seeded with data. That is the actual content of a golden path. It is not a mandate handed down from platform team; it is the best existing pattern, generalized, tooled, and made the path of least resistance so the next nine squads inherit consistency by default instead of by memo.

The golden path Pave defines is not a policy document. It is the scaffolding, template, and default tooling that makes the standardized way also the fastest way, so squads follow it because it is easier, not because they were told to.

The security dimension mattered as much as the speed dimension. Warden's warden-recon had already flagged the four-secrets-pattern problem during the initial audit; once the golden path routed every service through a single Vault instance by default, Warden ran warden-harden against the shared template once, instead of auditing nine separate, divergent setups. That is the compounding effect that matters at this ARR stage: security posture, deploy consistency, and onboarding speed stop being three separate problems solved nine times each, and become one problem solved once, in the template every future squad inherits.

Pave vs the alternatives, for scaleup platform work specifically

The comparison below is scoped to what a Series A/B engineering leader is actually trying to solve: consistency across a growing number of squads, not a single engineer's productivity in a single file. That distinction is exactly where generalist chatbots and autocomplete tools have no real answer, because neither one has a concept of "squad" or "catalog" at all.

Tonone's Pave, Relay, and Warden turn a scaleup's fragmented deploy and security practices into one template every squad inherits, instead of nine squads each solving the same problem differently.

Install and try

Tonone is free and MIT-licensed. Install it once and Pave, Relay, Warden, and the rest of the roster are available in your Claude Code session. You pay only for the Claude Code token usage during the work itself.