A bank underwrites a loan in roughly 5 steps: market the product, take the application, review and approve it, run final diligence, execute. Point a team at that flow and they will find step 3 almost immediately. A human spends an hour reading the application, a model can read it in seconds, and the hour comes back. Every board asking where the ROI went finally gets a number.
Andrew Ng’s argument at LangChain’s Interrupt conference is that the number is real and the transformation is not. “Bottom-up innovation often results in point solutions that drive incremental efficiency gains” [1]. The loan still takes a week, since the application still sits in a queue waiting for a human to be free. The marketing still promises whatever it promised before. Nothing about the product the customer buys has changed.
Some of the banks Ng works with drew a different conclusion. “Instead of doing this efficiency gain, which is worthwhile, let’s rethink the entire workflow and market a get approved in 10-minute loan product” [1]. That single sentence rewrites marketing, routing, data infrastructure, diligence, and execution at the same time. Step 3 was never the point.
Ng advises large enterprises through AI Aspire, the firm he founded with Kirsty Tan [2]. Bain & Company announced a strategic partnership with him in 2025 to accelerate AI transformation for its clients worldwide [3]. The vantage point matters here, since the distinction he is drawing only shows up when you have watched a lot of organizations spend a lot of money on the first kind of project.
Figure 1 - One Step Swapped Versus the Whole Flow Rewritten: The top path automates loan review and leaves the other 4 steps untouched, so the cycle time barely moves. The bottom path rebuilds marketing, routing, diligence, and execution around a promise that was previously impossible to make. The first path saves an hour of labor. The second one creates a product [1].
Efficiency Has a Ceiling. Growth Mostly Does Not.
The reason point insertions plateau is structural rather than a matter of effort or model quality. When each team automates its own step, the surrounding workflow is unchanged, so total cycle time falls by exactly the duration of the step that changed and no further. Run that play on 5 steps independently and you get 5 local wins and a product nobody experiences differently.
Ng puts the decision one layer up, at how the goal itself is written: “we can only save so much money, but growth has almost no practical ceiling” [1]. Cost savings are bounded by current spend. That bound is arithmetic, not attitude. Growth is bounded by the market, which is a much larger number in almost every business.
There is a second-order effect worth naming. A modest growth target invites a modest response. Ng’s observation is that a 2% target reads to an organization as an instruction to work 2% harder, where a 20% or 50% target cannot be met that way and forces a more creative answer [1].
We have made the compounding version of this argument before. The March of Nines covers why stacking incremental reliability fixes onto an unchanged architecture stops paying off, and the same math applies to workflow steps [4]. Each fix is real. The sum of them is not a different system.
Figure 2 - Two Ceilings, Very Different Heights: Savings are capped by what an organization currently spends, so the curve flattens by construction. Growth is capped by the addressable market. The choice of which curve to aim at is made at the strategy layer, long before any model is selected [1].
KEY INSIGHT: If your AI business case is denominated in hours saved, you have already chosen the bounded curve. Rewrite the case in terms of a product promise you could not previously make, and the architecture questions change with it.
Counting Automation Opportunities Is the Wrong Unit of Measure
The clearest restatement of Ng’s argument from an unconnected source that we have found this year comes from a mid-market tax advisory network in Europe, which is not where most AI transformation stories are set.
HSP GRUPPE is a network of legally independent tax advisory, auditing, and law firms. In an OpenAI-published customer story, CEO Carsten Schulz describes what happened when the firm went looking for automation targets: “We identified 88 opportunities for automation. But I think that’s already thinking too small. The real question isn’t how we automate today’s processes. It’s how we redesign them. That’s what opens the door to a completely new world” [5].
An inventory of 88 automatable steps is a genuinely useful artifact. It is also, on its own, a list of point insertions. Schulz’s point is that the count is the wrong unit: 88 faster steps inside an unchanged process is still the unchanged process.
His concrete example is year-end accounting. Today, accountants often discover missing information only when they begin preparing annual accounts, months after the bookkeeping itself was finished [5]. The point-insertion move is to speed up the chasing of documents. HSP’s stated direction is to remove the discovery-at-the-end failure mode entirely, by having the system continuously review bookkeeping through the year, flag gaps as they occur, and request documents from clients proactively, “so that much of the preparation has already happened before an accountant even opens the file” [5].
Two caveats travel with everything in this case study, and we are stating them once so they apply to every HSP figure below. The usage figures refer to a shared ChatGPT Enterprise workspace used by HSP GRUPPE together with its partner network Kanzleipakt, covering 81 organizational groups, not to HSP alone [5]. All of it is self-reported by HSP and published by OpenAI, so it corroborates the pattern rather than independently verifying it.
Figure 3 - 88 Faster Steps Is Still the Same Process: An automation inventory counts steps. A redesign changes what the process is for. HSP’s year-end close moves gap detection from the month of the close to the whole year preceding it, which is not a faster version of the old workflow at all [5].
When Software Gets 10x Faster, Everything Else Becomes the Bottleneck
Ng’s second observation is the one that decides whether a redesign is deliverable. “When writing software becomes 10 or 100 times faster, not only is there a product management bottleneck, pretty much everything else becomes a bottleneck” [1]. This is his own field observation from running teams, not a benchmark, and it should be read that way.
The examples he gives are specific. Marketers scramble to work out what the engineers built in order to describe it. A feature that took 3 months to build could absorb a week of legal review without anyone noticing; a feature built in a day cannot. Design sign-off behaves the same way [1].
None of those functions got slower. The queue in front of them simply started filling faster than it drains. That is the structural reason a workflow redesign stalls even when the AI capability is adequate: the redesign touches marketing, legal, and design, and those functions are sized for the old arrival rate.
Ng’s organizational answer is small pods of high-context generalists, anywhere from 1 to 10 engineers, given wide guardrails and the authority to extend into adjacent roles rather than wait for handoffs [1]. He is explicit that AI makes a generalist somewhat less bad in a domain where they have no formal training, which is enough to unblock a handoff without replacing the specialist [1].
We have written about where that model runs out. The Orchestration Tax argues that the ceiling on this kind of parallelism is human attention rather than tokens or model capability [6]. A pod of generalists moves faster than a handoff chain right up to the point where one person is supervising more concurrent work than they can actually hold.
Figure 4 - The Constraint Moves, It Does Not Disappear: Faster software construction does not shorten a workflow whose downstream functions run at the old rate. Product management, legal review, marketing, and design become the new queue. A redesign that ignores them delivers features nobody can ship [1].
Figure 5 - Handoff Chain Versus Generalist Pod: The handoff chain is gated at every boundary, so its throughput is set by its slowest sign-off. The pod trades some specialist depth for the ability to carry work across role boundaries. Ng runs teams of 1 to 10 engineers this way, with wide guardrails rather than narrow approvals [1].
What Redesign Actually Looks Like When It Ships
The argument so far is a strategy argument, and strategy arguments are cheap. Three production accounts are worth walking, with their attribution intact.
Cisco: define the criteria before counting the use cases
Carlos Pereira, Fellow and Chief Architect in Cisco’s Customer Experience organization [8], told LangChain’s Interrupt conference what his advisory team found when it met a customer that had already inventoried its AI ambitions: “We enter on a customer that the customer had 412 use cases for AI and when you talk with them ends up being five that actually collaborate to the business” [7].
The interesting part is what Cisco changed as a result. Rather than triaging 412 items, the team defined admission criteria first, so that a use case had to fit one of 3 buckets before it was considered at all: help customers get immediate value from what they have already invested, make operations more secure and reliable, or provide visibility and insight across the whole lifecycle [7]. Pereira’s account of the pre-criteria era in a 20,000-person organization is that everybody was trying to build a chatbot, and that leaving it alone means people do their own thing [7].
These figures are conference testimony from a named executive. No Cisco press release or published case study corroborates them, so treat them as an account of what a practitioner says his team did.
Figure 6 - The Filter Comes Before the Inventory: Cisco’s advisory practice reports meeting a customer with 412 catalogued AI use cases, of which roughly 5 actually contributed to the business. The response was not better triage of that list, it was defining 3 admission criteria inside Cisco’s own 20,000-person CX organization before anyone was allowed to propose a use case [7].
LATAM Airlines: out of scope is unmet demand, not noise
LATAM Airlines built Concierge, a passenger-facing travel-assistance agent. According to LangChain’s own writeup, 13% of messages to Concierge were initially classified as out of scope. Reviewing those conversations changed the reading entirely: 95% of them were legitimate passenger needs the agent had simply not been built to handle, including check-in, baggage, and travel requirements. Adding a customer-care specialist reduced the out-of-scope rate from 13% to 1% and improved the return rate by 6% [9]. The talk was given by Nico Venegas and Claudio Urbina Lara at LangChain’s Interrupt conference [10].
Read that as an instrumentation result rather than a routing fix. The “out of scope” bucket was the product roadmap, written by users, sitting in a log that nobody had read as a roadmap. This is the same mechanism we described in Self-Driving Products, where observability signals become the input to product change rather than an operational afterthought [11].
The same team found a second result the same way. Production traces showed each specialist agent independently formatting its own structured output even when no downstream component needed it, costing roughly 15% overhead in latency and token consumption. Moving formatting to the supervisor, once, immediately before the response goes out, preserved output quality and cut cost by around 15% [9].
Figure 7 - The Reject Pile Was the Roadmap: LATAM classified 13% of Concierge messages as out of scope, then found that 95% of them were real passenger needs the agent had never been designed to serve. Building the missing capability moved out-of-scope traffic from 13% to 1% and raised the return rate by 6% [9].
Figure 8 - Format Once, Not at Every Hop: Every specialist structuring its own output added roughly 15% overhead in latency and tokens with no downstream consumer for the structure. Moving formatting to the supervisor, executed once before the final response, held quality steady and cut cost by around 15% [9].
HSP GRUPPE: the redesign lands in a boring workflow
The HSP year-end-close example above is the third account, and it is the most useful precisely because tax and accounting is not a sector anyone uses to sell AI transformation. Individual results inside the same workspace are consistent with the pattern. Partner Magdalene Posnak reports that evaluating multiple real estate investments went from around 9 hours to about 2 [5].
The firm’s stated capacity scenario is the number most likely to be quoted out of context, so here it is with its own hedge attached. HSP estimates roughly 40,000 hours of additional annual capacity across the network, split into about 28,000 hours of billable specialist work and about 12,000 hours of administration and client service, which at conservative hourly rates it values at approximately EUR 3.8 million. The source states plainly that this “is a capacity scenario, not realized or guaranteed revenue” [5]. It is a projection of what freed time could be worth if it is redirected to billable work, and the 81-organization-group scope caveat applies to it as well.
KEY INSIGHT: Instrument the requests your system refuses, not only the ones it serves. The refusal log is the cheapest roadmap in the building, and it is written by the people who are already trying to pay you.
The Version You Can Run This Month
Enterprise accounts are useful for establishing that the pattern exists and useless for showing a reader how to start. The smallest fully-narrated version we have found is Nate B Jones, who ran the exercise on his own support inbox and published the method.
He starts from a week that looked like a win: 51 of 52 customer support issues resolved with AI assistance, which reads as a 98% week on any dashboard [12]. The problem is that the underlying cause kept manufacturing tickets, so a 98% resolution rate measured how fast the treadmill was running.
The instruction he gave the agent is the reusable part. Make a row for every case. Record what the customer experienced, what actually failed in root-cause form, what the team checked, what people did to solve it, and whether the customer came back, “and then group the cases by their underlying cause, not by the subject line” [12]. His own illustration lands it: “my Slack invitation never arrived,” “the link expired,” and “I paid with a different email” look like 3 different tickets, and they pointed at the same broken doorway [12].
The fix was structural. Approved email domains for self-service entry, a non-expiring community invite, and removal of a redundant approval step for people who should have been admitted automatically. In the next comparable week the total support count fell to 19, and the Slack category did not appear at all [12].
Where the automation actually landed is the sentence to keep. The agent was pointed at gathering and synthesizing context across billing, account state, and prior conversations, so the human opened a ticket with the research already attached. The reply itself stayed human, and human approval was retained on every decision touching access or money. By his own estimate, roughly 90% of the mental load went away, which is an operator’s read rather than a measurement [12].
Two honesty beats from the same account are worth more than the headline. Scaling this out meant finding 26 distinct support patterns with separate standard operating procedures, then examining each one for where AI could take the most painful part [12]. The residual gets harder rather than easier: “you don’t go from 52 to zero in a week. You go from 52 to 19” [12]. What remains involves systems disagreeing, unclear policy, or a product problem that needs judgment.
He also names the failure mode of trusting the analysis: “Agents are very good at making a messy pile look orderly, including when the order is wrong” [12]. His countermeasure is to read the largest cluster manually and check whether the grouping holds before acting on it.
Figure 9 - Group by Cause, Not by Subject Line: Three tickets that read as separate problems traced to a single broken access path. Fixing the doorway rather than answering the tickets faster took the weekly count from 52 to 19, with the largest category disappearing rather than being handled more efficiently. The operator’s own framing is that you do not get to zero in a week [12].
The Organizational Mechanics Nobody Puts in the Architecture Talk
Every account above describes a technical change. None of the technical changes is the hard part.
HSP is the only one of these sources that documents the organizational side at a level a reader can copy, and it treated the rollout as an organizational transformation rather than a software deployment [5]. The named mechanics are unglamorous:
- Monthly AI forums gave employees a recurring venue to share working use cases and learn from each other [5].
- Pairing AI specialists with domain experts turned individual experiments into shared, standardized capabilities instead of leaving them as one-off prompts [5].
- Piloting with a small group before expanding is how the agentic tier was introduced, starting with developers and administrators and widening from there [5].
- Measuring adoption and business impact rather than deployment is stated explicitly as the way to find where value is actually being created [5].
The standardization step is the one most organizations skip. HSP names two of the individual use cases it standardized into shared Agents: AI Client Communication, which supports first drafts, structure, clarity, and a consistent client-facing tone, and Booking Assistant SKR03 & SKR04, which supports preparation and classification of bookkeeping questions. In both cases the source is explicit that professional review and final responsibility remain with the relevant specialist [5].
Schulz names the constraint directly: “Technology is moving faster than organizations can transform” [5]. His stated challenge was never introducing AI, it was helping the organization absorb it.
The measurement discipline is where we would push hardest. Measuring adoption and business impact rather than deployment [5] is easy to agree with and hard to operationalize, and most teams substitute a deployment count because it is the only number available. We covered what a real measurement layer costs to build in Evals in Practice [13]. A redesign without one is a story, not a result.
Figure 10 - The Loop That Turns Experiments Into Capability: Individual experimentation produces scattered wins. Forums surface them, pairing standardizes them, small pilots de-risk them, and measurement decides which ones survive. HSP lists all 4 among the tips it offers other organizations, and the standardization step is the one that converts a clever prompt into an organizational asset [5].
KEY INSIGHT: A workflow redesign is an organizational-capability project wearing a technology project’s clothes. Budget for forums, pairing, and measurement the way you budget for infrastructure, or the redesign stays a slide.
Where a Redesign Stalls Regardless of the Model
Ng named 2 infrastructure gaps that block top-down redesign regardless of how good the models get, and both are worth a hard look before anyone commits to a redesign timeline.
The first is unstructured data. Organizations spent decades organizing structured data and comparatively little effort organizing everything else. Ng’s description of the current state is fragmentation, governance gaps, no consistent schema, and some of it sitting on someone’s laptop [1]. The compliance-driven document archives that nobody has opened in 20 years are suddenly worth reading, and they are not in a shape any agent can use.
The second is permissions. “The permissions were designed for humans, not for agents,” Ng says, and the questions that follow have no default answer: does the agent inherit the operator’s permissions, and how is governance and observability managed once it does [1]. This is a policy question wearing an engineering question’s clothes, which is why it stalls.
There is a third gap that shows up once a redesign spans more than one team’s systems. Cisco’s framing of it is memorable: when you go to the internet, the first thing that happens is a DNS lookup, and there is no equivalent for agents [7]. A protocol standardizes the tool call. It does not standardize discovery, identity, or semantics, so every cross-team integration in a redesign is still hand-wired.
AGNTCY is the named response to that gap, and it is further along than most readers expect. Cisco open-sourced it in March 2025 with collaboration from LangChain and Galileo, and the Linux Foundation welcomed it as a project on July 29, 2025, with Cisco, Dell Technologies, Google Cloud, Oracle, and Red Hat joining as formative members and more than 65 supporting companies [15]. Its stated scope is discovery, identity, secure messaging, and observability across agents from different vendors and frameworks [14][15]. Whether it becomes the standard is an open question. That the gap is real enough for 5 infrastructure vendors to join a foundation project as formative members is not.
Figure 11 - What Stops a Redesign That the Model Cannot Fix: Unstructured data with no schema and permissions designed around human identity are the 2 gaps Ng names as blocking top-down redesign. The third appears as soon as a redesign crosses team boundaries: a protocol carries the call, and nothing carries discovery, identity, or semantics. AGNTCY is the named production response to that third gap [1][7][15].
Conclusion
The distinction Ng draws is not a criticism of point automation. Automating an hour of loan review is worth doing, and so is the invoice-matching step, the ticket triage, and the first-draft generation. Every one of those is a real gain with a real number attached. The mistake is booking the gain as transformation and then wondering, 18 months later, why the product looks the same.
The tell is the unit of measure. An organization counting automation opportunities is running the bottom-up motion, and 88 of them is still 88 point insertions. An organization asking what promise it could make to a customer that was previously impossible is running the top-down motion, and that question reliably produces a smaller list with a much larger denominator behind it. Schulz and Ng arrived at the same framing from a mid-market tax network and a conference fireside, with no connection between them.
The accounts we walked share a shape. Cisco defined admission criteria before anyone was allowed to propose a use case. LATAM read the traffic its system refused and turned it into the roadmap. HSP treated adoption as an organizational-capability build with forums, pairing, pilots, and measurement rather than a licence rollout. Jones grouped tickets by cause instead of subject line and deleted a category rather than answering it faster. In each case the technology was ordinary and the framing decision did the work.
There are 2 things worth doing before the next AI project gets funded. Take the existing portfolio and sort it into point insertions and redesigns, honestly, with the efficiency projects allowed to stay and be measured as efficiency projects. Then take the largest single flow in the business and ask what the customer-facing promise would be if the internal cycle time went to near zero, since that question is the only one that reliably produces the second kind of project.
That sorting exercise is the work we do. A workflow-redesign audit at Dotzlaw Consulting means sitting with the actual flow, the actual traces, and the actual refusal logs, then producing a short list of candidate redesigns with the readiness gaps named per candidate: what the unstructured data looks like, where the permission model breaks, which downstream function becomes the new bottleneck, and what the measurement layer has to cover before anyone can tell whether it worked. We are happy to say when the honest answer is that the point insertion is the right call and the redesign is not yet buildable. That answer is worth as much as the other one, and it is cheaper to get before the budget is committed.
References
[1] LangChain, “The Future of AI Agents with Andrew Ng | Interrupt 26,” YouTube, 2026. https://www.youtube.com/watch?v=OaRhpwz_TGM
[2] A. Ng and K. Tan, “AI Aspire,” 2026. https://www.aiaspire.ai/
[3] Bain & Company, “Bain & Company forms strategic partnership with Dr. Andrew Ng to accelerate AI transformation for clients worldwide,” Bain & Company Press Release, 2025. https://www.bain.com/about/media-center/press-releases/20252/strategic-ai-transformation-partnership-with-dr.-andrew-ng
[4] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The March of Nines: Why Agent Skills Alone Won’t Reach Production Reliability,” 2026. /insights/ai-01-march-of-nines-reliability/
[5] OpenAI, “How HSP GRUPPE builds AI capabilities for tax advisory,” OpenAI, Aug 2026. https://openai.com/index/hsp-gruppe/
[6] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Orchestration Tax: Why Loop Engineering Has a Human Ceiling, Not a Token One,” 2026. /insights/claude-code-17-orchestration-tax/
[7] LangChain, “How Cisco Powers AI Automation with LangGraph, LangSmith, and LangChain | LangChain Interrupt,” YouTube, 2026. https://www.youtube.com/watch?v=gPhyPRtIMn0
[8] Cisco, “Carlos Pereira, Fellow and Chief Architect, Cisco Customer Experience,” Cisco Blogs author profile. https://blogs.cisco.com/author/capereir
[9] LangChain, “Customer Experience (CX) Agents in Production: Lessons from Lyft, Vodafone, and LATAM Airlines,” LangChain Blog, Aug 2026. https://www.langchain.com/blog/customer-experience-cx-agents-in-production-lessons-from-lyft-vodafone-and-latam-airlines
[10] LangChain, “How LATAM Airlines Built Intelligent Agents in Aviation | Interrupt 2026,” YouTube, 2026. https://www.youtube.com/watch?v=RnLCl3ilRgo
[11] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Self-Driving Products: From Observability Signals to Pull Requests,” 2026. /insights/ai-14-self-driving-product-pipeline/
[12] N. B. Jones, “I Gave An AI Agent My Support Inbox. It Cut The Work By Two-Thirds.,” AI News & Strategy Daily, Jul 2026. https://www.youtube.com/watch?v=7pqRRxrdr0c
[13] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Evals in Practice: The Two Wrong Ways and the Three-Stage Fix,” 2026. /insights/ai-12-evals-in-practice/
[14] AGNTCY, “AGNTCY: the Internet of Agents,” AGNTCY / Linux Foundation. https://agntcy.org/
[15] The Linux Foundation, “Linux Foundation Welcomes the AGNTCY Project to Standardize Open Multi-Agent System Infrastructure and Break Down AI Agent Silos,” The Linux Foundation, Jul 2025. https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.