What is an AI system builder? The infrastructure role enterprises are missing

What is an AI system builder?

An AI system builder is an engineer who designs and constructs the AI infrastructure (orchestration patterns, evaluation pipelines, agent coordination frameworks and development tooling) that enables teams to build, evaluate and operate AI systems at scale.

Their output is measured differently from most engineering roles, not by the quality of any single product but by how much faster and more reliably every subsequent product gets built. The infrastructure the AI system builder creates for one initiative becomes the platform on which the next five initiatives build, so if you're trying to move from one AI product to many, this is the role that will determine whether that scales or starts over.

How the AI system builder differs from the AI developer

Here’s a simple metaphor to get us started. The AI system builder creates the factory. The AI developer uses the factory to build products. The bigger differences lie in the who/what/why that each role is actually building for:

Different customers

An AI developer's customer is the end user, the person interacting with the AI-powered product. An AI system builder's customer is the development team.

The quality bar, the feedback loops and the failure modes are all different. When an AI developer ships something that doesn't work, a user has a bad experience. When an AI system builder ships something that doesn't work, an entire team slows down or builds on unreliable foundations.

Different time horizons

AI developers work in product cycles, such as shipping features, iterating on user feedback and responding to market signals.

AI system builders work on a longer arc. The orchestration layer they design today needs to support products that haven't been scoped yet. Getting that architecture wrong tends to show up six months later, when the third or fourth product built on top of it hits a constraint that requires rearchitecting the foundation.

Different instincts

The best AI developers have cross-domain fluency. They think about product, design and engineering together, making informed decisions about what to build and how it should work for users.

The best AI system builders have a different kind of fluency. They think about systems, scale and developer experience. Their instinct is to look at work that one team did well and ask how to make it available to every team. They're wired for repeatability, not novelty.

These are complementary profiles, not a hierarchy, and we’re still in the early stages. Today, the split is blurry in practice but will sharpen over time. At TELUS Digital, some engineers build both the product and the underlying infrastructure. However, we’re observing that the practitioners who become genuinely exceptional at AI system builder work develop a scaled mindset. Their instinct isn't, "How do I build this for my team?" but "How do I build this for every team, at once, with as few barriers as possible?"

This is the natural evolution of developer experience work. The AI system builder is what that role becomes in an AI-first engineering organization, like TELUS Digital. We've always had teams focused on developer productivity and platform engineering, making sure everyone is bootstrapped to move fast. As the complexity of AI infrastructure increases and the number of teams building on top of it grows, the depth required in each direction, from product-facing to platform-facing, makes the split inevitable. It doesn't need to be mandated. The demands of the work create it.

What AI system builders actually build

Two examples from inside TELUS Digital's engineering practice show what this work actually looks like.

Multi-agent development infrastructure

Joel Garrett, principal software engineer at TELUS Digital, has been building what he calls the ARDEN fleet, which is a suite of specialist AI agents that run as independent voices on every pull request, covering security review, QA, design and product management.

Rather than handing off to each other, the agents operate in parallel, each assessing the pull request through its own lens and surfacing findings independently. In the cases where they've been deployed, review cycle times have been dramatically faster and more thorough than human review. Where a human reviewer brings one perspective to a pull request, ARDEN brings four simultaneously.

The next step is coordination: Joel is building an orchestrating agent that will run above the specialist fleet, synthesizing their findings into a unified review. He's also building evaluation frameworks into each new agent as it's built, which is one of the reasons the work is taking longer than a prototype would. Building AI systems properly, with evaluation, takes more time than building them impressively. While the factory isn't finished, it's already running.

An AI-assisted SDLC pipeline at scale

Vatsal Bhatt, a platform engineer at TELUS Digital, set out to solve how to give 70+ developers across 10 squads the benefits of AI-assisted development. The challenge was how to do so without every team rebuilding the same tooling from scratch, and without one team's AI noise polluting shared knowledge across the organization.

The answer was a three-tier, shared-memory architecture built on top of Claude Code.

A slow layer packages the core AI configuration as a versioned node package manager (npm). Squads pin to versions and receive updates on a semantic versioning (semver) contract, enabling patches to auto-update, minor improvements to be opt-in and major changes to be coordinated. This provides teams with stability while allowing the platform to improve continuously.

A fast layer runs an MCP knowledge server backed by a vector store and Postgres. A dedicated scribe agent writes new learnings at the end of every development session. A nightly continuous integration (CI) job then clusters learnings across all ten squads. When three or more squads independently surface the same pattern or anti-pattern, the system opens a pull request to permanently promote that learning into the shared pipeline. Humans review every promotion before it merges. The consensus threshold is intentional. It filters noise and ensures only validated, cross-squad patterns make it into shared infrastructure.

A human layer provides periodic governance digests for visibility and oversight across the organization.

The pipeline ships as a Claude Code plugin. Its agent roster (orchestrator, scout, architect, coder, tester, reviewer and scribe) auto-detects whether a repository is web, BFF/API or React Native and loads the right skills, agents and guardrails for that stack. This results in approximately 30 committed files reduced to just three. Vatsal's output doesn't ship to customers. It ships to the 70+ developers on a client project team, and to every subsequent team that adopts the pipeline. He didn't build a product on top of AI. He built a factory.

Why the AI system builder role is becoming a bottleneck

Most organizations can build their first AI product without a dedicated AI system builder. A strong AI developer or a capable engineering team can handle the infrastructure along the way, building just enough orchestration, evaluation tooling and operational scaffolding to get one product into production.

However, problems may surface with the second product, the third and so on. When each team builds its own version of the same infrastructure, new patterns, evaluation approaches and operational blind spots stack up. The work gets duplicated. Quality gets inconsistent. The organization builds AI products, but it doesn't build the capability to build AI products.

AI system builders solve this by turning one team's hard-won solutions into shared infrastructure. The orchestration layer that worked for one product becomes the platform for those that follow. Evaluation frameworks that one team designed by hand become repeatable pipelines. Operational patterns that were figured out through painful trial and error become defaults rather than discoveries. The institutional knowledge stops being locked inside one team's codebase.

AI developers are rare because cross-domain fluency is rare. AI system builders are rarer still because the instinct to build for other builders, combined with the infrastructure skill to do it well, is an unusual combination. Most engineers who are talented enough to build strong AI infrastructure also want to build products. The ones who see infrastructure itself as the product are a genuinely small population.

As enterprises move from "We have an AI product" to "We are an organization that ships AI products," the AI system builder becomes the constraint. You can hire or contract for AI developers, but if the infrastructure they build on doesn't exist or is fragile, it limits everything that sits on top of it.

What the rarity of AI system builders means for enterprises scaling AI

For organizations moving beyond their first AI initiative, here’s what to prepare for:

Hiring an AI system builder is a capability decision, not a product decision

If you're trying to build an organization that ships AI products repeatedly and at increasing speed, you need AI system builders. This is a new kind of investment with a different payoff timeline, and it requires a deliberate decision.

AI system builders are defined by orientation, not background

AI system builders don't come from one specific background, but they all tend to have experience in platform engineering, developer tooling or ML infrastructure, combined with the instinct to ask "How do I make this work for every team, not just this one?" The key is understanding whether their default orientation is toward the product or toward the platform.

At TELUS Digital, the AI system builders who have emerged have spent their careers thinking about how engineering teams work, not just the products they build. The distinguishing characteristic is an orientation, not a specific background. Our AI system builders generalize the strong infrastructure they build by looking at what worked on one team and immediately asking what it would take to make it work for every team.

The ROI of AI system builders compounds over time

The ROI of an AI system builder is hard to measure in the short term because their output ships to teams, not customers. The value shows up in the third, or even tenth, AI product, the ones that get built faster and more reliably because the infrastructure already exists.

Organizations that measure by organizational velocity rather than product output alone will get the most from an AI system builder. If you need to know whether you have the right infrastructure capability to support an AI system builder, reach out to our experts.