The Spec That Vanished: How Agents Reshuffle Business, Product, and Engineering

Not another "will AI replace the PM" piece. This is a role fight from a real project meeting, dug down to the root — why, in an agent system, the twenty-year-old "business → product → engineering" handoff suddenly won't connect, the three named fixes enterprises have already converged on, and a two-speed timeline where one architect builds the pilot and a whole team hardens it. 中文版：开发直接对业务把 Agent 架起来，产品不干了。

In that meeting, why product suddenly became "support"

A recent project meeting. The business lead said something that made the room go quiet: for this customer-service agent, engineering is wiring the whole thing — architecture, delivery, phase-one and phase-two launch — straight off the business needs, and product is the support role this time. On a traditional project that sentence runs the other way: product leads, engineering implements.

After the meeting I went to talk to a colleague building a knowledge agent, and he handed me something sharper: his design can't be written up as a doc and handed to product and engineering first — it doesn't explain. What he does is stand the system up directly, and then product and engineering take that architecture and wire the existing enterprise systems into it.

Put the two sentences together and they point at the same thing: on this project, the act of "designing" moved out of product's hands, over to whoever can stand the system up.

Product's frustration is fair. On a traditional project their work is concrete: take the business need, produce the design doc, draw the prototype, spec everything down to how big the button is and where the tap goes, then hand it to engineering to build. Now the top half of that chain got routed around.

But reading it as "engineering grabbed power, product is out" reads it shallow. Over the past year doing agent adoption inside enterprises, I've watched several teams stall on this exact spot, all of them arguing "who leads" — and not one team was arguing about the right thing. What actually happened is that the deliverable in their hands, the thing called "the spec," quietly stopped existing in an agent system. And this fight has already run for a year abroad, with billions of dollars on it, long enough to grow names and fixes.

The craft of pinning business into config just failed on agents for the first time

Let me put the conclusion on the table first: traditional SaaS product's core craft is turning fuzzy business rules into deterministic config — screen after screen you can check, fill, and drag; in an agent system, that "pinning down" simply can't be done.

Take the most ordinary need — the business says "get refunds under control." In traditional SaaS, what product ships is a whole stack of pin-down-able things:

• An approval-flow builder: drag nodes on a backend — "amount over $500 → manager approval; over $5,000 → add a finance approval" — if/then branches drawn as a visual flowchart;
• A ticket form: ticket-type dropdown with twelve items, required fields per type, an SLA countdown, who it auto-escalates to on timeout;
• A state machine + permission matrix: a refund ticket's five states (draft → pending → approved → rejected → refunded), which role can click which button in each state, pinned cell by cell;
• A rules-engine backend: let ops self-configure the "7-day no-questions return" toggle and "$20 off over $200," so when the business changes, ops edits it without calling engineering.

The core of this craft is a default assumption: that "what's correct, what's good enough" in the business can be thought through in advance by product and pinned into config. "Refunds over $5,000 need finance" is a rule you can write down; product turns it into a config screen and the system executes it deterministically. Product, engineering, and QA connect because the thing passed between them can itself be pinned: given the input, what the screen looks like, which endpoint the tap hits, which approval path it takes — all fixed.

Agents pull that assumption out. A user types "these shoes pinch — can I return them?" and there's no dropdown that can hold what sits behind that sentence: is this a return or a size-exchange, has it shipped yet (which decides whether you can even intercept the parcel), was it bought on promo and does the size-swap owe a price difference, and which price for that difference. None of that can be pre-baked into a config item for ops to tick, because the next step depends on runtime context and every conversation's path is different (this is exactly the line between an L2 real agent and L1 automation).

Abroad they put it bluntly — "AI broke generic SaaS": every enterprise's data, workflow, compliance, and definition of "good enough" differ, and in the agent era every one wants a slightly different prompt, tool list, eval rubric, integration surface. Generic SaaS bet that business rules can be pinned into one shared config by product; on agents, that bet collapsed. Product's craft of translating business into deterministic config lost the thing it used to pin.

Product "can't explain it" — not a skill gap, the translation changed direction

The "business → product → engineering" chain — the value was never in the three stations themselves, it was in the translation in the middle: turning fuzzy business intent into something buildable. The product role is, at its core, the owner of that translation.

In traditional software, that translation is the hardest and most valuable part: the business says "make returns smoother," and product breaks it into a dozen screen states, dozens of config rules, how big the button is and where it jumps. The difficulty is turning intent into deterministic screens and config — and product carries it.

In an agent system, the hardest translation changed direction. The business says "make returns smoother," and the hard part isn't drawing screens, it's turning that intent into a safe, evaluable, accountable decision architecture: which calls the LLM may make on its own, which must run a fixed path, which step costs real money if it's wrong, where the Critic backstops, how you prove it's right before launch. That translation wants someone who understands the business rules and the LLM's failure modes at the same time — both in one head — and that isn't in product's old "screens and config" skill set. It lands more on whoever knows both the business boundaries and how the LLM breaks — usually the architect.

That's the real reason the colleague "can't explain it." Not poor communication. It's that the thing he has to hand over, written to the point where it can be explained, is already the system architecture itself, not a spec for someone downstream to implement — the middle layer, "product translates the design into a spec engineering can build," has nothing left to translate. Design is architecture; architecture is the implementation note. The floor got pulled out from under the layer product was standing on.

So it isn't that engineering grabbed product's job. It's that "translate business intent into something buildable" — the core translation — changed shape in an agent system and moved into another person's hands. This isn't just my read. Andrew Ng puts it more bluntly: the bottleneck in AI startups isn't writing code, it's product — deciding what to build is harder than building it. Some peg the new ratio at one PM to 0.5 engineers, not the traditional 1:4. In the Valley they call this round "the PM gets bisected": one half sits close to engineering and customers, writing agent-executable specs; the other half retreats to platform, APIs, data, compliance — and the person in the middle writing ten-page PRDs and speccing button sizes becomes the bottleneck. One line: "engineering got 5× faster, PM didn't."

"Product is useless" is a trap: the vanished spec split into three

The easy next step here is a conclusion: so is product just useless now? That's a trap. Teams that fall in pay tuition six months later.

That vanished "spec" was carrying three things at once. The spec is gone, but the three don't vanish with it — they just fall out of product's doc and scatter on the floor, waiting for someone to pick them up. See which three, and you know where product should move, and what rots if nobody picks them up.

One: the decision boundary — what the agent may decide, and what it may not. Whether "return vs. cancel vs. parcel-intercept" takes which path depends on whether the order has shipped; which policies the LLM may judge itself, which must escalate to a human. This now lives in the workflow state machine and travels with the architecture — it needs someone who understands both the business and the LLM's failure modes, and product can't catch it without both. This one mostly went with the architect.

Two: eval ground truth — what actually counts as "done right." This is the one everyone misses, and it's precisely product's new home. A case that stings: a customer bought shoes on promo, comes back to swap up a size, and owes a price difference — which price? Amount paid, current purchasable price, list price, member price — four numbers that can differ by a hundred dollars. This isn't an engineering problem; engineering just runs the formula right. "Which price" is a business decision someone has to make and write into a rubric.

This isn't my private opinion — abroad it's become a discipline called eval-driven development: before any probabilistic system ships, you first need a spec of "what's correct," and nothing ships without automated proof it meets that spec. And the one line of division of labor at its center reads almost like product's new job description — "the rubric is written by the PM, not the engineer; the engineer builds the scoring infrastructure, the PM defines what each score means and what the threshold is." Better still: this eval — the rubric, the labeled real conversations, the thresholds — lives in version control with a changelog, and it's the "product IP" that survives model upgrades: prompts and models churn, the rubric doesn't (both containment vs. resolution and the pre-launch gates hang on this rubric). This is the vanished PRD reincarnated: it no longer looks like a requirements doc, it looks like a scoring rubric plus a batch of real conversations with answers labeled. Whoever defines that rubric is the product person of the agent era.

Three: accountability — who signs their name on "why the agent did that" when it goes wrong. On a traditional project, product's spec was a link in the accountability chain. Once engineering stands the system up straight off the business, that chain often snaps mid-air — who signs "ship it" before launch? When a refund goes out wrong in production, who answers the regulator and the boss on "why did this path go through"? The moment no one clearly carries this, the whole project hangs. This isn't a technical problem, it's a decision-rights problem.

Put the three together and "product is useless" falls apart. Product wasn't replaced by engineering. The layer product stood on — translating intent into screens and config — got thin in an agent system; and the new layer that grew — defining eval ground truth, holding accountability — product hasn't moved into yet. The Valley line is crude but right: execution gets cheap, coherence gets scarce — more people who can do the work, fewer who can decide and make the whole thing cohere.

How enterprises actually reorganize: three fixes that already have names

Good news: the awkwardness in your meeting room has been argued abroad for a year with billions of dollars on it, and it's produced three fixes with names you can copy. They're not theory — they're operating models the biggest AI companies bet real money on.

Fix one: accept that "engineering talks to the business directly" is a named model, not a power grab. It's called the Forward Deployed Engineer (FDE) — Palantir invented it back in 2008, and OpenAI, Anthropic, and Databricks rebuilt it for the LLM era across 2023–2025. Mid-2026, the biggest AI companies (AWS, Anthropic, OpenAI, Microsoft) piled into the model within a few weeks, sending engineers to sit on-site at customers and stand agents up — AWS alone publicly committed $1 billion. That multi-billion-dollar collective bet is on one thing: agentic AI doesn't ship itself; someone has to sit next to the customer and stand it up. The FDE line most quoted in the field is almost word-for-word your boss: "there's no product manager in the room to do this for you — you are the product manager in the room." So your boss isn't freelancing; he's standing on a rail that's run for seventeen years and was rebuilt. The fix isn't to grab leadership back — it's to pair that architect with a business SME to go direct, and move product out of the "middleman relay" seat — where to, see fix two.

Fix two: redefine the vanished spec as an eval, and move product in as the rubric owner. Eval-driven development, at the org level, is a job redefinition: product stops writing "how big the button" PRDs and moves to defining "what counts as resolved, which price for the difference, does this order qualify for a refund" — writing it as a rubric, labeling a batch of real conversations as ground truth, setting thresholds, into version control. This work is worth ten times the old PRD — because it's the only product asset that survives model upgrades. A product person who can read the business and is willing to go deep on labeling and rubrics is the scarcest hire on an agent project. Product's transformation path isn't "learn to write prompts," it's becoming the owner of the rubric.

Fix three: draw decision rights explicitly, add a layer of governance (DRI + agent registry). Name each of the three owners in writing. Here's the number that should sober the boss up: nearly half — 48% — of enterprises rolled out AI without redesigning the workflows or roles it sits in; only 34% say AI produced measurable financial return, and under 20% have a mature governance framework. Most failures aren't the model — they're stuffing an agent into an unchanged org. The mature move is an agent registry that governs every agent — who can call it, how KPIs are watched, when it retires; and enterprise-architecture teams model agents as "architectural components" alongside processes, apps, and data (which echoes fix one: the decision boundary travels with the architecture). Don't be the 48%.

Stitch the three together and you have the new division of labor: architect + business SME go direct (FDE), product moves in as the rubric owner (eval-driven), governance pins the three owners down (DRI). "Who leads" is a fake question; this placement is the real one.

This split has a timeline: architect builds the pilot, a team hardens it

Everything above is the cross-section — which of the three things goes to whom. But there's a vertical axis that's easy to miss: an agent project has a pilot phase and a maturity phase, and the division of labor in the two is not the same thing.

That axis has a ready template too. Palantir's FDE was never one person start to finish — it's two-speed: one crew up front (they call it Delta) sits on-site with the customer and stands the system up fast, 0→1, however-fast-it-takes; a second crew (Echo, the core product org) then generalizes, hardens, and turns what got trailblazed into a stable platform reusable across customers. Their nickname for it is perfect — "paving the gravel road."

It lines up: the pilot phase is the architect's stage. One strong agent architect runs solo and fast, standing the business pain up into a working feature — this stretch should be architect-led, more hands only slow it down, and product genuinely can't help much here. But the maturity phase is another crew's job: stable operation, data-governance pipelines, monitoring and alerting, reuse across scenarios — none of that is "polishing the architecture," it's building a whole capability the pilot skipped.

Here sits the most expensive trap on an agent project, and it needs saying against the grain: evals and data governance can't all be deferred to the maturity phase. A schedule of "get the feature working first, grind stability later" sounds reasonable, but the international data runs the other way — organizations using eval tooling ship nearly 6× more AI systems to production (Databricks 2026); only 21% of enterprises have mature agent governance, and enterprises naming a dedicated "agent owner" went from 11% in 2024 to 56% in 2026 (Deloitte).

Translated to your situation, one line: in the pilot phase one strong architect can carry it; in the maturity phase you can't — not because the architecture is weak, but because no one can yet measure whether the agent is getting better. A team with no evals, no labeling, no continual-learning muscle (which is exactly the state of most traditional enterprise engineering teams) turns the maturity phase's "grind and polish" into "grind and rewrite": you change a version, don't know if it's better, ship on feel, roll back after it breaks. Without that ruler, polishing is running in place.

So what the maturity phase actually does isn't smoothing the architect's design — it's building the capability the team doesn't have yet: evals, labeling, data governance, a rubric owner — and some of the seeds have to go in during the pilot. Which is exactly product's cue to step in: you finish 0→1, product walks in with the rubric and the labeling to do 1→N. The pilot belongs to the architect, the maturity phase to product + engineering + data — not who-replaces-whom, but two surfaces of one road, gravel and paved, each laid by different people.

That friction in your office is a multi-billion-dollar industry reshuffle

If you're living this awkwardness too, exhale first: it's not any one person's problem at your company, it's an industry-wide role reshuffle, and teams all over the world are spinning in the same pit right now.

On HN this gets loud. One engineer complains that product won't let engineering touch the prompts, and the top reply cuts through: "banning engineers from prompts is pure politics" — it's a role guarding its turf. There's the reverse too: product edits AI-generated code but "can't tell if the AI wrote good code or bad," planting bugs it doesn't see. And one line in product's defense: "good PMs do invisible work; bad PMs are just invisible" — product's value was never in the manual craft of writing the spec, it's in judgment and alignment, and that part AI can't take.

The numbers don't all deserve to be swallowed whole, but the direction agrees: the twenty-year-old division of "who writes the spec, who decides, who signs" is being collectively redrawn. GitHub's engineering team put it most bluntly — "the specification becomes the source of truth and determines what gets built." The PRD used to be an alignment doc for humans; the spec you now give an agent is an executable, scorable interface. Writing the spec itself changed species.

The friction in your meeting room is one slice of that redraw landing on your desk. Arguing "who leads" is reading a new road off an old map — the "business → product → engineering" road is still on the map, but a stretch of the pavement has collapsed.

Conclusion: product's frustration is real, but the fight is the wrong one

Back to that meeting. Product feels routed around, and that feeling isn't false — the spec in their hands that used to pin down requirements really did lose its use. But what the meeting should actually settle was never "who gets leadership back." It's whether the three things the vanished spec scattered — decision boundary, eval ground truth, accountability — have landed in your project.

• The decision boundary mostly went with the architect already (that's FDE). Accept it, don't fight for it.
• Eval ground truth is the biggest open lot, and the most valuable. If product moves in as the rubric owner, it's worth ten times guarding "how big the button."
• Accountability snaps mid-air most easily, and it's the most fatal. Name a DRI, in writing. Don't be the 48% that rolled out AI without changing the org.

Here's a detection move you can use in the room: at the next review, stop asking "is this product's job or engineering's job," and ask three things —

1. Who set the decision boundary? This agent may decide refunds on its own — where's the boundary written, who reviewed it? No answer = the decision boundary has no owner, wait for the LLM to free-run into trouble.
2. Who signed off on the ground truth? "Which price for the difference," "what counts as resolved" — who signed that, is it in version control? "The model decides" = eval ground truth has no owner, you ship on feel.
3. Who signs the launch? When it breaks, who answers "why did the agent take that path"? No answer = accountability has no owner, the project hangs.

If any of the three stalls, that slot is where your project rots next — nothing to do with who leads.

The division of labor in the agent era isn't who-eliminates-whom. It's that the twenty-year-old "spec" came apart, and the three things it carried are on the floor waiting to be picked up. Whoever bends down to pick them up stays on the field.

If this untied the "who leads" knot for you, pass it to the colleague on your team stuck on it — especially the product person who feels routed around. A role reshuffle isn't zero-sum; it's three owners each finding their place.

Want the "three-owner placement checklist" from this piece (one A4 page, tick it off at your next review)? Reply with the keyword role-reshuffle and I'll send it. Reply channels in the footer.