ExpertsFM

(Preview) All About Agents: Dots Arrive, Google and Apple Questions, Muse Follow-Ups, Super Intelligence, and the Mandate of Heaven

Sharp Tech with Ben Thompson · October 2, 2026

5 Selected Lessons:

heuristic · 3 reasoning_pattern · 2
Mutual-interest partnerships hidden inside platform agentic deals
reasoning_pattern based on: reasoning Ben Thompson

Source

Sharp Tech with Ben Thompson — (Preview) All About Agents: Dots Arrive, Google and Apple Questions, Muse Follow-Ups, Super Intelligence, and the Mandate of Heaven (October 2, 2026) · at 2:11 ▸

When this applies

when evaluating a partnership between a platform and a service provider where one side's product becomes a distribution surface for the other's core revenue stream

The takeaway

Look past apparent competitive overlap to ask whether a deal actually substitutes one party's revenue mechanism with the other's, or preserves it under new interface — incumbents may root for an 'intruder' if the intruder channels revenue back to them.

Why it works

If a partner's product (the agent) can deliver on functionality while still surfacing the other partner's existing monetization (ads/products), that preserves the incumbent's revenue, making the deal mutually beneficial rather than purely competitive.

One level up

Analyze ecosystem incentives, not just stated competitive positioning, to understand why unlikely alliances form.

Where it stops holding

This stops working when the new interface fully disintermediates the incumbent's ability to capture revenue (e.g., the agent suppresses ads entirely).

Detail

approach: Trace what revenue mechanism the incumbent depends on, then check if the new product preserves or destroys it when integrated.
signals:
  • agent surfaces partner's ads/products as part of its answers
  • partner's ad business is not harmed by the agent's success
rationale: A platform will favor an agent's success if the agent still serves as a conduit for its existing monetization.

In their words

that that is a way for Amazon to deliver on sort of the external agentic
Apps get harder to use over time despite being a historic improvement
reasoning_pattern based on: reasoning Ben Thompson

Source

Sharp Tech with Ben Thompson — (Preview) All About Agents: Dots Arrive, Google and Apple Questions, Muse Follow-Ups, Super Intelligence, and the Mandate of Heaven (October 2, 2026) · at 7:06 ▸

When this applies

when judging whether an incumbent interface paradigm (apps, dashboards, any UI layer) is still serving users well just because it was once a major improvement

The takeaway

Don't assume a dominant interface paradigm is still the best experience just because it was once a major upgrade over its predecessor — re-evaluate current friction independently of historical context.

Why it works

An interface paradigm's initial superiority over what preceded it gets mistaken for permanent optimality; in reality the paradigm can degrade (bloat, login friction, fragmentation) while people still assume 'this is the best it can be' because of anchoring to its original launch improvement.

One level up

Periodically re-test whether an incumbent solution still earns its dominance, rather than extrapolating from its original disruption.

Where it stops holding

This stops working when the paradigm has actually kept pace with needs and genuinely remains the best available option, not just the incumbent by inertia.

Detail

approach: Compare the current lived friction of using the dominant paradigm (app logins, 2FA churn, hundreds of apps) against the narrative that it's still 'the best experience,' and flag the gap as an opportunity.
signals:
  • accumulating app count without usability
  • friction from account/security management
  • painful migration costs (e.g., switching ecosystems)
rationale: The reason Ben is optimistic about agents is that the current dominant paradigm has quietly degraded in usability, creating real room for a pain-relief alternative.

In their words

Apps on an iPhone were way better than what came before, but there is a mindset that sort of looks at the world as apps were so much better than before, therefore apps are the best experience
Switching cost aversion when the current solution is 'fine'
heuristic based on: lived experience Ben Thompson

Source

Sharp Tech with Ben Thompson — (Preview) All About Agents: Dots Arrive, Google and Apple Questions, Muse Follow-Ups, Super Intelligence, and the Mandate of Heaven (October 2, 2026) · at 7:06 ▸

When this applies

when deciding whether to switch platforms/tools/vendors purely because of anticipated future downside, while the current option still works adequately

The takeaway

Don't pay a switching cost now against a merely anticipated (not yet realized) problem if the current solution is still functioning acceptably — the one-way switching cost compounds if you might need to reverse it.

Why it works

The pain of migration (re-setup, re-learning, potential reversal) can outweigh the speculative future benefit, especially when reversal itself carries a second full switching cost.

One level up

Weigh total round-trip switching cost, not just the one-way cost, when deciding whether to preemptively abandon a working solution.

Where it stops holding

This stops working when the anticipated future problem is near-certain and severe enough that delaying migration only increases total pain (e.g., regulatory deadline, imminent discontinuation).

Detail

situation: Ben anticipated big Mac price hikes and told others to buy computers before the hikes, but his own Mac still worked fine.
decision: He started migrating to test an alternative for a week but stopped halfway, deciding the round-trip pain (migrate, possibly dislike it, migrate back) wasn't worth it.
outcome: He kept his existing Mac setup, foregoing the hedge against future price hikes.
lesson: When a current tool still works, the compounded cost of migrating and potentially reversing can outweigh a speculative future benefit.

In their words

I got halfway through migrating, and it's like, this is so painful that if I go through with this and I don't like it, I'm gonna have to do the same thing all over again in the opposite direction. And I
Thread-per-task beats one giant ongoing thread for agent context
heuristic based on: lived experience Ben Thompson

Source

Sharp Tech with Ben Thompson — (Preview) All About Agents: Dots Arrive, Google and Apple Questions, Muse Follow-Ups, Super Intelligence, and the Mandate of Heaven (October 2, 2026) · at 11:03 ▸

When this applies

when managing context/memory for any system (agent, team process, documentation) where accumulated history can start degrading decision quality

The takeaway

Segment accumulated context by task boundary rather than letting it grow indefinitely in one continuous stream, and persist key facts externally so they can be reloaded fresh rather than relying on them staying salient inside a bloated context.

Why it works

As a single context window accumulates more history, the original instructions get buried far back in context, causing the model's reasoning to become more confused; starting a fresh thread per task keeps instructions proximate and relevant.

One level up

System performance degrades with unmanaged accumulation of state; deliberate segmentation and external persistence counteract this.

Where it stops holding

This stops working when tasks are so interdependent that splitting into separate threads loses necessary continuity the agent needs to perform well.

Detail

rule: Use one thread per task rather than one massive ongoing thread; have agents 'write things down' externally so fresh context can be reloaded as needed.
threshold: Bigger context = more confusion; a model's own early instructions become functionally lost once buried deep in a long thread.
rationale: Larger context windows don't fix this because the problem isn't token capacity but attentional dilution/staleness of early instructions.

In their words

The way they actually function well is continually writing things down. And the way they keep track of stuff that's written down is by having relatively fresh context and then loading stuff in as it's sort of appropriate
Dedicated app vs. bundled-tab tradeoff for discoverability vs. usability
heuristic based on: reasoning Ben Thompson

Source

Sharp Tech with Ben Thompson — (Preview) All About Agents: Dots Arrive, Google and Apple Questions, Muse Follow-Ups, Super Intelligence, and the Mandate of Heaven (October 2, 2026) · at 17:55 ▸

When this applies

when deciding whether to bundle a distinct feature inside an existing flagship app or ship it as its own standalone product

The takeaway

Weigh incremental discoverability gained from bundling against the usability cost imposed on users with a clear, specific intent — the right choice depends on which user group (discoverers vs. intentional users) you most need to serve.

Why it works

Bundling inside an already-installed app increases the chance users who wouldn't otherwise seek out the feature will discover it, but it also forces unrelated functionality into a shared navigation structure, degrading usability for users who already know what they want.

One level up

Distribution convenience and user experience quality often trade off against each other; be explicit about which one you're optimizing for.

Where it stops holding

This stops working when the bundled feature is used by the exact same audience as the host app with no distinct workflow needs, in which case bundling has no usability downside.

Detail

rule: Consider a standalone app for a distinct-workflow feature instead of burying it as a tab inside a flagship app, unless the discoverability benefit for new users clearly outweighs the usability cost for existing power users.
threshold: N/A
rationale: This having to go into a little thing to get to your thing... it just makes for a really crappy user experience.

In their words

By the way, why both Anthropic and OpenAI, why is there not a dedicated quad code app and a dedicated Codex app? This having to go into a little thing to get to your thing, it just drives me by