TL;DR — Seven pieces this week, one pattern: the thing people blame (model, platform, RFID) is almost never the thing that actually breaks. The real failure lives in a product decision, an org chart, or a token budget nobody wrote down.
The theme
Every item this week is an argument against a comforting story. Agent flakiness is not a model problem, it is a product problem. Inventory accuracy is not an RFID problem, it is a comp-plan problem. The million-token window did not solve context engineering, it just gave people a bigger closet to cram. Returns in store fail for political reasons dressed up as integration reasons. Unifying B2B and DTC works, but only when the channels actually share a SKU and a margin model. Headless CMS pays off at exactly two thresholds and is a luxury good below them.
The common shape is this: engineers want the next release to fix the thing. Operators want the next vendor to fix the thing. Both groups are avoiding the work that actually moves the number — rewriting the loop, writing the contract, cutting the context, changing the bonus plan. This week is a stack of reminders to do that work instead.
1. Agent reliability is a product problem, not a model problem (original)
Overview
The loud position on X is that agent flakiness is bottlenecked by the model, and the next Sonnet or Opus will fix it. After shipping a Mission Control orchestrator, a PR worker that opens dozens of PRs a week, and a content generator that drafts 80 posts at a time, I am confident the model is not the bottleneck. The product is. Anthropic's Building effective agents has been saying this politely for a year. The audience that most needs to hear it is still waiting for a smarter weight release to save them.
Technical
The first time I read that post I treated it as a taxonomy — routing, parallelization, orchestrator-workers, evaluator-optimizer, prompt chaining. The second time, after my PR worker had been merging garbage for a week, I noticed the real thesis: start with the simplest thing that could work, and only reach for an "agent" when a workflow cannot carry the weight. Autonomy is a cost, not a feature. Every degree of freedom is a degree of freedom you have to write tests, observability, and recovery for.
My PR worker was an agent because agents are cool. Single loop, single prompt, freedom to do anything the sandbox allowed. Once I refactored the deterministic parts out — classify the task, pick the worktree, detect the test command, run tests — and kept the model only for the code-writing pass, the failure rate dropped about 60% with no model change. The shape that survived production is five steps, four of them deterministic, one of them a narrow subagent with an allowed-tools list and a dollar and turn budget. Anthropic's postmortem of three recent issues makes the point from their side: even the team that trains the model ships reliability regressions through infrastructure wiring.
Takeaway
Write down every step of your current loop. For each, ask whether it needs creative judgment or whether you are being lazy. The lazy ones become deterministic code Monday morning. The creative ones stay with the model, with a tighter prompt and a smaller tool surface. Publish a budget and timeout for every model call. You will find three places where a workflow beats your current agent. Reliability is a product surface most of us never designed on purpose.
2. Returns in store when the order lives on the web stack (original)
Overview
The best five-minute audit of a unified commerce stack is walking into one of your own stores and trying to return an online order. Bring the packing slip, bring the loyalty card, time it from "I'd like to return this" to "you'll see the refund in 3-5 business days." Try it as a customer anywhere — I do, compulsively. It works almost nowhere. The associate calls the help desk, the help desk calls e-comm ops, ops issues a credit the next day, the loyalty points sit in limbo for six weeks. Locally rational, globally broken.
Technical
The flow touches six systems at once — order lookup, payment refund, inventory restock, loyalty reversal, customer notification, store P&L attribution. Lookup breaks when the POS does an external call to the OMS and the response schema omits line-item fulfillment status. Refund breaks because the store uses a different acquirer than the web gateway, so the POS cannot cleanly reverse the original card and falls back to a manual queue the customer does not see. Inventory writes sync on a 30-minute to 24-hour cadence, and during that window the website and the store disagree. Loyalty is the silent killer: the vendor webhook fires on web refunds but not on POS returns, so points stay on the account until reconciliation six weeks later. Store P&L attribution is the political one — managers quietly resist accepting web returns because the return nukes their numerator without adjusting the denominator.
A clean flow looks like this: scan, see the full order in under a second, mark items, refund the original payment instantly, restock in real time, reverse the points, email the confirmation, credit the store without penalizing the P&L. Ninety seconds. That requires unification at the data layer, the payment layer, the inventory write path, the loyalty event model, and the finance attribution model. Most retailers have one or two.
Takeaway
Try this in your own stores next week. Time the return. Note every system the associate touches. Check whether the refund lands within the SLA and the points reverse within 24 hours. The list of failures is your unified commerce backlog, written by the customer experience instead of the vendor slide. If you cannot return an online order in your own store cleanly, you do not have unified commerce.
3. The context window is a budget you spend, not a closet you fill (original)
Overview
When the million-token window dropped, half the agent crowd cheered and the other half quietly admitted it changed nothing. I was in the second camp. What actually moved my agents was treating the window I had as a budget instead of a backpack. Anthropic's Effective context engineering has been making the gentle version of this argument for a year. If you are stuffing the repo, every prior message, and every search result into the prompt, you are doing token taxidermy. The model will appear to remember everything, then quietly degrade on the reasoning step you cared about, and you will blame the model.
Technical
Context is finite, attention is non-uniform, recency and salience compete. Every token you put in costs compute, latency, and a slice of attention the model will not have for the actual work. I run a hard rule now: every context block declares a purpose — tool result, memory, instruction, history — and a role of must-have, nice-to-have, or sourced-on-demand. The nice-to-have blocks fight for inclusion. The sourced-on-demand blocks are not in the prompt at all; they sit behind a tool the agent calls when it needs them.
I keep a literal token ledger capped at 80k, not 200k. Past 80k the model gets measurably worse at following the system prompt, and 80k keeps the prompt cache hot, which is the actual unlock of a large window. Prepending a one-sentence context line to every retrieved chunk before embedding — the Contextual Retrieval trick — took retrieval hit-rate on operational queries from "unusable, the agent fakes it" to "good enough to trust in production." The token cost of those blurbs is rounding-error next to the 8k of background they replaced.
Takeaway
Open your agent loop, find where you assemble the prompt, add a ledger. Mark every block. Drop the nice-to-haves under cap. Move the on-demands behind a tool. Cap at the smallest size that still works — for me that is 60-80k on Sonnet 4.6. Prepend a one-sentence context line to every chunk. You will cut latency, cut spend, and improve recall on the actual question. The window is not your closet. It is your bank account.
4. Headless CMS for DTC: when it actually pays off (original)
Overview
Headless content is on every vendor homepage. The argument is reasonable in the abstract — separate content from presentation, render anywhere, let writers and engineers work in parallel. In practice, for the typical DTC brand running a single .com storefront, headless CMS is solving a problem the brand does not have with a tool the team is not staffed to maintain. There are two thresholds where the investment pays off. Outside them, it is a luxury good. The brands that needed headless got speed and reach. The brands that did not got a Sanity bill and a bottleneck.
Technical
Threshold one: content velocity exceeds the platform's templating ceiling. If editorial is publishing more than ten long-form pieces a week or running campaign pages at SaaS-marketing cadence, the native CMS eventually becomes the bottleneck — not because it is bad but because templating in commerce platforms is optimized for product pages, not editorial. Threshold two: the same content has to render in three or more surfaces — web, app, in-store screen, email, marketplace, separate marketing domain. Below three, you are paying for an abstraction you are not using.
The hidden cost is not the license, it is the content modeling tax. Every new content type needs schema changes, type generation, component work, and a publishing workflow update. For a brand publishing weekly this is fine. For a brand that needs a campaign page on Friday afternoon, it is death. The loudest signal that the investment was wrong-sized is marketers quietly spinning up landing pages in HubSpot or Webflow to escape it. Shopify's Represent case study is a useful counter to the headless-equals-conversions narrative — their 8x Black Friday lift came from site speed and merchandising depth, not CMS abstraction.
Takeaway
Before signing a headless contract, write down two numbers. Non-product content pages published last quarter: if under 30, the native CMS is probably enough. Distinct frontends that will consume the content in the next twelve months, with names attached: if under three, the investment will sit underused. Use the platform CMS until it actually hurts, then revisit. Premature decoupling is premature microservices with a different bill at the end of the month.
5. B2B and DTC on one stack: when to unify, when to fork (original)
Overview
One platform, one catalog, one cart, one customer record — B2B and DTC unified at last. Shopify is the loudest voice in this room and the pitch is honest enough to take seriously. For a lot of brands, unification is right. For a meaningful minority, it is wrong, and the cost shows up eighteen months in when you are trying to ship a B2B-only feature without breaking DTC checkout. The test that decides which side you belong on is three questions: do the two channels share a SKU, a margin model, and a fulfillment shape — today, with no awkward asterisks.
Technical
Seam one, the product. A candle brand sells singles to consumers and 12-packs to wholesale. The 12-pack is not a quantity, it is a different SKU with different packaging and barcodes. One product with variants is cleaner in catalog, messier in inventory. Two products is cleaner in inventory, messier in reporting. Seam two, the margin model. DTC prices risk through ads and shipping. B2B prices risk through receivables and terms negotiation. The "DTC minus 30%" shortcut works for a quarter, then a sitewide promo leaks through the catalog gate and a wholesale buyer pays $9.45 for a $14 item. Seam three, fulfillment. DTC is a parcel out of a 3PL bin with a tracking email. B2B is a pallet on a freight carrier with a BOL, a delivery appointment, and a lift-gate request. Shopify's B2B order management post is honest about this — most of its real estate goes to workflows DTC stores never touch.
Winter '26 closed real gaps — company-level pricing, native PO capture, terms management — and unification is increasingly viable for apparel brands where wholesale orders look like big DTC orders to a store address. For food distributors with case-packs, net-30, and freight, do not force it.
Takeaway
Run the three-seam test this week. Top twenty SKUs: same physical unit across channels? Last quarter's pricing decisions: derivable from DTC, or a separate ladder? Last month's fulfillment: same warehouse process? Three yeses, unify. One no, fork — and fork lightly, two stores in one org, before you fork heavily into two platforms. The cost of forking is two of everything. The cost of forcing unification across a real seam is feature paralysis, which is more expensive by a factor of ten.
6. Why multi-agent beats long-context for the work I actually ship (original)
Overview
The long-context-versus-multi-agent debate has been going a year, and the loud half of X is on team long-context. Just stuff everything in, modern attention can handle it, why introduce subagents and orchestration. I shipped both architectures into my Mission Control PR worker. One of them still works on Friday afternoon when I am out. It is not the long-context one. Anthropic's How we built our multi-agent research system is the most honest writeup of what actually makes this pattern work.
Technical
The seductive thing about a long context is that it lets you avoid making decisions. Don't filter, don't chunk, don't summarize — just dump and let attention sort it out. This works in demos because demos are short, the input is curated, and the question is well-formed. Production is none of those. The failure I have hit at least four times: an agent runs a multi-step task — find the issue, write the fix, run the tests, open the PR — and by the PR description step it is still attending to the failing test output, the original issue, the diff, the file tree, and an hour of its own intermediate thoughts. The description it writes is competent but generic. It misses the point because the point is buried in turn 3 of a 9-turn loop. I have watched this happen on Sonnet 4.5, Sonnet 4.6, and Opus 4.6.
The multi-agent fix splits the work. Orchestrator never sees raw outputs, just summaries. Each subagent sees only the slice of context it needs. The Anthropic number people do not like is that their setup uses roughly 15x the tokens of a single chat. That scared me off for months. Then I measured. My single-agent PR worker cost $0.80 and failed 38% of runs. The multi-agent version costs $2.10 — roughly 2.5x because most of my subagents are short — and fails 9%. I am happy to pay 2.5x for that. The structure I use is four subagents in series: planner, coder, verifier, writer. The writer sees summaries, crucially not the raw diff.
Takeaway
Take your long-context agent and split it into two pieces: a planner and a doer. The planner reads the task and high-level context, writes a 200-token plan. The doer takes the plan and only the relevant files, executes, and returns a summary. Run them as separate calls with separate prompts. You will see a measurable drop in failure rate by Wednesday. Split the doer into coder plus verifier when you are ready. The unit of agent design is the subagent, not the megaprompt.
7. Inventory accuracy is a political problem, not a technical one (original)
Overview
I have sat in too many meetings where the conversation goes like this. Director of digital: the website said it was in stock, the customer drove there, it wasn't. Director of stores: supply chain issue. Director of supply chain: receiving didn't scan correctly. Director of stores: we don't have the labor. Everyone looks at the CIO. The CIO mentions RFID. The meeting ends without a decision. That meeting will happen again next month. It will end the same way. Inventory accuracy is a political problem about who owns the number, who gets blamed when it is wrong, and whose budget pays for the work to make it right.
Technical
Industry-average SKU-by-store accuracy is 60-85% depending on the study. Retailers claiming 95%+ are measuring at warehouse total instead of SKU-store, or they are small-format operations like Apple or Lululemon flagships where the org structure is built around inventory discipline. Every percentage point has a political cost. 80 to 90 is software and process. 90 to 95 is behavior and incentives. 95 to 98 is org chart redesign. The technology gets cheaper at every step. The politics get harder.
Four failure modes keep repeating. The person who counts is not the person measured on accuracy. Cycle counts are scheduled around labor rotations instead of risk. Shrink and miscount are the same finance line item, so there is no pressure to disambiguate theft from mis-scan. RFID gets pitched by vendors, paid for by IT, benefits the stores, and dies at year three when budget tightens. What works is an explicit accuracy contract between digital and stores: the site shows counts only above 92%, stores run a daily 30-minute risk-weighted cycle count, a jointly-owned team maintains the dashboard, and 10-15% of store manager variable comp is tied to the accuracy KPI. This is not a technology project. It is a series of meetings and a comp plan change.
Takeaway
Pick one store. Walk it next week. Pull the system count for the top 50 SKUs, physically count them, calculate accuracy. It will be lower than you expect. Then ask the manager what would have to change for them to care about that number. The answer will not be better software. It will be some combination of give me the labor, tell me what is at risk, stop blaming me for the receiving team, and put it in my bonus. That conversation is the roadmap your accuracy work actually needs. No platform vendor can have it for you.
Original sources
- Agent reliability is a product problem, not a model problem — originally published 2026-01-26
- Returns in Store When the Order Lives on the Web Stack — originally published 2026-01-27
- The context window is a budget you spend, not a closet you fill — originally published 2026-01-28
- Headless CMS for DTC: When It Actually Pays Off (And When It Doesn't) — originally published 2026-01-29
- B2B and DTC on One Stack: When to Unify, When to Fork — originally published 2026-01-30
- Why multi-agent beats long-context for the work I actually ship — originally published 2026-01-31
- Inventory Accuracy Is a Political Problem, Not a Technical One — originally published 2026-02-01
