Build, Buy, Borrow, Bots: The Seven-Layer Sourcing Stack

For three decades, capability decisions have been reduced to a triangle. Build it in-house, Buy a vendor product, Borrow the skills from a partner. Nothing was wrong with that framework. It worked because the unit of analysis — a discrete capability — could be cleanly assigned to one of three boxes, with very little overlap and cost structures comparable enough to run a credible total-cost-of-ownership comparison.

What AI is dissolving is not the framework. It is the unit of analysis underneath it. A modern capability is not a skill you can put in a box. It is a stack: a foundation model doing anomaly reasoning and narrative generation; an orchestration layer routing sub-tasks; execution bots posting journal entries and resolving tickets; the ERP holding the system of record; one or two AI-native point tools; a systems integrator helping with rollout; and a small team of humans who supervise, intervene, and own the audit defense.

Each has a different sourcing logic, refresh cycle and risk profile. Lumping them together produces decisions that are technically defensible and strategically incoherent.

What pushed the triangle past its breaking point

Three forces. The foundation-model layer became a genuine commodity input — three or four credible providers, priced per token, accessible to anyone with a credit card. The agent layer emerged as a new locus of differentiation: the same model can be wrapped in dramatically different orchestration logic, and it is in orchestration that institutional knowledge gets encoded. And the bot layer matured to where well-scoped tasks run end to end without a human in the loop, shifting the binding constraint from "can we do it" to "can we govern it."

The obvious response is to add a fourth box called Bots and move on. That is the most visible change, but not the most important, and doing only that leaves a framework that is still misleading. The bigger change is internal. Build has decomposed into foundation models, agents, and human skills. Buy has split into legacy systems of record and a fast-moving layer of AI-native point tools. The labels stayed the same. The substance changed.

Seven layers, four pillars

Each of the seven layers has its own ownership pattern and pace of change. Foundation is a procurement decision made under rapid technical change, with swap-out planned from the start. Agents is where operating logic gets encoded, and it is the most function-specific layer. Skills is the human control layer. Existing systems are the substrate. Partners have shifted from staff augmentation toward outcome-based engagements carrying reusable IP.

Finance and Accounting was our worked example, but the structure is not finance-specific. Applied to Human Resources, it looks like this.

• Build (Foundation) — What it means in HR: Reasoning models for screening, interview synthesis, policy Q&A · Who owns it: Hybrid · Value created: Intelligence, reasoning
• Build (Agents) — What it means in HR: Requisition routing, candidate prioritization, internal-mobility matching · Who owns it: Internal (HR + AI/IT) · Value created: Process intelligence
• Build (Skills) — What it means in HR: Offer negotiation, sensitive conversations, workforce planning judgment · Who owns it: Internal · Value created: Trust, judgment
• Bots (Execution) — What it means in HR: Background-check bots, payroll exception bots, benefits enrollment bots · Who owns it: Hybrid · Value created: Throughput
• Buy (Existing) — What it means in HR: Core HRIS and payroll: Workday, SuccessFactors, ADP · Who owns it: Enterprise · Value created: Stability, compliance
• Buy (New) — What it means in HR: AI-native talent tools such as Lattice · Who owns it: Vendor · Value created: Targeted improvement
• Borrow (Partners) — What it means in HR: Transformation partners for org design and rollout · Who owns it: External · Value created: Speed, expertise

We ran the same exercise across software engineering, where the agent layer holds issue triage, PR review routing and incident response, and across Sales, where it holds lead scoring and account prioritization. The contents change by function. The structure does not.

Why Agents is the layer that carries the advantage

Agents are where institutional knowledge lives. An agent that orchestrates the financial close knows things written down nowhere else: which entities post late, which intercompany relationships are fragile, which exceptions are worth waking a controller about and which can wait until morning. That layer is the one most likely to be undervalued in a sourcing review, because it does not look like software. It looks like a configuration, a set of prompts, a routing graph. It is where process intelligence becomes durable, and where the cost of getting it wrong is highest.

The Skills layer is the second thing people get wrong. The popular narrative says it shrinks as the stack grows. What we see is that it changes shape rather than size. The mix moves from preparation, which bots and agents now handle, toward judgment, exception handling, stakeholder communication and audit defense. Headcount may stay flat; the seniority profile rises. Treating Skills as a residual line item that absorbs whatever automation missed is the most common mistake we encounter.

Bots deserve one honest caveat. That is where most of the reportable productivity shows up, and it is not fake — a bot posting 10,000 journal entries a month produces a number that goes straight onto a slide. The risk is that its visibility crowds out the layers above. Most organizations we work with are over-invested in bots relative to agents, producing a stack that is fast at doing the wrong things and slow to learn from the exceptions it generates.

The substrate, the point tools, and what a partner owes you

SAP, Oracle and Workday are not obsolete. They have become the substrate — the system of record everything else reads from and writes to. That is not a demotion; a reliable substrate is what makes the layers above it possible. But it changes the question from "can we get more value out of it" to "can we keep it stable and instrumented enough that the layers above can move quickly." Usually that means not customizing it in ways that make it harder to read.

The new-tools layer should stay thin and replaceable. These tools do one thing well and get replaced every few years as a new entrant takes the category. Let one become your de facto agent layer and you are locked into a vendor's view of how your process should work. Partners have changed most of all: the unit of analysis is no longer the engagement but the IP that survives it — agents, prompts, evaluations, runbooks the Skills layer can own once the partner leaves.

The layers constrain each other

Optimizing each layer independently is the most common failure mode. A weak Foundation choice puts a ceiling on what agents can do. An overbuilt Bot layer accumulates debt the Agent layer has to refactor. A starved Skills layer means exceptions pile up and agents never learn from them. Three interactions matter most. The Agent–Bot inversion: build bots first and you get a fast execution layer pointed at the wrong tasks, and redirecting it costs more than building it did. The Skills–Agent feedback loop: agents improve only when their supervisors have time to label exceptions and refine prompts. The Partner–IP transfer: engagements either leave durable IP behind or they create dependency.

Six principles, and where to start

• Build agents before bots; pointing bots at the wrong tasks costs more than waiting a quarter to point them at the right ones.
• Treat Foundation as procurement under uncertainty — short contracts, an evaluation harness owned by the business, and one credible second source rather than whatever your cloud vendor is reselling.
• Staff the Skills layer for judgment, not throughput; the question is not how many people but at what seniority.
• Keep the New-tools layer thin, and resist letting a point tool creep into the agent layer, because that is where lock-in becomes painful.
• Stop customizing the substrate; push customization up into the agent layer, where it is cheaper to change.
• Measure partners by the durable IP they leave behind, not by the engagement itself.

One caution before you add pillars of your own. Balance is not a sourcing mode; it is the act of choosing among them, which is what governance does. Blend is a property of the resulting stack. Bridge names a transition state, and building a permanent framework around a temporary one means redrawing it every two years.

The practical first step is an audit, not a re-org. Take one function, list what you spend across all seven layers, and look at the ratio between agents and bots. Then ask who owns the agent layer by name, at what seniority Skills is staffed, and what durable artifacts your last three partner engagements left behind. Leaders who adopt this view will not necessarily spend more or less in aggregate. They will spend differently, and the difference compounds.