TL;DR — Three posts this week all circle the same instinct: we distribute work across systems, services, and tools long before the problem justifies the coordination tax. The teams that win are the ones that keep the surface area small on purpose.
The theme
The common thread across this week's reading is the hidden cost of premature distribution. Transformation programs fail at month six because they split delivery from operations and never pay to stitch them back together. Agents burn tokens because we hand them thirty leaf tools and ask them to do data wrangling in English instead of letting them write a five-line snippet against one code-execution tool. Commerce teams ship features quarterly because they composed twelve services when one platform with deep customization would have let them ship weekly.
Each piece is really an argument against a specific kind of over-distribution — across time, across tools, across vendors. The teams that ship are the teams that refuse to fan out until the pain is concrete. Until then, fewer moving parts, tighter ownership, and a surface area the team can actually hold in its head.
1. Why Most Digital Transformations Fail at the Six-Month Mark (original)
Overview
Launch is not the failure point. Month six is. By then the delivery team has rolled off, the executive sponsor is chasing the next initiative, and the operating team is holding a system they didn't scope, didn't staff, and don't fully understand. The steering committee starts hearing about "concerns" that were never on any earlier risk register, and the program gets quietly reclassified as "successful technically, troubled operationally" — which is the polite way of saying it didn't deliver.
Shopify's seven mistakes piece catalogs the usual culprits — weak change management, unclear vision, poor measurement — but understates how time-delayed the damage is. Every mistake plants a seed at month one that only blooms at month six, when launch energy finally burns off.
Technical
The dynamics I keep watching repeat: training half-life (half the team has forgotten the new system by month six and the trainers are gone); integration entropy (three vendors shipped breaking changes, two integrations silently drop records, one is duplicating orders that finance reconciles by hand); dashboard divergence (new numbers run 4% off the legacy ones and nobody trusts either); team turnover compounding (two senior engineers leave and the stack becomes a black box to its own owners); and the promise gap (finance asks which business-case targets landed and discovers most were never measured, because measurement was descoped during delivery).
The transformations that survive month six do three specific things. They keep the delivery team partially attached for nine months with a contractual allocation — eight hours a week of the original architect, not a full handoff cliff. They stand up an operations runbook before cutover, updated weekly for the first quarter, with screenshots and named owners for every workflow. And they report on the business case from week one — if the case promised 20% faster checkout, a dashboard shows checkout speed on cutover day. The dashboard creates accountability and catches drift before it compounds.
Takeaway
If you are inside a transformation program, put the date six months after launch on every senior leader's calendar with a one-line agenda: are we still delivering what we promised? Make it non-negotiable and make the answer measurable. The programs that survive are the ones where someone is paid to remember the original promise. Plan for the operating phase before the delivery phase — delivery ends in six months, operations is forever.
2. Code execution is the universal tool interface I should have built first (original)
Overview
For eighteen months my mental model of agents was: the model picks a tool, calls it, reads the result, picks the next tool. It is the flowchart every introductory post draws. I am now convinced it is the wrong model for any agent that calls more than a handful of tools per task. The right model, argued in Anthropic's Code execution with MCP, is that the model writes a small program, the program calls your tools from inside a sandbox, and only the final result comes back. I resisted for months. My own production numbers finally convinced me.
Technical
The canonical failure case: "find EU customers who spent over $1k in 90 days and haven't ordered in 30." With direct tool calls, the model issues searchCustomers, gets 200 records, fires 200 getOrders calls, stuffs 200 order arrays into context, and filters in natural language. Token cost enormous, latency enormous, and the model does data wrangling badly — it misses records, double-counts, loses date precision. With a code execution tool the model writes a ten-line Python snippet, the sandbox runs it against the MCP namespace, and only the final list comes back. Anthropic reports 90%+ token reductions on representative tasks (~150k to ~2k). I have seen 50× to 100× on my own Klaviyo-and-Shopify cross-tool agents.
The token savings are not even the main point. The main point is correctness. Python and JavaScript are overrepresented in training data. The model writes a correct list comprehension in its sleep. Aggregates computed by sum() are right by definition; aggregates computed by attention over 200 records are approximately right, sometimes. My top-level tool surface is now two tools — execute and a couple of escape hatches like think and askUser. Shopify, Klaviyo, GitHub, Vercel all live inside the sandbox as mcp.* namespaces. The tool list never sits in the system prompt. Advanced tool use pushes the same idea from another angle with dynamic tool discovery — the tool surface is an API the model queries, not a menu pinned to the prompt.
Takeaway
Pick your most expensive agent — the one that calls the most tools per task — and wrap your MCP servers in a code execution tool. Move the prompt from "here are 30 tools" to "here is one execute tool and here are the namespaces it can call." Re-run a representative task and measure tokens, latency, and correctness. You will see a 5× improvement on at least one of the three. Treat your tool surface like an API the model writes code against, not a menu it picks from. Then never go back.
3. The Honest Case for Monolith Commerce in 2026 (original)
Overview
The composable wave has spent five years convincing the commerce industry that monoliths are legacy thinking. Every conference deck, every analyst report, every vendor pitch leads with "API-first," "headless," "composable," and a quiet sneer at the brands still on a single platform. The framing has become so dominant that operators who chose a strong monolith have started apologizing for the choice. In 2026, they shouldn't. Monolith commerce is a deliberate architecture with concrete benefits: faster feature delivery, lower headcount, fewer integration failures, and a surface area small enough that a product team can hold the whole thing in its head.
Technical
Shopify's composable architecture piece is more nuanced than its title. Read carefully, it argues for composition only on differentiating edges, with the vast majority of commerce capability living in a stable monolithic core. That is the honest case for monolith dressed up in composable language, and it is correct. The customizable enterprise platform piece takes it further — deep customization on a stable core produces enterprise outcomes at the lowest operational cost.
The velocity argument is plain. A one-platform stack means one deployment, one rollback path, one credential set, one observability surface, one team. A twelve-service composed stack means coordination across pipelines, monitoring systems, and sources of truth for every feature. The first architecture ships a feature in a week. The second ships it in a quarter. The business agility piece makes the underweighted point that agility is a function of the number of decisions a team has to make to ship — monolith minimizes that number, composable maximizes it. The Shopify Kendo case study is instructive against type: a multi-brand beauty company with the budget to run anything chose a monolith with extensions and ships brand launches at a cadence composable shops envy. Even a team that could afford sophistication picked the architecture with the fewest moving parts.
The honest costs: you give up best-of-breed on some surfaces (your CMS and search will be the platform's), you lose fine-grained vendor leverage (one big contract instead of twelve small ones), and every monolith has customization ceilings that heavy B2B, marketplace, or regulated businesses may hit. If those costs are real for you, compose. For most brands, they are not.
Takeaway
Next time "monolith" gets used as a pejorative in an architecture meeting, ask which specific business capability the team cannot get from a strong base-layer platform. If nobody can name one in concrete terms, you are in a fashion conversation, not an architecture conversation. Pick the architecture that ships the most features per quarter with the smallest team. For most brands in 2026 that is a monolith with deep customization. Ship the boring architecture. Win on the things customers actually feel.
Original sources
- Why Most Digital Transformations Fail at the Six-Month Mark — originally published 2026-03-10
- Code execution is the universal tool interface I should have built first — originally published 2026-03-15
- The Honest Case for Monolith Commerce in 2026 — originally published 2026-03-21
