Phase 2: First export

Everything you did in Phase 1 happened on home ground. Your team already thought in pipelines, already trusted a green build, already argued in pull requests. The rest of the company does none of that, and it does not owe you the benefit of the doubt.

This is the phase where AI programs go to die. Not in the lab, in the handoff. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, on cost, unclear value and weak risk controls. Almost none of those failures will be about the model. They will be about a function that was handed engineering's project, in engineering's vocabulary, by someone it never asked for.

The claim of this chapter: the first export succeeds only if it stops looking like engineering's project. One function. One owner who wants it. You co-write the intent. They own it.

What happens

One business function with a willing owner. The CTO co-writes its intent document. The pattern is retold in that function's language, not engineering's.

The gate

Second function at rung 3, with its intent owned and reviewed

What changes for the people doing the work

The first business team learns to write intent. Its best operator becomes the intent owner.

One function, and an owner who wants it

One. Not a wave, not a portfolio, not "support and finance in parallel to save time". You are still the person carrying the pattern, and the timeline rules are plain about why that caps you: one leader can't write intent for two functions in the same stretch. The export is where you teach. You can teach one team at a time.

The owner has to want it. Not agree to it, want it. There is a difference between the leader who volunteers and the leader who gets volunteered because nobody else raised a hand, and you will feel it in the first co-writing session. The volunteer brings the hard cases. The draftee brings reasons it can't work here. Pick the team that actually wants to try is the same rule that kills a pilot committee, applied one level up.

What the owner brings is the thing you don't have. They know which refunds are actually fraud. They know which contract clauses legal will never accept, which vendors always send the wrong PO number, which customers escalate to the CEO. None of that is written down. All of it is exactly what a machine needs before it can do the work without a person translating for it.

Picking the second function

There is no default. The guide will not tell you "start with support" because support was the right answer for someone else. It recommends a function from your own answers at intake, one yes or no question per signal, asked for every function in scope.

The three signals, and why each one earns its place:

• An owner who wants it. The only signal you can't buy, hire or build. Everything else can be fixed with time and money. A reluctant owner cannot, and a reluctant owner will be the one writing the intent.
• Enough volume to matter. The second function is your proof to the rest of the company. A function that processes a dozen items a month can reach rung 3 and nobody will notice. Pick one where the work is heavy enough that moving it off human keyboards changes someone's week.
• Output that can be measured. If nobody can say whether the output was right, nobody can build the evals that get you past rung 3 later, and nobody can show the result. Finance has a ledger to check reconciliations against. Support has resolved tickets and reopened ones. Legal is split: the first independent benchmark found some tools beat lawyers on extraction, while lawyers beat the tools on redlining, 79.7% against 59.4% and 53.6%. Measurable output lives in the first kind of work, not the second.

Watch for the obvious pick that fails the first signal. Support usually has the volume and the measurable output, and its leader is often the least willing person in the building, because they have read the headlines about support teams being cut. Volume and measurability without an owner is a function you will drag. Drag is how Phase 2 stalls.

Your right to overrule

You know things three yes or no questions can't. The willing owner is leaving next quarter. There is an audit landing on finance. The board has a view on sales you have not written down anywhere. Overrule the pick.

But write the reason down. On your report, the overrule goes into your trust log with the reason you gave. It is how you learn whether your gut beats the signals. Later, when the check-ins show how the export actually went, the log tells you which calls you argued with and how they turned out. A CTO who overrules and records the reason gets better at overruling. A CTO who overrules silently just gets to be right in their own memory.

Overrule the pick if you must. Write down why. Your memory is not a trust log.

Co-writing the intent document

In Phase 1 you wrote an intent document alone, for work you understood. Now you write one with someone who understands the work better than you do and has never written one.

Co-writing has an order. The owner holds the pen. You ask the questions an agent would ask if it could: what exactly counts as done, what happens when two rules collide, which way you lean when speed and accuracy pull apart, who decides the case nobody has seen before. Same seven sections as your engineering document: outcome, why now, decided trade-offs, open decisions, revisit triggers, owner, review cadence. The blank starter template is waiting in your takeaways, pre-filled with the owner and cadence from your profile.

The section that will hurt is decided trade-offs. Most functions run on a sentence like "we care about customer experience and cost discipline", which lets two camps who disagree both feel represented. Strategic ambiguity is load-bearing. It holds a coalition together. Writing the trade-off down means someone loses an argument they have been avoiding on purpose. For a refunds workflow it looks like: "Below the policy threshold, we would rather issue a credit we didn't owe than make a customer wait for a person." That sentence costs something. That is how you know it is a decision.

Expect the open decisions list to be longer than the owner wants. Good. Each item gets a name and a date, instead of whoever hits the gap first quietly inventing policy. And set the revisit triggers in the function's own terms: a change in refund policy, a new payment provider, a reopen rate past a number the owner picks.

Then stop. You co-write it. You do not own it. If your name ends up in the owner field, the export failed, and you have bought yourself a second function to run alongside your own.

Retell it in their language

Engineering's words are a tax on everyone else. Nobody in finance should have to learn what an eval is to get the benefit of one. Retell the pattern in the function's own terms:

• An eval is the pile of cases we already know the right answer to.
• A sandbox is what the machine is allowed to touch, and what it isn't.
• Rung 3 means the machine drafts every one and a person signs it off.
• An escalation is the case the written rules don't cover, and it goes to a person by name.
• Drift is the day the document stopped matching how we actually work.

Do not send engineering's deck. Do not send an engineer to run it for them. Both say the same thing: this belongs to engineering and you are borrowing it. Engineering's job is plumbing: the sandbox, the pipeline, the connection to the tools the function already uses. The work, the intent and the calls belong to the function.

Put the time in person. In the same BCG survey cited in the ladder, only 25% of frontline workers said leaders give them enough AI guidance, and the training that turned people into regular users worked best coached and in person. The first business team is watching whether you mean it. Showing up is how they find out.

The gate

Second function at rung 3, with its intent owned and reviewed. Three conditions, and all three have to be true on the same day.

At rung 3. Every core workflow on that function's list, not the favorite one. A function sits at the rung of its weakest workflow. If support's triage runs through the pipeline and refunds still get done by hand, support is at rung 1 on that scorecard, however good the triage demo looks.

Owned. One person's name in the owner field. Not "the support team", not "Finance Ops". A team is not an owner, and a name nobody can produce is the first thing Constraint Court will ask for.

Reviewed. Written is not reviewed. The document has been reopened on its cadence, by its owner, and either confirmed or changed. Until then it is a draft that nobody has tested against a month of real work.

Pass all three and the pattern has left engineering and survived. That is what earns Phase 3, where the rest of the functions move in waves and the rulings you collected along the way become the playbook.

What changes for the people doing the work

The first business team learns to write intent. That is a new skill for them and it will feel like homework at first. It is the job they are moving into.

The intent owner should be the function's best operator. Not the manager by default, and not the person with the most free time. The operator who knows where the bodies are buried is the one whose judgment the machine needs written down. Hamel Husain and Shreya Shankar recommend appointing a single domain expert as the arbiter of quality for exactly this reason: quality needs one person's judgment, not a committee's average.

Say what the role is, out loud and in writing. The best operator is not automating their own job away. They are moving from doing the work to deciding how the work gets done, and handling the cases nobody wrote down. That is a promotion in everything but title, so consider giving them the title.

Then say what has not been decided. The headcount conversation belongs to Phase 3, held in the open, function by function. The team knows the question exists. Pretending it doesn't only invites the worst explanation on offer.

The export works when the function stops calling it engineering's project.