What is this field guide, and why might it help?
Bring this into the room. You can read this field guide in order or start with the question your team is facing. The guide below points you to relevant sections. "Two Ways to Read This," at the end of the book, explains how to use the companion agent alongside the text.
If you are reading this, you are probably somewhere in the work of becoming an AI-Native company. Maybe your CEO put the phrase on a whiteboard and you have been trying to figure out what it actually means. Maybe you have already spent eighteen months and a lot of money on AI pilots that have not produced what was promised. Maybe you are at the start, trying to decide whether to commit, and looking for something solid that does not feel like a sales pitch.
This is that.
I wrote it because almost everything I have read on AI-Native is either too high to act on or too narrow to be useful. The strategy decks describe the destination without the path. The implementation playbooks describe the path without the destination. The vendor white papers describe whichever piece the vendor sells.
This book is different. It holds the strategic, the human, the technical, and the operational in the same frame. It names the trade-offs.
It is also a design guide. A pattern I see often: leadership teams treat the AI-Native transition as something to go do. They pilot, they test, they implement, they call it fast failing when the pilots do not produce. If design happens at all, it happens after the first wave of failures has consumed the budget. I think this is the wrong sequence. Designing an AI-Native company is design work. Naming the considerations, weighing the trade-offs, choosing the path. The work belongs at the front of the transition.
The pushback I get on this is real and worth engaging. Design is expensive, slow, and what consultants do when they want to bill more hours. The companies that win are the ones that move fast, ship something, learn from the market, and iterate. Spending six months on design is six months your competitor spent shipping. I have heard versions of this from every leadership team I have worked with, and the people making the argument are not foolish. They are responding, often correctly, to a pattern of over-designed enterprise initiatives that produced a lot of slides and not much else. The argument has a real grievance behind it.
I think the argument was right and is becoming wrong. It was right because design, until recently, was expensive and slow. A single design option for a major operating-model change used to take a small team weeks to produce. Interviews, framing documents, scenarios, financial models, the rest of it. Multiple options took multiple weeks each. The economics rewarded teams that limited their design work, made one bet, and tried to execute it fast.
I watched this up close on ERP implementations. On the SAP and Oracle programs I worked on, armies of people were deployed for months to understand what was happening at the client, map the current state, and then build the crosswalk to what the process would look like in the new system. Highly manual, and expensive. Most of the labor went into managing documents and inputs and trying to rationalize them against each other, working out interdependencies, tracing how different processes touched the same data. That was the real cost of design, and almost none of it was the thinking.
The design work remains, but AI has compressed enough of the labor around it to change what a team can afford to consider. I have found the same thing building the Nodalix application. I am not spending more hours on design than I used to spend. I am exploring more options per hour, pressure-testing them faster, and catching mistakes that would have shipped in the pre-AI version of my practice. Working in Claude Code within a configured codebase, the system can inspect the code that is available to it, so the design does not start from a blank page. I describe what I want to build and it helps me work out the appropriate path to take. Work that used to take a six-person consulting team is now within reach of one capable person to attempt, though domain review and collaboration still matter. That changes what a leadership team can afford to consider before they commit. The companies that recognize this change have a window of advantage. The companies that stick with the old economics of design, either by skipping it or by paying consultants for it the old way, are leaving that advantage on the table.
So my response to the pushback is this. The old preference for shipping over designing was a reasonable response to the old economics. The new economics are different. Design done well, with AI as a thought partner, is faster than it was. Shipping into the AI-Native transition without designing first is more dangerous than it used to be, because the stakes are operational, financial, and human at the same time.
This field guide is organized the way a football coach uses a playbook. A playbook is a menu of plays. No coach runs it start to finish. The right play for third-and-long is not the right play for the goal line. A coach reads the situation, finds the play that fits, runs it, and adjusts. The plays are the substrate. The judgment is the work.
This book works the same way. The ten stages and forty-three sections are plays. The frameworks inside are options to choose between based on where your company is and what you are trying to do. You do not need to read it front to back. You can find the section that matches what you are working on right now and start there. Come back to other sections when the work surfaces them.
A field guide is meant to be marked up. The marginalia and the dog-ears are the point.
You can work with this on your own. Many leadership teams will. You can also call me and Nodalix, and we will help. The book is yours to use either way.
A word about where all of this comes from, because two different things are braided together in it and you should be able to tell them apart. The AI thinking is recent and it is mine by way of building. Since I began building Nodalix, I have been constructing an AI-Native company rather than advising one, and almost everything I claim about what AI does to work comes from that, plus what I can see happening in the market, plus the research where the research is good. AI is new enough that nobody has a decade of AI-Native transitions behind them, and I will not pretend otherwise.
The methodology is the older half. Two decades of designing and facilitating collaborative sessions for senior teams, across industries and across every kind of hard decision a company faces. That work is older than AI. It is about how a room full of people reaches a decision they will actually carry out.
The bet this field guide makes is that those two things belong together. Becoming AI-Native is a design problem that a leadership team has to work through collaboratively, so I am offering the thinking on one side and the method for exploring it on the other. When I describe what I have seen companies do with AI, I mean what I observe in the market and the research. When I describe how a room works, I mean twenty years of standing in them.
Where I am uncertain, I will say so.
One last note before we begin.
Becoming AI-Native means designing the organization so AI helps people do worthwhile work and serves the people affected by that work. That purpose governs the choices about technology, roles, authority, and investment. People whose work changes need a meaningful part in those decisions. Throughout this field guide, we will examine what each design asks of people, what it gives them, and whether the company can sustain it.
Which Play Do You Need Right Now?
This section promised you a field guide: a menu of plays. The router below is how you call the play. Find the line that sounds most like what is happening in your company, in your own words, and start with the sections listed, in order.
Come back when the situation changes. It will.
"The CEO announced we're becoming AI-Native and everyone heard something different." Start with Sections 1.2, 9.2, and 2.1. Name the ambiguity, use the sprint to build a working definition without erasing dissent, and ground it in an honest account of your current posture.
"We have eleven pilots and nothing in production." Start with Sections 8.2 (Case One), 1.2, and 2.4. The pilot graveyard can begin with unresolved meaning, ownership, evidence, or architecture; the developmental model helps locate what remains missing.
"Our pilots keep stalling and we can't tell why." Start with Sections 7.1, 8.2, and 3.2. Map the feedback structure rather than diagnosing it from frustration alone; compare the failure patterns, then inspect the operating system beneath the pilots.
"The board is asking what we're spending and what we're getting." Start with Sections 4.5 and 2.4. Separate spending that rents capability from spending that builds it, then examine why the strongest performance association in the cited research appears between its middle maturity stages.
"We don't know what to measure." Start with Sections 7.3, 7.1, and 7.2. Build an instrument panel that tests the transition without turning workers into surveillance targets, then connect the signals to feedback structures and competing causal explanations.
"People are scared." Start with Sections 5.2, 6.1, and 1.3. Make room for the emotions without assigning them, establish practices that protect candor, and confront the human premise underneath the transition.
"Everyone has Copilot and nothing is compounding." Start with Sections 4.3 and 2.3. You have the thirty-islands architecture; audit which of the nine layers you have actually invested in.
"Our most experienced people are going quiet, or leaving." Start with Sections 5.2, 7.1, and 8.2 (Case Five). Treat nonparticipation as information about fear, extraction, workload, privacy, or professional duty; the covenant and the failure case show what must change.
"We're about to announce a restructure." Start with Sections 8.2 (Case Four), 6.2, and 5.10. Do the design work before the announcement: map the moments that concentrate value and the invisible work each layer is doing.
"We handed the AI strategy to the CTO." Start with Sections 8.2 (Case Two), 4.2, and 5.1. Technical leadership is necessary and insufficient on its own; the five-part mandate shows where leadership accountability and cross-functional ownership belong.
"Our people are using AI tools we never approved." Start with Sections 4.3, 8.2 (Case Three), and 4.4. Prohibition alone is brittle. Pair useful sanctioned tools with proportionate controls, enforcement, and the epistemic disciplines the work requires.
"We can't tell whether the AI's output is true." Start with Sections 4.4 and 3.3. Corroboration, monitoring, and verification are the disciplines; the validate step of the work loop is where they live day to day.
"Our AI gives generic answers. It doesn't know our company." Start with Sections 4.1 and 2.3. Documents carry narrative and evidence; graphs expose named structure and relationships. Strong systems use both as context for reasoning.
"The leadership team doesn't actually use AI themselves." Start with Sections 5.1 and 5.6. The four stages and four obstacles locate the leader's practice; the work-design test asks whether the resulting environment supports challenge, agency, and care.
"Our people are getting faster but the work is getting shallower." Start with Sections 5.4, 5.5, and 6.1. Distinguish useful cognitive offloading from loss of required capability, then design the foundations, feedback, and team practices that support development.
"Junior people aren't learning the trade anymore." Start with Sections 5.10, 5.5, and 3.2. The apprenticeship inversion is a risk you can design around: redesign formative work so people still build judgment while learning to direct and check AI.
"Our managers are checked out, and AI is making it worse." Start with Sections 5.6 and 5.9. AI can give a distracted manager a plausible excuse for more distance. Engagement architecture and deliberate unlearning put attention back on the conditions people need.
"Our people feel like the work doesn't need them anymore." Start with Sections 5.8, 5.2, and 6.5. Name what the change takes away, give people a hand in redesigning their own roles, and move recognition to the part of the work only a person supplies.
"We don't know where humans should stay in the loop." Start with Sections 6.2 and 5.3. Place accountable human presence at the moments where rights, consequence, relationship, lived context, or professional responsibility make it matter.
"Our decks and reports look dated next to what others are producing." Start with Sections 6.4 and 3.3. Output, communication, and knowledge sharing are all shifting; set the standard deliberately, then make specification, validation, and learning part of the pathway.
"We ran the workshop, the energy faded, nothing changed." Start with Sections 7.2, 7.1, and 9.3. Test where the intervention met the system, identify the feedback structures carrying or resisting it, and establish the ownership and review rhythms that continue after the room closes.