A Blueprint for AI-Native Enterprise Delivery

By Andrew Duncan (Vertice Labs) and Robert Fiore (The Hive Group AI).

You've felt this. The idea is clear in your head. You bring it to your technology team. Six months later, you have something that kind of approximates what you meant, at twice the budget, with half the functionality that mattered. The team is frustrated. You're frustrated. And you already have a new idea that you're afraid to bring up.

This is not a technology problem.

Most executives assume the gap between vision and software is a technical one. Wrong tools, wrong vendor, not enough AI. So they buy more tools. They add AI to the stack. They hire a new CTO. The gap persists.

The problem is structural. Your delivery model was built for a constraint that no longer exists. Everything about how you staff software delivery, sequence the work, manage progress, and measure success was designed for a world where engineering was slow and expensive. That world ended.

This is what we've been watching happen in live engagements, and what we're both building toward in our respective practices. We wrote this to give you the blueprint that nobody else has handed you yet.

What AI Actually Changed (It's Not What You Think)

There's a principle in design: artists don't sketch in marble.

You don't start with the most expensive, most specific medium. You use cheap tools to narrow the problem space. Napkin sketches, wireframes, mockups, prototypes. Each step more expensive and more precise than the last. Then, when you're confident you know what you're building, you commit to the expensive thing.

For software, code was the marble. The most expensive, most specific, hardest-to-change medium in the process. Your entire delivery infrastructure was built around this fact. The business analysis, the requirements documentation, the sprint planning, the product backlogs, the project managers who managed it all. That apparatus existed to protect scarce code from being wasted on the wrong thing.

Now code is practically free.

A staff-level engineer working with AI agents can produce in one week what a traditional team produced in four months. We've seen this firsthand. Timelines quoted at four months delivered as working functionality in a week. Not because something magical happened. Because the code itself stopped being the hard part.

When you can sketch in marble, everything built to prevent marble-sketching becomes overhead.

• The PM org exists to manage scarce engineering capacity. Now it adds latency.
• Sprint ceremonies exist to sequence slow delivery. Now they're friction.
• The backlog exists to prioritize a long wait. Now it slows alignment.
• Phase-gated delivery exists to control expensive sequential work. Now it impedes flow.

The constraint didn't disappear. It moved. Engineering execution used to be the scarce resource. Now the scarce resources are:

Domain knowledge. Who actually understands the business process deeply enough to build software that reflects it.

Decision speed. Who can clear ambiguity fast enough to keep pace with a build that can move in days, not months.

Context fidelity. Whether everyone involved in building shares a complete, current understanding of what the software is supposed to do and why.

Your board is right that AI changes everything. But the change isn't copilots in the IDE or AI in the customer chatbot. The change is that your most expensive medium is now essentially free, and your entire delivery model is still organized around protecting something that no longer needs protecting.

Why the Gap Persists Even When Everyone Is Doing Their Job

Before we get to the new model, it's worth being precise about why the old model fails. The people in those roles are usually competent. The failure isn't about individuals. It's structural.

The traditional delivery chain looks like this: business stakeholder → business analyst → product manager or product owner → development team → build.

Every handoff in that chain is a translation. Every translation loses fidelity.

The business stakeholder knows what they need but can't always articulate it in the language of software requirements. The BA captures what they can: the explicit requests, the stated workflows. But they inevitably miss the exceptions, the edge cases, the institutional knowledge that lives in people's heads and never gets written down. The PM sequences and tracks what the BA handed off. The dev team builds what the PM scoped. By the time intent becomes software, the signal is degraded at every step.

Here's the thing that makes this structural rather than fixable: the people who understand the business process best are at the start of the chain. The people who build the software are at the end. The distance between them is the gap you feel.

The tribal knowledge problem is universal. In every operations engagement we've run, leadership has a high-level understanding of the operation. The department leads who actually run the process have a completely different, granular picture. The exceptions, the workarounds, the decisions nobody ever documented, the places where the official process and the real process diverged years ago and everyone just adapted. That knowledge isn't in a system. It lives in the heads of the people doing the work.

The BA tried to surface it. The BA couldn't. Not because they were bad at their job. Because the interview process and the requirements document are inadequate tools for capturing the kind of operational knowledge that actually makes software useful.

None of this is anyone's fault. The chain was built for slow, expensive engineering. It was a reasonable approach to a real problem. That problem has changed.

The Lifecycle Hasn't Inverted. It's Collapsed.

Here is the standard narrative about what AI did to software delivery: the process inverted. Instead of design leading engineering, engineering now leads design. Build first, figure it out later.

This isn't quite right, and the imprecision matters.

The process didn't invert. It collapsed into one.

When code was the most expensive medium, phases existed to protect it. You used cheap phases (discovery, design, prototyping) to narrow the solution space before committing to expensive code. Each phase was a gate: don't proceed until this phase is complete. Don't sketch in marble until you know what you're building.

When code is free, the rationale for the gates disappears. But something more interesting happens than just removing the gates. You can now solve valuable (does it matter to the business?), usable (can people actually use it?), and feasible (can it be built?) simultaneously, in a single motion, in conversation with a working system, rather than sequentially through a chain of approvals.

In practice: one of our engagements had a client who expected a four-month timeline. We delivered working functionality in a week. The timeline wasn't slow because the code was hard. It was slow because the client's mental model of delivery was still phase-gated. They expected design to complete before build started, business requirements to stabilize before the first commit. When we handed them a working system in week one, the conversation immediately became richer: this is right, that's wrong, we didn't know we'd want this until we saw it, we thought we needed that feature but we don't. Understanding didn't precede development. It emerged from it.

This is what it means for the lifecycle to collapse: the tools that used to be separate (napkin sketch, wireframe, mockup, prototype, build) merge into a single continuous act of discovery and refinement. The marble is cheap. Sketch in it. Refine it. You'll learn faster than you would from a requirements document.

This changes what alignment means in a delivery process.

In the waterfall model, alignment was achieved through documentation. Sign off on the requirements, agree on the spec, freeze the scope. In agile, alignment was achieved through ceremony. Standups, retrospectives, sprint reviews, the ritual of getting the team in the same room.

In an AI-native delivery model, neither works. The work moves too fast for documentation to keep up. Ceremonies are overhead when you're shipping continuously. Alignment has to be continuous, baked into how work is captured and shared as it happens, not achieved through scheduled checkpoints.

The framework for this is Context Engineering: the continuous capture of the what, why, and how of work. Not a task list. Not a backlog. A living record of meaning. What the system is supposed to do, why each decision was made, what was learned, what changed. Every contributor can operate from it. When the person who built the authentication module goes on vacation, the next engineer shouldn't need a meeting to understand the intent. It should be in the context.

This also addresses a legitimate concern about any model that concentrates domain knowledge in a small team: what happens when someone leaves? In a traditional delivery model, that's a real risk. Knowledge walks out the door. In an AI-native delivery model, knowledge capture is inherent to how the work happens. Every conversation, every decision, every design choice is stored and accessible. The context doesn't live in someone's head. It lives in the system.

The vocabulary of the old lifecycle has to change too, because the old terms describe the old constraints. Sprint velocity measures how much code moved, not whether it solved the right problem. Story points abstract away the real constraint, which in an AI-native model is cognitive energy, not engineering hours. Roadmaps organize work around delivery dates, not business outcomes.

The framework replaces these with more precise instruments: Outcome Maps instead of roadmaps (organized around impact, not dates), Energy Allocation instead of release planning (distributing cognitive effort rather than scheduling capacity), Flow Design instead of sprint planning (balancing intensity with recovery). These aren't rebrands. They measure different things because the constraint is different.

The New Team

When you can sketch in marble, you don't need an intermediary between the person sketching and the person who will use it.

Think about why the BA → PM → PO chain exists. It exists because code was expensive and rare, and you needed people who could translate between the people who understood the business and the people who could write software. You couldn't put a domain expert in a room with an engineer and have them produce working software together. The engineer couldn't move fast enough, the domain expert couldn't stay engaged through eighteen months of a project. So you built an intermediary layer to manage the translation.

When engineering is fast and AI-augmented, that layer is no longer translating anything. It's adding latency to a process that doesn't need it.

The delivery team we've arrived at through practice is three roles:

A staff AI-native engineer. Full-stack, senior, AI-augmented. This person's job is to stay in execution mode, producing working systems, not attending strategy meetings. They don't get pulled into product definition or stakeholder management. They build. The speed at which they can move is only useful if they stay focused.

A domain expert from the business. The department lead or operational team member who actually runs the process being built for. Not IT. Not a proxy for the business. The person whose operational knowledge is the primary input to everything being built. This is the person who knows the exceptions, the workarounds, the real workflow versus the documented one. Their involvement isn't governance. It's the source of the most valuable information in the process.

A new role that doesn't have a clean name yet. This is the most important thing we're trying to articulate in this piece, because this role is what everyone building AI-native software needs and almost nobody has properly staffed.

This person understands the domain as well as the client does. The process end to end, the inputs and outputs, the decision points, the edge cases, who to talk to for what they don't know, and what questions to ask. They translate that understanding into jobs-to-be-done, product capabilities, and solution direction. They research APIs and integrations. They produce prototypes and design artifacts quickly, AI-augmented, so one person can do what used to require a team. They remove ambiguity for the engineer so the engineer can stay in execution mode.

The closest analogy: a staff engineer can do frontend, backend, infrastructure, and architecture at a senior level. The whole engineering stack, in one person. This role is the equivalent in the non-engineering dimension. Domain analysis, product strategy, capability research, rapid prototyping, design. The whole non-engineering stack, in one person. Equally rare. Equally valuable. Not yet well-named.

The role isn't new as a concept. People have been doing it informally for decades. The technically fluent person who left their desk and embedded with the operations team. The BA who actually understood the domain instead of just documenting it. The product person who could speak both languages fluently. What's new is that AI has made this role essential everywhere, not just at organizations lucky enough to have an unusually capable individual willing to operate outside their lane. When the build can move this fast, every delivery team needs this person. Most don't have one.

We're watching this pattern emerge across industries. Legal, finance, logistics. Each one is independently arriving at the same conclusion: the bottleneck isn't technology, it's the absence of people who can translate capability into practice. Some are calling them "forward-deployed" specialists, embedded with the business, not sitting in a central function. The name will professionalize over the next few years the same way "social media manager" went from an informal add-on to a recognized career track. The role exists. The title doesn't yet.

This is not the old product owner. The product owner was a methodology role. Managing the backlog, running the sprint, coordinating the team. This role has no methodology to manage. The work is: understand the domain deeply enough to guide the build, and maintain the context that keeps the engineer moving in the right direction.

It's not a BA. The BA was upstream, gathering requirements before the build started, working in documents and process maps, not in working software. This role operates alongside the build, in real time, in conversation with a system that exists and can be changed.

What's gone from the traditional team:

The agile project manager is gone. Not compressed, not transformed. Gone. In a team that ships continuously, there is no project to manage, no Gantt chart to update, no status report to write. The work is visible in the system.

The product owner managing a backlog is gone. The backlog was a queue for slow engineering. When engineering is fast, the queue disappears. Prioritization happens in the six-week discovery cadence, not through a rolling backlog ritual.

The BA capturing requirements upstream is gone. Requirements don't precede the build; they emerge from it. What replaced the BA is split: the domain expert (on the business side, providing operational knowledge) and the new role (on the delivery side, translating that knowledge into what to build).

Where delivery connects:

In the old model, delivery was owned by IT. The business submitted requests. IT estimated, prioritized, and delivered. The business received, usually twelve months later, usually not quite right.

In the new model, delivery is connected directly to the operational team it serves. The department lead who runs a process has a delivery nucleus as a direct counterpart. They work together. They deploy into the real process. They validate in production, not in a UAT environment that doesn't reflect how anyone actually works.

The adoption problem, which is usually framed as a launch risk to manage, disappears in this model. Adoption fails when it requires behavior change that people weren't part of designing. Involve the person whose behavior needs to change in building the thing that changes it, and the resistance doesn't materialize. Add working software in their hands within weeks, not months, and the adoption curve flattens on its own. The team that built it is the team that uses it. Adoption isn't a lagging metric. It's built in from day one.

How It Actually Runs

Two parallel tracks. Not sprints, not quarterly roadmaps.

Track one: The six-week discovery.

The first half is process mapping. Map the operation at the floor level, with the people who actually do the work. Not the org chart version, the real version. Front-stage and back-stage: what customers see, what the team does behind it, where the handoffs are, where work piles up, where decisions are made and by whom, what's documented versus what's tribal knowledge.

Surface what leadership can't see. In every engagement we've run, the gap between what leadership believes their operation looks like and what the department leads know it actually looks like is significant. The exceptions, the workarounds, the informal processes that developed because the official process doesn't fit reality. These are invisible from the top and essential to building software that actually gets used. Find the real constraint. The bottleneck is almost never where leadership assumes it is. Usually it's buried two or three levels down.

The second half is solutioning. Once the operation is mapped and the constraints are visible, the nucleus begins shaping what to build and how to build it. This includes a recommendation on the integration point. Where the new system connects to the existing operational platform, where the seam is, what legacy modifications are necessary to support it. If there's an internal engineering team, the technical discovery conversations happen here, before delivery starts. By the time the six weeks are done, the architectural direction is agreed on and the delivery team has a clear mandate. The roadmap isn't a schedule. It's a ranked investment thesis: here's the highest-value thing to build, here's why, here's what good looks like if we get it right.

Track two: The eight-week bet.

Take the top priority from the discovery. Before the first line of code, define what "good" looks like, specifically enough that you'll know when you've hit it. Then build the whole thing. Not a phase of it. Not an MVP scoped down to the point where it won't actually change how anyone works. Build what was defined, deploy it into the real process, and validate it with the people who do the work daily. Eight weeks is the right window: long enough to build and deploy something real, short enough to stay connected to the original hypothesis and course-correct if it shifts.

The discipline this requires is scope integrity. The discovery defined the bet. The build honors it. When new ideas surface during the build, and they will, they go into the next discovery cycle, not into the current bet.

The parallel structure:

While the eight-week bet is running, the next six-week discovery starts on the adjacent priority. You don't wait for the build to finish before understanding what comes next. You're always discovering one step ahead of where you're building.

At scale, this looks like multiple pods running in parallel. Each pod one nucleus, each nucleus one slice of the operation. One pod is automating the intake process. Another is building the reporting layer. A third is mapping the onboarding workflow to understand what to build next. The organization is continuously discovering, building, and deploying in interlocking cycles, with progress that is visible, testable, and deployed into real operations. Not tracked in a project management tool.

The Transition: What Actually Starting Looks Like

The first move is not restructuring the org.

Most executives who read something like this immediately think about the organizational change. The new roles to define, the old roles to eliminate, the IT politics to navigate, the change management program to plan. That's the right destination but the wrong starting point. You can't restructure around a model you haven't tested.

The first move is one discovery engagement.

Pick a process. The most painful, visible operational bottleneck you have. The one that you already know is broken, that your team complains about, that your customers feel. Staff the nucleus: one senior AI-native engineer, one domain expert from that operational team, and a delivery-side lead who can bridge them. Run the six-week discovery. Let the roadmap tell you what to build first.

You'll learn more about your own operation in six weeks than most discovery processes surface in six months. And you'll have a clear, ranked picture of where AI can create the most leverage, built from the actual data of your actual process, not a benchmarking study or a vendor's pitch deck.

What to expect on the IT side:

This model doesn't require IT's blessing to start. It requires one operational leader willing to be the domain expert and one executive sponsor who believes the current model isn't working. If you have those two things, you can run a discovery engagement alongside your existing IT processes without displacing them.

The conversation with IT gets easier after the first bet lands. When you can point to a working system that deployed in eight weeks, is being used by the team it was built for, and eliminated a process that previously took three people two days per week, the conversation changes.

Common friction:

"We have a process for this." You do. It was designed for slow engineering. Running this model doesn't mean abandoning your existing IT processes for everything. It means creating a parallel track for the things that matter most, with a team that can move at the speed those things deserve.

"Our PMs won't like this." Correct. Some PMs have the instincts to move toward the new role. They're curious about the domain, they think in outcomes, they're comfortable operating without the structure of a sprint ceremony. Those people are valuable. Most PMs were trained to manage a process, not to own a domain. The distinction matters.

"The business team doesn't have time." This is the real constraint, and it's solvable. You don't need forty hours a week from a department lead. You need focused availability. The right person available for concentrated working sessions, able to make decisions in real time rather than through a committee. A department lead spending four focused hours a week with a delivery nucleus outperforms twelve months of BA interview sessions.

"IT needs to approve all software." This is a real constraint with a real answer. Get executive sponsorship for the engagement before it starts. Frame it as a pilot, not a shadow IT initiative. When the pilot works, you have the proof point to have the structural conversation.

A note on legacy systems:

Most organizations running at scale have a real concern we haven't addressed yet: the existing operational platforms aren't going anywhere. You can't disrupt a $50M business to rebuild its infrastructure from scratch.

The pattern we've landed on is carve, automate, integrate back. You don't rebuild the legacy system. You identify the specific slice of the process that can be automated, architect a clean solution for that slice alone, and feed its decisions back into the existing operational platform. The legacy system continues running the business. The new system owns one carved-out process. They connect at the output layer.

This works because you're not absorbing the technical debt. You're routing around it. The clean solution stays clean. The legacy platform stays stable. The integration point is a seam, not a merge.

One friction point worth naming: internal engineering teams often push back on this pattern, and not without reason. They're responsible for the stability of the platform you're integrating with. Their skepticism is worth taking seriously. What we've found is that the answer isn't to override them. It's to pull them into the architectural conversation during the discovery phase, before delivery starts.

The back half of the six-week discovery is where solutioning begins. That includes a recommendation on the seam: where the new system connects to the existing platform, what the integration point looks like, what modifications to the legacy system are necessary. That's when the technical discovery conversations with the internal engineering team happen. By the time the eight-week bet starts, the architectural direction is agreed on. Some legacy modifications will be necessary, and the internal team needs to be part of deciding what those are. Involving their product manager and operational lead in testing keeps disruption off the table and turns hesitation into ownership.

The First Move

If you recognized something in what we described (the gap, the frustration, the tribal knowledge that never makes it into your software, the PM layer that adds more process than value), you don't need to wait for an organizational transformation to start.

One six-week discovery engagement.

Pick the most painful, visible operational bottleneck you have. Bring in the right team. Let the process surface what you can't see from the top. At the end of six weeks, you'll have a complete picture of one slice of your operation and a ranked roadmap of what to build to create the most leverage.

Then you'll know whether this model works for your organization.

That's the bet worth making first.

Appendix: The Shift at a Glance

The lifecycle:

The team:

The cadence:

Andrew Duncan is the CEO of Vertice Labs, an AI-native software engineering firm. Robert Fiore is the founder of The Hive Group AI. Both are running the model described in this paper in active client engagements.