This is Part 0 of a series on building agentic AI workflows for platform engineering. Part 1 jumped straight into the practical how-to: your first steering file, the workspace structure, getting started with Terraform. This article takes a step back to ask a broader question: why is every team building this from scratch?

Something odd is happening across the industry right now. Thousands of platform engineering teams are independently discovering the same thing: AI coding assistants are competent at the language level but ignorant at the team level.

They know Terraform syntax but not your Terraform conventions. They know Kubernetes but not your Kubernetes workflow. They'll generate a perfectly valid IAM policy using jsonencode() when your team exclusively uses data.aws_iam_policy_document. They'll suggest kubectl apply when your team is GitOps-first and everything goes through ArgoCD.

The fix is straightforward. You encode your standards into files that AI agents read automatically: steering files, skills, agent definitions, so every conversation starts with your team's conventions already loaded. I'll cover the mechanics in detail later in this series.

But here's the question nobody seems to be asking: why is every team writing these from scratch?

The Terraform Module Problem, Again

We've been here before. Before the Terraform Registry existed, every team wrote their own VPC module. Most of them were 80% identical: the same subnets, the same route tables, the same NAT gateway pattern, with 20% of team-specific customisation on top.

The Terraform Registry didn't eliminate custom modules. It eliminated the redundant 80%. Teams could start from a community module and customise the rest.

AI workspace configurations have the same problem today. Every platform team that adopts agentic AI tooling starts from zero:

• "Always use data.aws_iam_policy_document", discovered independently by every AWS/Terraform team
• "Conventional commits with semantic release", written into a steering file by every team that uses them
• "No 0.0.0.0/0 ingress unless documented", encoded as a rule by every security-conscious team
• "Pin provider versions, pin Terraform versions", rediscovered after the first breaking upgrade

This is collective knowledge being individually rediscovered. It's wasteful, and it's solvable.

A Layered Model for Shared Standards

The solution looks like what already works for linting, CI templates, and infrastructure modules: composable, shareable, layered configuration.

Layer 1: Industry baseline. Universal best practices that are true regardless of your organisation. AWS Well-Architected principles as steering rules. CIS Benchmarks as security baselines. Terraform style conventions. Git hygiene. These should be published, versioned, and consumable, not rediscovered by every team.

Layer 2: Organisation standards. Your company's specific opinions layered on top: naming conventions, tagging standards, provider version pins, CI template references, security baselines. Shared across teams within the organisation, maintained centrally, consumed as a dependency.

Layer 3: Team customisation. The 20% that's genuinely unique: your specific module structure, your environment names, your repo layout. This is the only layer teams should write from scratch, and it's small because the heavy lifting was done by the layers below.

The key property is that each layer extends and can override the previous one, exactly like ESLint's shareable configs, where you extend eslint-config-recommended, then your org's config, then add your team's overrides.

The tooling is already moving in this direction. Kiro provides an explicit layered model through its .kiro/ directory: steering files, skills, and agent definitions at different scopes. Claude Code supports a similar pattern natively through CLAUDE.md files scoped at the project root, subdirectory, or global level. The concept of layered, overridable context isn't hypothetical; it's how multiple tools already work. What's missing is the sharing and distribution layer on top.

This Is Already Starting to Happen

The pattern isn't theoretical. Early efforts are emerging that treat standards as machine-readable tooling rather than documents.

In the UK Government space, Version 1 (my employer) open-sourced a proof-of-concept MCP server wrapping 102 curated UK Government technology standards from GDS, NCSC, Cabinet Office, and ICO as searchable, context-aware tools. Instead of an engineer reading through the Service Manual to find applicable accessibility standards, their AI assistant can query them directly, filtered by work type, development phase, and priority level. The repo hasn't seen active development since its initial release, but the concept holds: standards as something AI agents consume, not something humans remember to check.

In the US, LegislMCP takes a similar approach for government data: an open-source MCP server spanning 29 federal and state data sources with 161 tools, covering everything from Congressional records to FDA and EPA data.

These are point solutions, individual MCP servers for specific domains. The bigger opportunity is the layered model: composable packs of steering files, skills, and agent definitions that teams can extend rather than rebuild.

Where Standards Bodies Fit

This is where it gets interesting for organisations with centralised standards: government departments, regulated industries, large enterprises.

Take UK Government as an example. GDS already publishes the Technology Code of Practice and the Service Standard. NCSC publishes cloud security guidance. These are well-maintained, authoritative, and widely referenced. They're also PDFs and web pages that people read once during onboarding and then forget.

What if they were published as AI workspace configurations instead?

A GDS steering pack could encode the Service Standard as rules that AI agents follow automatically. Not "here's a document about accessibility" but "every frontend component you generate must meet WCAG 2.2 AA, and here's how." An NCSC security pack could encode their cloud security principles as non-negotiable guardrails that every agent respects by default.

The distribution mechanism already exists. Git repos with semantic versioning. Teams declare a dependency, pin a version, and get updates when the standards evolve:

extends:
  - "@gds/service-standard:^2.0"
  - "@ncsc/cloud-security:^1.5"
  - "@myorg/platform-standards:^3.0"

Updates to security guidance would propagate to every team's AI agents on the next version bump. That's fundamentally different from emailing a PDF and hoping people read it.

The Gap Today

To be clear, the ecosystem isn't there yet. There's no standard format for shareable AI workspace configurations. No version resolution for layered configs. No discovery mechanism. No governance model for who maintains the GDS steering pack and how changes are reviewed.

But these are solved problems in adjacent domains. The npm registry solved package discovery and versioning. ESLint solved layered configuration with extends chains and override rules. The Terraform Registry solved module sharing with documentation and version pinning. The AI workspace ecosystem just needs to catch up.

What You Can Do Now

You don't need to wait for the ecosystem. You can structure your workspace to be ready for it:

1. Separate universal rules from team-specific ones. Even within your own steering files, keep a clear boundary between "this is true for any AWS Terraform project" and "this is specific to us." When shareable packs exist, you'll know exactly which rules to replace with a dependency.

2. Version your workspace config. It's already in git. Treat it like a product: tag releases, write changelogs, make it consumable by other teams in your organisation.

3. Share within your org first. If you have multiple platform teams, publish your Layer 2 config as an internal package. Get feedback. Iterate. This is the fastest way to discover what's genuinely universal and what's team-specific opinion.

4. Contribute upstream. If you've written a good AWS Terraform baseline, open-source it. The community will tell you quickly what's universal and what's opinionated.

The Series So Far and What's Next

This article covered the why: why shared, layered AI workspace configurations matter and why every team shouldn't start from scratch.

Already published:

• Part 1: Your First Steering File: Teaching AI Your Terraform Conventions: the practical getting started guide covering workspace structure, your first steering file, and the tooling choice

Coming next:

• Part 2: Steering files in depth, encoding Terraform, Git, and CI/CD standards as non-negotiable rules
• Part 3: Skills and agents, deep reference material and purpose-built agents for different roles
• Part 4: Tool integrations and the refinement loop, connecting agents to your workflow and making the system compound over time

Each part is practical and hands-on, with real examples from an AWS platform engineering stack (Terraform, GitLab, EKS, Control Tower).

If you haven't read Part 1 yet, start there for the hands-on setup.

If you're building agentic AI workflows into platform engineering, or thinking about shared standards for your organisation, I'd love to hear your approach.