The claim of this piece: in an AI project that actually runs, step one is not bringing AI in the door — it's taking AI down off the lead role. Where the same need lands on the technical map decides the budget and the acceptance test; those are two different ledgers. What the kickoff meeting is missing is not a list of model capabilities. It's a translation layer — something that turns "what we want" into "which slot we act in, and what we accept against."
What this piece solves: at every AI kickoff, the business side can say "I want the shelves to never go empty," and the technical side can answer "is the model any good" — but the sentence in between, which slot does this work actually belong in, and what do we accept against, goes unanswered. Three live deployments take that sentence apart: a map for placing the work, three questions you can ask in the meeting itself, and the boundaries where the questioning fails.
Scope: the three cases come from the first 24 cases of Datawhale's FDE Case 100, published September 2026 — interview compilations from a single editorial project, not 24 controlled experiments. Every claimed effect below stops at the case author's own account. The "technical tiers" and the "three placement questions" are the framework we built while reading across the cases — no case company describes itself this way, and no client verified any of it. This piece answers once a need is found, where does it land. It does not answer what loss you should look for in the first place — that's the earlier half of the trip, linked at the end.
Three Sites, One Anomaly
A cross-border e-commerce team of roughly a dozen people came to a case author with a need stated in a single line: could he hook their inventory SaaS up to Feishu (NO-22 L21-22)? Taken literally, that's an API integration job. And yet the most counter-intuitive line in the finished solution was this: the client's own restocking formula stayed, untouched — "we did not reinvent an inventory algorithm" (NO-22 L49).
The second site is stranger. In a consumer-goods company's packaging-review project, the thing the model is supposedly best at — arithmetic — was exactly the thing taken away from it: the NRV calculation was hardened into deterministic code, "letting the model do only explanation and data-entry suggestions" (NO-19 L133-134).
Only the third site actually lets AI write. A Douyin local-life agency's short-video copy line is the only one of the three that gave generation the home field. And the backdrop before the outside team arrived: the client had already tried letting AI write directly — including a locally deployed DeepSeek — and it failed (NO-15 L66).
Three sites, side by side, one anomaly: in AI projects that actually run, step one is taking AI down off the lead role.
First, the grade of the evidence. All three cases come from the first 24 of FDE Case 100, published the month before this piece — the product of one interview-editing project, not 24 controlled experiments, so every effect below can only be stated as far as "the case author says so." But precisely because these are small stories told in interviews, the things that usually stay hidden are exposed: where the money went, who decided, and who eats the loss when something breaks.
Money in the wrong slot is not an outlier, either. In August 2025, Fortune relayed an MIT report: by the report's own framing, only about 5% of corporate GenAI pilots achieved rapid revenue, and the rest showed no measurable impact on the P&L. Meanwhile, more than half of GenAI budgets went to sales and marketing, while the report argued the biggest returns sat in back-office automation. The money got spent. It just got spent in the wrong place.
A Restocking Formula, Untouched
Start with the client's situation. A team of a dozen or so people, selling into Southeast Asia, apparel as the main line (NO-22 L16). In apparel, every color of every size is its own SKU, so the count balloons: by the interview's own estimate, 500 to 800 new SKUs a quarter, roughly 2,500 to 3,000 a year — in the case author's words, "already a lot" for a 10-to-15-person team (NO-22 L17-19).
The tools were never the problem. An aggregated inventory SaaS, Feishu, Excel, plus the Google and TikTok ad consoles — all of it running. What was exhausted was the person shuttling data between them (L43-44). The factory ships with photos, so staff read photos by eye, key in the data, and chase tracking numbers (L27-29). Restocking meant scraping the SaaS, pasting into a spreadsheet, running the house formula, transcribing the result into another template, generating a PDF, sending it to the supplier (L30-32). Ads ran on yet another platform, burning budget while the stock behind them ran dry (L33-34). Each task looks light on its own. Chained together, a whole day dies inside "look, copy, fill, verify" (L55-56).
The case author's key move on arrival was not to replace any of this. It was to concede it first: the staff read each SKU's last three months of sales and apply their own forecasting logic to compute the restock — "the logic holds. The problem is that it's buried in a process that needs a human hauling data back and forth" (L47-48). So the first cut landed on the pipe, not the brain: "the client's original restocking logic can stay. Our job is only to hand the mechanical, repetitive, cross-system motions to the machine" (L49-50).
Four steps followed, and every step had a human standing guard.
Step one fixed the data. The SaaS's API openness was poor (L74), and its key mechanism made things worse — keys expire, and one key cannot serve multiple teams at once (L153-155). The fix was a middle layer: an open-source cloud database, Supabase, where data lands first and then syncs into Feishu (L74-76). The author later compressed this class of wall into one sentence: "The AI may already be able to do the task, but the data can't be pulled out at all — so it still never lands" (L157-159).
Step two put an agent on logistics photos — recognizing and back-filling the data — with humans doing only the final check (L86-87).
Step three went back to that formula. The agent computes by the original restocking rules, screens out the SKUs that need restocking, projects a restock cycle and quantity, and the PDF order is generated only after a human review — "the human role shifted from 'calculator' to 'reviewer'" (L92-94).
Step four was never in the original scope at all. Once the data flowed, "the client grew the next layer of need on their own" (L98): inventory started steering advertising. When a SKU's stock falls past a threshold, the system dials its ads down — or pauses them (L101-102). The step the author values most, in his own words: the business "started moving from single-point automation toward linkage between processes" (L126-127).
The results are only half a story. The time savings are self-reported by the people who ran the work: logistics-photo handling fell from about 4–5 hours per person per day to under 1 hour, and restocking went from at least 2–3 hours to mostly a glance and a verification (L116-120). There are no system logs and no comparison ledger behind those numbers, and nothing in this piece converts them into a money figure. The harder boundary came after: once the delivery ended, "the client removed our team's access — we never got the full downstream numbers on revenue, ad cost, and profit" (L114-115). The author himself flags it: "this case's effect tracking has gaps" (L128). At the end of the interview he leaves one more line: "after delivery, effect attribution is also part of the FDE's work" (L212). The expansion of that line opens the next case's transcript (printed p. 227, NO-23 L4-15), and its first sentence is: "the biggest regret of this case is that after we delivered, we never tracked the downstream effects in full" (NO-23 L4). He adds that if he ran the project again, he would "design an 'effect baseline' up front" (L11) — quantifiable metrics, agreed before launch, for restocking, ads, and orders (L12-13). The mechanism got built. The accounting never got finished — and the author knows the accounting never got finished. That is where the project stops.
Read this case correctly and AI's position becomes obvious: it doesn't do clever here. It does hauling and execution. The formula wasn't wrong. What was wrong is that the formula was buried in a manual data-hauling process — this is not a model problem, it's a plumbing problem.
The Model Was Explicitly Forbidden to Do Math
The second company's ledger opens on a deliberately vague line: "in a year we may do 100-plus SKUs" (NO-19 L24 — the source's own fuzzy framing, quoted as-is). One product runs from requirements and flavor R&D through packaging, compliance, pilot production, and channel launch, crossing a long chain of roles on the way (L24-26). The context that actually drives judgment lives largely in the heads of product managers, R&D, and channel staff; the systems keep only the outcomes (L36-40). As SKUs piled up, packaging reviews started stacking and queueing (L64-65).
The case author opened up "packaging review" and found at least four kinds of judgment packed inside: designers catch typos; legal checks hard requirements under food and advertising law; the channel checks its own rulebook — say, the size ratio between the channel's logo and the brand's; and the product manager judges whether the package actually expresses the product (L69-73). All four used to land on the same reviewers.
The entry move deserves a note of its own. The author does not walk in with a finished solution (L86). Instead, an agent sits in the business group chat for two or three weeks, collecting context without rushing to solve anything, until "the agent itself located packaging review from real business conversations" (L97-101). One caution before anyone copies this: the source never says whether the group members knew an agent was listening — settle the authorization boundary first. Then comes the most organizational step of the whole case: write the AI a "job description." "If the company used to hire a person for packaging review, HR would hand him a job description. Now that we want AI to carry this work, AI should have a 'job description' too" (L111-112). And the business itself has to write it — if outsiders define the Skill wholesale, "it still tends to become the layman directing the specialist" (L109-110). In fact the decomposition was done by the people doing the review: what they actually check, the inputs, the outputs, what needs judgment and what can run as a straight rule (L113-115).
The sharpest cut of the engineering landed on arithmetic. Packaging art is dense — paragraphs of text, NRV energy tables, stylized display type — so the artwork first gets split into visual modules, each fitted with the OCR or VLM that suits it; then the fixed rules get scripted, and the calorie-table and NRV computation is hardened into deterministic code, "letting the model do only explanation and entry suggestions" (L131-134). The author's example is concrete: is "protein 2.9g, per 40g serving, NRV 5%" correct — "from now on, that kind of question is verifiable, reproducibly" (L134-135). Every module's result carries a source confidence, every conclusion traces back to raw data — "when a human employee takes over, they know what to trust and what to check" (L136-137). Finally the whole thing was wired into the product lifecycle system: a design file gets submitted, the Skill auto-runs a pre-check, and compliance problems, NRV math, and contradictory numbers get stopped before the designer hands work downstream (L141-142).
Now the caliber of the result. The pre-check is embedded in the daily flow and running in production (the breakdown card grades this case: live; effects as self-reported by those involved, with no quantitative comparison). The changes are self-described, in three layers: legal's and product managers' time gets re-allocated (L166-170, no numbers attached); personal experience "gets the chance to become organizational experience" (L175-176); and the author reads the overall effect as three layers — cost and efficiency, decision quality, organizational capability (L186-188, his own framing). None of it has a before-and-after denominator. The blank space is just as telling: who corrects a pre-check that rejects wrongly, who is allowed to change the review rules, who approves exceptions — the source doesn't spend a word on any of it.
The judgment this site stands up: a judgment that can be written as code does not go to the model — the model's number can come out different every run, and a review needs the same answer every time. The model wasn't cut from the project. It was placed: explain, suggest entries, feed context to human judgment.
The Only Site That Lets AI Write — and Its Ticket In Still Wasn't the Model
The third company's load sits at the peak. A Douyin local-life agency — think China's TikTok — whose clients are mostly restaurants across multiple cities (NO-15 L30-31), and at peak it needs to produce two to three hundred copy pieces a day (L37, self-reported). The company isn't short of people who can write. It's short of replication: "one person may write beautifully, but no single person can steadily process dozens — a hundred — pieces a day" (L34-36).
It's not that the client skipped AI. "We tried letting AI write directly, including a locally deployed DeepSeek, but the results didn't meet expectations" (L66). The author's diagnosis: the AI smell comes largely from a "fixed paradigm" — hand the model a fixed template and make it imitate it. That can work inside a single case; across merchants and formats it turns mechanical (L70-72). And this client's merchant spread is exactly the kind templates can't fool: luxury hotels, chain restaurants, independent little shops — different signature dishes, different campaigns, different owner voices, different target guests (L44-46).
The real path took five steps. First, understand the business: on-site conversations, watching how the work actually runs — who owns what, how a new client enters, how anyone decides a script is good (L95-102). Second, decompose human experience into business fields: who the client is, the store type, the signature dishes, the campaigns, the selling points, the content direction (L110-113). The author's own summary of this step is the most worth-stealing sentence in the entire collection: "take the experience inside a strong operator's head and turn it into business logic the system can call" (L114-115).
Then comes a concession: "a single Prompt or a single Skill is not enough" (L119) — because "writing one piece of copy" and "steadily producing usable short-video scripts" are two different jobs (L120). So step three bundles prompts, Skills, business parameters, and validation-and-audit mechanisms into one production flow (L121-122). Step four fixes the human-machine boundary: AI handles most of the standardized work, "humans own the final review and judgment" (L133), and any node where AI underperforms gets handed back to a person (L134). Step five is the grind: ship new versions to the client on a cycle and tune against platform data — prompts, process order, even model choice are all movable (L139-142) — because copy is like "an ear for language," and "it's very hard to define it as an absolute standard up front" (L143).
The caliber: the workflow is live in production, and the way new clients enter has changed — store, dish, and campaign parameters get planned before day one, and the system generates continuously, which the author calls "shaving the peak and filling the valley" (L159-163, his own term). "Judging from the client's usage feedback, the effect is very obvious" (L147) — and note what that is: a client self-report, relayed by the case author. There are no before-and-after throughput numbers, no script pass rates, no per-merchant breakdown behind it.
The judgment lands on territory. Variable expression genuinely is generative ground — there is no formula to preserve, no number to compute. But "throw it at the model and win" had already been falsified once at this very client, and the floor of fields, validation, and fallback was forced out by that failure. On generative ground, the entry ticket is fields, validation, and fallback — not the model itself.
The Question Nobody Answers at the Kickoff
Re-order the three sites against one template and the misplacement becomes visible.
The business side can always state the outcome. NO-22's case author described the shape of client language: "what the client tells you is usually an outcome" — "I want the shelves never to go empty," "I want restocking to stop being a hassle," "I want the ad money not wasted" (L180-182). He has a sharper line still: "actually, clients usually know what they want — they just can't say it in technical language" (L189). They don't know how the API hooks up, which processes suit automation, or that inventory and ads could even be linked (L190-191). The technical side, meanwhile, can always answer whether the model is any good. Both ends are right. The middle is vacant.
At all three sites, the missing question got filled in by one person. In NO-22, he declines to take the request at face value — before treating it as an API integration, he asks who will use it and what business problem it solves (L23-24), then spends a week and three or four rounds of conversation collecting the client's scenarios before writing anything (L67). In NO-19, he has the business decompose its own job — inputs, outputs, what needs judgment, what runs as a rule (L113-115). In NO-15, he watches the business before splitting it into fields (L95-102). The author has a name for the move: "the FDE's value is to take the outcome the client wants, take it apart, see which business chain it maps to, and then judge where in the chain the technology should plug in" (NO-22 L183-184). The most expensive word in that sentence is not FDE. It's take it apart first — an action that somebody should own at every kickoff meeting in every company, and at most companies that seat is empty.
Our breakdown sorts technical positions into five coarse tiers: optimization, data governance, deterministic computation, integration, generation. That sort is ours — the cut we made while comparing mechanisms across the 24 cases; it is not any case's self-description (cross-case study §2). But the same sentence, "I want AI to help with this," carries a different budget and a different acceptance test depending on which tier it lands on:
| Tier | What the work looks like | What acceptance watches | What the wrong slot looks like |
|---|---|---|---|
| Optimization | Picking combinations and sequences under finite capacity (truck loading, cutting, scheduling) | It fits, it's feasible, the floor can execute it | Translating "it won't fit" into a chat with a large model |
| Data governance + integration | The rule already holds; the data just never arrives, and the steps don't talk to each other | Data arrives on time + threshold triggers | Retraining a model for a formula that already works |
| Deterministic computation (recognition) | Fields have to be lifted out of images; the numbers must reproduce | Computes right, computes stably, traceable | Letting the model do arithmetic — paying for an answer that may differ every run |
| Generation | The expression has to be different every time | A stable floor + a human at final review | Bolting on fixed templates — paying to mass-produce the AI smell |
Recognition-and-extraction work usually shows up on the same ticket as deterministic computation and data governance, as it did in NO-19.
The three sites, slotted in (our breakdown; each case's facts come only from its own source text and breakdown card):
| NO-22 Cross-border restocking | NO-19 Packaging review | NO-15 Short-video copy | |
|---|---|---|---|
| The sentence the client walked in with | "Can you hook this SaaS up to Feishu?" | Reviews piling up in a queue; AI never mentioned | "We tried letting AI write… it didn't meet expectations" |
| Tier where it landed | Data governance + integration | Recognition + deterministic computation | Generation |
| State of the rule | Formula already holds; data just arrives late | Fields live inside images; numbers must reproduce | No formula; different every time |
| Acceptance | Data arrives on time + threshold triggers | Right, stable, traceable | Stable floor + human final review |
| The wrong slot | Training a model for a formula they already had | Letting the model do arithmetic | Fixed templates over variable expression |
One boundary has to be pinned down: this table is not an exclusive taxonomy. A single line of need can occupy several slots at once — NO-19 itself carries recognition, computation, and a pre-check integration. NO-15 is a necessary outlier: it faces variable expression, and it would be wrong to cram it into an optimization model just because optimization problems exist, and equally wrong to call generation illegitimate because it can't solve truck loading. The error of a misplaced project is never "picked the inferior technology." It is moving budget across slots.
Read the MIT report backwards and you get the scale of the misplacement: the money was spent, and spent outside the grid — more than half of it into sales and marketing, while the back-office automation the report considers the biggest return sits unattended.
What the AI kickoff is missing is not a list of model capabilities. It's a translation layer — something that turns "what we want" into "which slot we act in, and what we accept against." And that capability sits in neither the technical team nor the business team. It sits on the seam between them.
Three Questions to Take Into the Meeting
Here is how to turn take it apart first into something you can actually run in the meeting. Our breakdown gives three questions, in order — and only after all three are answered does anyone earn the right to talk models.
Question one: does a correct rule for this work already exist?
If yes — this is not an AI project. It's a data project. Fix the pipe, keep the formula, add the linkage. Acceptance equals: data arrives on time, thresholds trigger. NO-22 is this question's answer sheet: formula preserved, Supabase in the middle, inventory steering ads — and not one of the four steps involved training a model.
Question two: which of the judgments inside it are deterministic computation?
Whatever qualifies gets scripted — and the model is explicitly forbidden from doing the math. It explains; it suggests entries; nothing more. Acceptance equals: reproducible, traceable. NO-19 hardened the NRV computation into code, and did the sorting for free along the way: typos, regulations, channel rules, product expression — different judgments into different slots (L69-73, L126-127).
Question three: is what remains "expression that must come out different every time"?
If yes — only now does generative enter, and it must bring three things with it: business fields, validation and audit, node-level fallback. Acceptance equals: a stable content floor, a human at final review. NO-15 is the case that passed this gate.
Two boundaries. First, the three questions are a checking order for placing a budget, not a taxonomy — one line of need can answer "partly" to all three, and the answers are not mutually exclusive. Second, only after the three questions does "which model" even come up. In NO-22's case author's words: "so when I choose an approach, I ask first — does this problem actually need AI" (L168), and "if simple automation can solve it, don't force an Agent in just to chase the trend" (L169-170).
Where This Breaks
The three questions are not a master key. Four ways they fail — stated up front.
One: the rule itself is wrong. Question one carries a hidden premise — that a correct rule exists. In NO-22, "the logic holds" is the case author's conclusion after judging the operation on site; the source contains no order-by-order validation process. If the rule is wrong, the three questions will cement the error into the pipe, and automation just makes it wrong faster.
Two: slots move. The border between deterministic computation and generation is not permanent. NO-19 gives a live example: "as feedback from each channel accumulates, it settles into standards, and the pre-review gets handed to AI" (L76-77) — what needed human judgment yesterday may be standardizable tomorrow. The three questions have to be re-answered on a schedule. Answering them once at kickoff does not buy you five years.
Three: the pain isn't at the technical position at all. Data that can't be pulled out, a process that can't be changed, nobody with the authority to decide — the three questions can be answered perfectly and the project still never lands. NO-22's key-expiry mechanism is exactly this kind of wall (L153-155, L157-159). The same case had its access revoked after delivery and its effect ledger severed (L114-115, L128). Placement, however correct, is not a substitute for acceptance.
Four: the loss itself was never found. This piece answers once found, where does it land, not what to look for. That earlier half lives in Find the Loss First, Then Talk AI: Scenario Discovery Is Not a Technology Selection: audit the loss first, then talk placement — the order cannot be reversed. And where the organization can run its own operations after placement is a different ruler's job entirely; see AI Adoption Has Six Levels: From H0 to H5, Where Does Your Company Stand?.
One last compression. Companies that spend their budget in the wrong slot are never missing a list of model capabilities. They're missing the seat in the meeting where "I want" gets translated into "act in this slot." That seat is empty at most companies today — and every day it stays empty, the budget makes the decision for you.
Sources and Caliber Notes
- Case source: the first 24 cases of Datawhale's FDE Case 100, published September 2026; an L1 interview compilation from one editorial project — not 24 independent causal experiments. This piece uses only NO-22, NO-19, and NO-15 (plus the NO-22 continuation at the head of NO-23's transcript, L4-15); each case's facts come only from that case's source text and breakdown card — nothing borrowed across cases.
- Quote anchors: (NO-XX L-n) = the physical line in
sources/fde-cases/pdf-text/NO-XX-*.txt, re-verified line-by-line for this draft on 2026-10-10. Quotations are translated from the Chinese source text. Pages use printed-page numbering (printed page = PDF physical page − 1): NO-19's "live in production" grade is the breakdown card's, p. 193; NO-15's "changed how new clients enter" is p. 154; NO-22's case body spans printed pp. 219–226. - Number calibers, marked inline: NO-22's "a dozen or so people / 500–800 SKUs per quarter / 2,500–3,000 a year" are interview estimates; "4–5 hours → under 1 hour" and "2–3 hours → glance and verify" are self-reported by those involved, with no system logs and no comparison ledger, and nothing in this piece derives a money figure from them. NO-19's "100-plus SKUs" is the source's own fuzzy framing, quoted as-is. NO-15's "two to three hundred a day at peak" is self-reported, and "the effect is very obvious" is a client self-report relayed by the case author. NO-19 and NO-15 are live in production with no quantitative before-and-after denominators; the phrase "verified" appears nowhere in this piece as a claim about their effects.
- Framework attribution: the five technical tiers (optimization / data governance / deterministic computation / integration / generation) and the "three placement questions" are our breakdown (cross-case study §2). A single line of need can hold several kinds of technical work; the tiers are not an exclusive taxonomy, not any case's self-description, and not client-verified results.
- MIT anchor: hedged as "the report's own framing / as relayed by Fortune" throughout (Fortune, 2025-08-18, relaying MIT NANDA, The GenAI Divide: State of AI in Business 2025).
- Geography, per source: NO-22 is a cross-border e-commerce team selling into Southeast Asia; NO-15 is a Douyin local-life agency; NO-19 is a consumer-goods company whose country the source never names. None of them is flattened into "a Chinese company."
The next piece in this series moves to a different kind of site entirely: institutions inside the system. Their front offices went digital years ago; the back office is still people. In the few sites where errors are least tolerable, the delivered closed loop turns out to be the most complete of all — and the first deliverable AI hands over there is not an efficiency report. It's an audit report.
Related reading: Find the Loss First, Then Talk AI is the earlier half of this trip — if the loss hasn't been audited, "which slot does it land in" has nothing to act on; the order cannot be reversed. AI Adoption Has Six Levels: From H0 to H5 is the later half — after placement, how far the organization can run its own operations is a different ruler's job. And the take it apart first move usually belongs to whoever is embedded on the client's floor; that role's business model has its own piece: Your FDE Moved Into the Client's Building. How Do You Get Them Back Out?.
I'm Uncle J. Eighteen years in HR is where I learned that budget meetings rarely die on whether the model works — they die on the empty seat that was supposed to translate "I want" into "act in this slot, accept against that." These days I run a one-person AI organization, and this is how I work: start from what actually happened on real sites, draw the frame myself, and hand you the tool.