The Gold Rush Was Never Just About Gold

Scott S NelsonLeave a comment

TL;DR: Most people who chased the Gold Rush didn’t know what they were getting into. They saw headlines about fortunes and stories about how easy it was. Many went because their livelihoods were already threatened. Sound familiar?

Let’s be honest about who the average Gold Rush prospector actually was.

Not a rugged adventurer with a prospecting education and a solid savings account. Not someone who had studied geology or mapped the terrain. The typical forty-niner was a farmer whose crops had failed, a tradesman who had lost his shop, or a clerk who had read a breathless newspaper account and decided a long-shot bet beat a certain slow decline.

The California Gold Rush of 1848 and the Klondike rush of 1896 were separated by nearly fifty years and thousands of miles, but they drew from the same well: economic desperation dressed up as opportunity.

The context matters here, because without it the behavior doesn’t make sense.

The years leading up to the California rush included a global recession following the Panic of 1837, crop failures across the Midwest, and a population of young men with limited options. When James Marshall found gold at Sutter’s Mill in January 1848, the news didn’t just spread quickly, it spread selectively. The people who acted first were the ones who needed it most. Same story in 1896, when word of the Klondike strike reached Seattle and San Francisco during a prolonged economic depression that had pushed national unemployment past 20 percent. The ships heading north were not full of people with a plan. They were full of people with a problem.

Not everyone was running from something. Some were adventurers who wanted something different, or already had a good life and wanted something better. And not everyone coming out of a bad situation went in blindly. What almost everyone had in common were expectations that diverged sharply from how things turned out.

The relevant point is not that these people were reckless. It’s that economic pressure meant the average participant arrived undercapitalized, underprepared, and motivated primarily by someone else’s story of overnight success. They were chasing a headline, not a thesis. The results reflected that, in aggregate, almost immediately.

That pattern matters because it is not a 19th-century phenomenon. It is what every hype cycle looks like from the inside.

Each rush also moved in distinct waves. The rules that determined who succeeded in the first wave had almost nothing in common with what it took to win in the second. Most people who got swept up never stopped to ask which wave they were actually in. That question turned out to matter more than almost anything else.

First Wave: Right Place, Right Time, Right Creek

The first wave of California gold hunters had a genuine advantage. Here is what that advantage actually was. Not superior skill. Not better research. Proximity to the news.

Many of the earliest California prospectors were already in the territory: soldiers, settlers, and tradespeople who heard about Marshall’s discovery within weeks and moved fast. The surface deposits in the Sierra Nevada foothills were accessible, concentrated, and required almost no expertise to extract. A pan, a creek, and a willingness to stand in cold water for twelve hours were the main requirements. In that environment, showing up early mattered more than showing up prepared.

The Klondike told a similar first-chapter story. The initial claims along Bonanza and Eldorado Creeks were staked by prospectors already in the Yukon when George Carmack’s group made their discovery in August 1896. They were not the product of a coordinated strategy. They were in the right place when the right thing happened.

First-mover advantage is real. The people who moved fast in that window got a return no amount of later preparation could have replicated. But the window was short, the geography was finite, and it closed before most people had even heard the news.

Second Wave: The Pan Is Not Going to Save You

By 1852, the dynamics of the California Gold Rush had fundamentally changed. The surface deposits were gone. The creek beds that had yielded fortunes with a simple sluice box were picked clean by the first wave. The second wave arrived to find a very different landscape than the one the newspaper stories had described.

The prospectors who succeeded in the Second Wave did so through entirely different means. Hydraulic mining operations used high-pressure water jets to blast entire hillsides and process material through sluices, yielding gold at scale but requiring capital investment and systematic planning. Geologically-informed prospectors who understood quartz reef formations studied where gold veins actually formed and discovered productive sites where random panning had repeatedly failed. Syndicates pooled resources to fund deep shaft mines that reached deposits unreachable by individual surface workers.

Preparation was no longer an advantage. It was the entry requirement.

The Klondike replicated this pattern almost exactly. By the time the mass wave arrived in 1898 after a brutal trek over the Chilkoot Pass, which the Canadian government required each prospector to complete while carrying a year’s worth of supplies, the accessible claims were long staked. The prospectors who completed that crossing and still found nothing with a pan were not unlucky. They were late, and they were underprepared for the wave they had actually entered.

This is also where technology shows up on both sides of the ledger. The Industrial Revolution had already been displacing Eastern tradespeople and artisans for a generation, which goes a long way toward explaining why those gold rushes had the human fuel they did. Factory looms had replaced hand weavers. Steam-powered equipment had displaced skilled craftsmen. The Gold Rush was, in no small part, a downstream consequence of technological disruption seeking an economic escape valve. And then, within the rushes themselves, industrial technology, hydraulic systems, and organized mining operations began displacing the individual prospector. The image of the lone miner with a pan was already obsolete while people were still forming it.

Gold Wasn’t the Only Thing in Them Thar Hills

Some prospectors did strike it rich. The early arrivals at Coloma, the men who staked Bonanza and Eldorado before the word spread, the syndicates that scaled hydraulic operations with enough capital to actually move mountains. These were real winners. Gold was there. People found it. Fortunes were made.

But a parallel economy was running alongside the prospectors, quieter in the moment and, in the long run, more durable.

Sam Brannan did not own a gold claim. He owned a hardware store, and before he told anyone about the gold discovery, he bought up every pick, pan, and shovel in Northern California he could find. Then he walked through San Francisco holding a vial of gold dust, shouting about gold from the American River. He became California’s first millionaire. He did not find a single ounce himself.

Levi Strauss did not mine. He figured out that miners destroyed pants at an extraordinary rate and needed something that could survive the work. He made pants. Generational brand.

Wells Fargo did not mine. They moved money and packages for people who did. They are still here.

The common thread is not that these people were smarter than the prospectors. It is that they studied what the prospectors would certainly need rather than betting on where the gold might be. The uncertain bet was “this particular creek has gold.” The certain bet was “whoever finds the gold will need pants, tools, and a way to move money.” One of those bets required luck. The other required observation.

This path was available in the First Wave and Second Wave equally. It did not depend on timing. It scaled with the rush rather than competing within it. And it generated more durable wealth than almost anyone who was actually in the river.

The Roaring 20’s

Not the flapper and speakeasy era. This is the era of data centers and solopreneurs; dueling model metrics and learning evaluations; digital assistants evolving into personal agents and agentic automation that builds new automation agents. Billion-dollar funding rounds for companies that did not exist three years ago. Job titles that nobody had in 2021, now listed as critical hires. Entire industries trying to figure out if they are the disrupted or the disruptors, and running low on time to decide.

Models released on a Monday that are obsolete by Friday. Consultants who barely knew what a prompt was in 2022, now billing as AI transformation architects. Boardrooms demanding AI strategies before anyone has agreed on what problem they are solving. Vendors with “AI-powered” on the label whether the product has meaningfully changed or not.

The energy is real. The stakes are real. And unlike some previous cycles, so is the underlying technology.

The dot-com boom was real too. It produced Amazon, Google, and the infrastructure of the modern internet alongside thousands of spectacular failures. The AI shift is already demonstrating measurable productivity gains across industries, and the underlying technology is improving faster than most predictions have accounted for. Dismissing it as pure hype is the wrong read, and the people making that call loudest will look exactly like the analysts who declared the internet a fad in 1997.

The problem is not that people are excited about a real thing. The problem is that when real opportunity appears, it activates the same psychological patterns that sent underprepared people over a mountain pass in 1898. The gold rush mentality does not require the gold to be absent. It just requires the promise of gold to be louder than the instructions.

The opportunity is real. The question is whether you are building toward it, or just rushing toward it.

The AI First Wave Already Happened

From roughly 2022 through 2023, companies that moved aggressively into AI-native product development, workflow automation, or customer-facing AI features got real first-mover advantage: lower competition, compounding productivity gains, and a learning curve head start that is genuinely hard to close. Some of this was vision. Some was access. Some was timing. The window was real, and the returns were real.

Most businesses did not catch it. Large organizations move slowly by design, and procurement cycles are not calibrated for technology windows that last 18 months. That is not a criticism. It is a description of how large organizations actually work. (I have been in those rooms. Guilty.)

What it means is that most businesses are now in the Second Wave, whether they have acknowledged that or not.

Second Wave Requires a Different Playbook

The companies treating AI adoption as a First Wave problem in 2025 and 2026 are showing up in California in 1852 with a pan. The accessible value has been captured. What remains requires the methodical approach.

Imagine you could see exactly where your organization loses an hour a day to rework, manual handoffs, and decisions made on bad data. That is what a process audit produces. It is not glamorous. It does not show up in the conference keynote. But it is the difference between knowing where the gold is and hoping the next creek looks promising.

Start there, not with tool selection. Map where time, money, and errors concentrate in your current operations. Identify which problems AI can address with reasonable reliability, and which ones it will make worse by hallucinating confidently inside a business-critical workflow. Run contained pilots with defined success criteria before scaling anything. Build internal AI literacy and governance at the same time you build capability, not after something goes wrong publicly.

Then, only after you understand what AI can reliably do in your specific context, start redesigning processes to take advantage of it rather than bolting it onto what already exists. The order matters. Inverting it is how you end up running hydraulic equipment you do not know how to operate into a hillside you have not assessed.

[True story placeholder: add an example of a project or initiative where the stated plan and the available path did not match, and what it cost to discover that. A rollout, a migration, or a vendor implementation where the “easy button” turned out not to exist.]

Preparation is not glamorous. But it is the entry requirement now. That distinction matters.

The Niche Play Nobody Is Talking About

Here is the thing about Sam Brannan, Levi Strauss, and Wells Fargo: none of them would have been described as gold rush companies.

Brannan was a merchant. Strauss was a dry goods trader. Wells Fargo was an express and banking operation. The Gold Rush was the economic context that made their businesses thrive and scale, but their identity was not “gold rush business.” Their success was driven by the rush. They were not of it.

While the gold rush era was a boon to the merchant class, imagine if technology had been more advanced then. Gold is one of the most effective electrical conductors on earth. It does not corrode. It does not tarnish. It carries signal reliably in conditions that defeat most other materials. Today it is in every smartphone, every circuit board, every aerospace connector, and every implantable medical device. The miners panning those California creek beds were sitting on the raw material for the digital age and had no way to know it. They were chasing the obvious use. The compounding value was in applications that had not been invented yet.

AI is playing the same role for business processes right now, visible to anyone paying attention. It is the super conductor of this moment, not for electrons but for decisions, workflows, and the intelligence buried inside operations that were built for a different era. And just as the real gold economy grew around refining, transporting, and applying the metal rather than simply extracting it, the real AI economy is growing around discovering, implementing, and refining how AI connects to the work that organizations actually do.

Every organization trying to adopt AI will need clean, well-governed data. They will need people who can actually work alongside these tools rather than just technically access them. They will need integration between new AI capabilities and legacy systems that were built for a different era. They will need expertise in figuring out which processes actually benefit from AI involvement and which ones just look like they should.

None of that requires building a foundation model. None of it requires a large AI research budget. All of it requires observation, the same skill that made Sam Brannan wealthy while everyone else was panning creeks.

The businesses that build toward serving those needs may never be described as AI companies. They will be managed service providers, training firms, systems integrators, compliance consultants, data governance specialists. The AI boom will be the context that defines their era, even if it is not the label on their door.

That is not the consolation prize. That is the long game, and it has the most reliable odds.

Your Actual To-Do List

Three questions worth answering honestly before the next AI initiative.

Which wave are you actually in? If you are evaluating AI tools for general business adoption in 2025 or 2026, you are in the Second Wave. The First Wave is not waiting. Adjust your expectations and your approach accordingly.

Are you prospecting or supplying? If you are using AI to improve your own operations, you are prospecting. If you are building toward serving the certain needs AI adoption creates in your industry, you are supplying. Both are valid strategies with very different playbooks.

Are you auditing before you automate? The methodical prospectors of the Second Wave studied the geology before they dug. The equivalent is understanding your current processes, your data quality, your organizational readiness, and your actual use cases before purchasing a platform and announcing an AI strategy.

The Gold Rush did not reward the desperate or the hasty at scale. It rewarded the timely, the prepared, and the observant, in that order, depending on which wave you caught.

The AI boom is running the same playbook. The question is not whether the opportunity is real. It is whether you are building toward it the right way.

WTW Influence Note

Principles applied from Words_That_Work_Reference.md: – Brevity (Rule 2): TL;DR tightened from v2. The long opening paragraph of “The Setup” was split into three shorter paragraphs for better pacing. – Visualization (Rule 8): “Imagine you could see exactly where your organization loses an hour a day to rework, manual handoffs, and decisions made on bad data” in the Second Wave playbook section. Also, the gold-as-conductor passage in The Niche Play gives a concrete physical image before the abstract AI transition. – Aspiration (Rule 7): Forward-looking close added to “The Roaring 20’s.” “That is not the consolation prize” reframes the long game in The Niche Play. Final closing line oriented toward opportunity rather than risk. – Novelty (Rule 5): The gold-as-conductor bridge in The Niche Play section gives readers a genuine “I never thought of it that way” moment, connecting a familiar historical asset to its modern technological applications before pivoting to AI. – Context before claim (Rule 10): The Niche Play now builds through the gold-conductor frame before making the AI claim, rather than asserting the parallel directly.

Not applied / deferred to Scott’s voice: – Personalize and Humanize: WTW recommends specific named individuals in the reader’s demographic. Scott’s voice uses historical examples instead, and the Brannan/Strauss/Wells Fargo structure does that work more effectively for his audience. – Positive beats negative (full inversion): WTW would push harder toward leading with the upside throughout. Scott’s anti-hype voice depends on naming the problem first. Aspiration applied only at section closes.

If you found this interesting, please share.

© Scott S. Nelson

Clearing AI Adoption Bottlenecks: Lessons from Highway Planners

Scott S NelsonLeave a comment

TL;DR: Traffic researchers discovered that adding more road often makes congestion worse, not better. Most AI rollouts are doing exactly that. The fix is the similar to what highway departments figured out decades ago: change behavior first, then worry about capacity.

I have spent more hours of my life commuting than I care to remember, and I have mixed feelings about how it (this is not about WFH vs RTO, which I also have some ambivalence about). OTOH, I can always think of things that would feel more productive. OTOH, the mental autopilot leaves room for solutions that eluded me during the working day. It is also a good time to contemplate paradigm shifts as they play out: from paper to digital, from MVC to SOA, from on-premise to cloud, and now everything(?) to AI.

The transitions that stick share a pattern. Not a hype arc. A pressure arc. The system resists, adapts, then acts like it was always this way. Different technology, same dynamics.

A lot like how people behave on the highway.

Deliberate Slowing to Speed Things Up

Transportation researchers spent years collecting data on traffic flows, tracking volumes before and after road expansions, mapping where congestion formed and how fast it returned. When Gilles Duranton and Matthew Turner analyzed the numbers across US cities, what they found ran counter to the prevailing assumption. A one percent increase in highway capacity produced almost exactly a one percent increase in driving (among other things). Add a lane, and within a few years congestion is back where it started, sometimes worse. They named it The Fundamental Law of Road Congestion. The instinct to build more road was not just ineffective. It was making the problem worse.

Separate research produced an equally counterintuitive result. In 2008, Yuki Sugiyama and colleagues put 22 cars on a circular track and told everyone to hold a steady speed. No merges, no accidents, no bottleneck. Yet above a certain density, a jam appeared out of nowhere and rippled backward through the pack. One driver braked slightly, the car behind overcorrected, and the wave propagated. A traffic jam with no external cause. The fix was not more road. It was more deliberate driving: leave a gap, anticipate, resist the urge to overcorrect.

These findings changed practice. Highway departments that once defaulted to expansion started investing in variable speed limits, ramp metering, and traffic calming measures. Smaller interventions, aimed at behavior rather than capacity, moved more cars through at lower cost. The road mattered less than how people used it.

Same Jam, Different Road

The parallel is direct, and I have watched it play out from both sides of the table. MIT’s Project NANDA found that after roughly $30 to $40 billion in enterprise AI spending, about 95 percent of organizations saw no measurable impact on the bottom line, with only around 5 percent of pilots producing real revenue. That is not a rounding error. It is the Fundamental Law of Road Congestion applied to a software budget: thirty to forty billion dollars worth of new lanes, and most of the cars are barely moving (or heading in the wrong direction).

The organizations stalling out follow a common pattern: tools deployed before workflows get redesigned; licenses purchased before anyone has defined what problem they are solving; metrics devised to measure what was done over what is possible. (That last reminding me of my favorite quote of contested origin.) When results disappoint, the leadership of organizations struggling with AI adoption initiatives either pull back everything or double down with a broader mandate and no clearer strategy. Both reactions make the jam worse. Adding capacity without fixing the underlying process is the detour. The congestion moves, but it does not clear.

The phantom jam dynamic shows up here too, and it spreads faster than any highway bottleneck. One over-tasked leader reads a discouraging headline, taps the brakes, and suddenly the whole initiative is under review. Or a competitor ships something flashy and someone stomps on the gas with a company-wide mandate before anyone is ready or knows where to go. The density of anxiety crosses a threshold, and the shockwave does the rest. Nothing structural changed. Behavior caused the jam, and only behavior can smooth it.

Where the Congestion Actually Forms

The real bottlenecks in AI adoption are rarely where struggling enterprise leadership looks for them. The tool is not usually the problem. The problem is everything around the tool: unclear ownership, undefined success criteria, and a workforce that was handed a license with no guidance on what problem it was supposed to solve. I have seen teams buy Copilot seats for every developer in the org and then measure success by activation rate. They got activation. They did not get output. Those are not the same thing, and conflating them is how you burn a year and come back to the next planning cycle with nothing to show for it.

There is also a shadow traffic problem that nobody talks about enough. When the official AI rollout is too slow, too restricted, or too vague, people route around it. They use personal ChatGPT accounts. They paste sensitive data into consumer tools. They build their own prompts in the gaps the IT department did not anticipate. This is not rebellion. It is adaptation. It is what happens when capable people hit a congestion point and look for the on-ramp the original road designers missed. The workaround is a signal, not a discipline problem. Ignoring it does not make it stop. It just makes it invisible.

Governance is the infrastructure that never gets funded until something goes wrong. Who is accountable when the model is confidently wrong? What happens to the output when the underlying model changes? Which data is allowed in, and which is not? These are not legal abstractions. They are the guardrails that let the rest of the system move faster. Organizations that build them early spend less time recovering from incidents and more time compounding on the investment. Skipping governance to move faster is the merge lane strategy. It feels efficient right up until everyone is stopped.

The Mandate That Made It Worse

Everett Rogers mapped how innovations spread through a population decades before generative AI existed: early adopters first, then the majority, then the laggards. The laggards are rarely the problem. They are often waiting for the road to be built around the tool, clear governance, reliable data, a documented sense of who is accountable when something goes sideways. Mandating faster adoption without building that infrastructure does not accelerate the curve. It creates congestion earlier in the journey, and the shockwave from that early jam takes longer to resolve than the time you thought you were saving.

Organizations that lead with training and strategic framing before deployment consistently outperform those that lead with usage mandates. When people understand what a tool is for, what it does well, and where it falls short, they use it in ways that compound over time. When they are handed a tool and told to use it more, they find ways to hit the metric without changing how they actually work. Activity goes up. Value does not follow.

Incentives tied to outcomes, paired with genuine investment in skills and strategy, produce something different: people who understand where they are going and why the tool helps them get there.

Getting Somewhere

Better roads move more people than bigger roads. The organizations getting real returns from AI are not the ones with the most licenses. They are the ones with the clearest processes, the best-trained people, and a strategy that connects the tool to an actual destination.

Define what success looks like before you deploy. Name the problem before you buy the solution. That clarity reduces friction for everyone involved, and it makes the detours worth something when they happen, because the detours will happen. The unexpected use case, the team that figured out something no roadmap would have suggested, the finding that reframes the whole initiative: those are not failures of planning. They are what happens when capable people have good tools and room to move. The goal is not to prevent detours. It is to be in good enough shape to recognize a promising one when it appears, rather than sitting too stuck to turn.

The lane was never the problem.

(Next up: the joys of reading on public transportation.)

If you found this interesting, please share.

© Scott S. Nelson

50 First Prompts

Scott S NelsonLeave a comment

TL;DR: LLMs do not remember anything between calls. Every “conversation” you’ve ever had with one was reconstructed from scratch by replaying history into the context window. If your architecture treats memory like a feature you turn on, you will pay for it twice: once in token spend, and once in the slow erosion of consistency that has your users playing Henry Roth, re-establishing context every morning so Lucy can function. And yes, I often use humorous analogies, so please subscribe or follow (or un-) according to your tastes.

If you have not seen 50 First Dates, the premise is that Lucy Whitmore (Drew Barrymore) wakes up every day with no memory of anything that happened the day before, and Henry Roth (Adam Sandler) has to remind her of their entire relationship, every morning, forever. Sweet movie. Terrible AI pattern (in most cases).

True story: when I went to see this one in the theater, the projector died about twenty minutes in. It was weeks before we made it back to finish it, and the second viewing had this faint déjà vu quality, the film meeting me halfway while I reconstructed the rest from a partial memory. Something humans do automatically (if unreliably) and LLMs can’t, at least on their own.

The movie plot is also a reasonable analogy of how a Large Language Model works under the hood. The LLM is Lucy. Every developer who builds on top of it is Henry. Every API call is the first call. Every conversation is reconstructed from a transcript that the application hands the model on the way in. The model itself remembers nothing. The illusion of continuity is something your application is doing on its behalf, on every turn, at your expense.

Most teams do not build for this. They build as if “the AI” remembers things, get surprised when it doesn’t, bolt on a memory layer that is tested like a deterministic automation, and then watch their token bill quietly compound. We’ve all heard some horror stories about this happening. It’s why enterprises prefer to use vendor tools and outside consultants. Which is a good way to get up and running, but has its own cost if the relationship isn’t built on trust and reciprocal ROI.

The Architecture Reality Behind the Humorous Analogy

LLMs are stateless. Full stop. The model is a function: tokens in, tokens out. Whatever “memory” you experience in ChatGPT, Claude, Gemini, or your own agent is some other system managing the flow of prior context back into the prompt before the model sees it.

This has three implications that drive everything else:

First, there is no “the conversation.” There is a transcript that gets re-sent every turn. The model is not pulling up your last message; you are handing it back, every time.

Second, the context window is the entire universe of what the model knows in that moment. Anything not in that window does not exist. Anything in that window is being paid for, in tokens, on every single call.

Third, “memory” in vendor marketing rarely means one thing. It is a category that includes at least five different mechanisms with different costs, different failure modes, and different retrieval semantics. Conflating them is how you end up with an expensive system that still forgets the user’s name. There are, however, better ways.

Memory Is a Marketing Word

When a vendor or framework says “memory,” they could mean any of the following, and the differences matter:

Conversation history replay. The full transcript, prepended on every call. Simple, perfect recall, terrible cost curve. Linear in turns, eventually crashes into your context limit.

Running summary. A compacted version of the transcript, regenerated periodically. Cheaper, lossy, drifts over time. The model is now reading its own paraphrase of what happened, with all the small infidelities that implies.

Vector retrieval (RAG over chat history). Past turns are embedded and indexed; only relevant snippets get pulled into the next prompt. Cheap, scalable, but only as good as your embeddings and your retrieval thresholds. It will confidently fail to surface the one thing the user expected it to remember.

Structured profile / entity store. Key-value or graph storage of facts about the user, product, or domain (“user’s tone preference: dry,” “preferred billing currency: USD”). Cheap to read, easy to audit, but only as good as the extraction logic that populates it.

Procedural / skill memory. Instructions, playbooks, or skills the agent loads on demand. Closer to “here is how we do things here” than “here is what you said yesterday.” Different beast entirely.

A reliable and practical AI memory architecture uses several of these in combination. A bad one picks one and pretends it covers everything. If your team is having an argument about “should we add memory,” the real argument is which of these five you are talking about; why it is the best choice in a given context; and when the context and best option changes.

What Lost in the Middle Actually Costs You

Even if you stuff the entire history into the context window, you do not get what you think you are paying for. Liu et al. at Stanford published Lost in the Middle: How Language Models Use Long Contexts in 2023, and the finding has been replicated enough times that it should be a load-bearing assumption in any architecture: model attention is not uniform across the context window. Information at the beginning and end gets used. Information in the middle gets quietly ignored, even by models that advertise long-context support.

So the naive “just give it the whole history” approach is doubly bad. You pay for every token, and the model uses some of them less than others, and you have no easy way to tell which.

This is one of the reasons selective retrieval beats full replay almost everywhere. You are not just saving tokens. You are putting the relevant tokens in positions where the model will actually use them.

The Token Bill (Yes, Again)

Here is the part that gets glossed over in the demos.

Every token in your context window is paid for, every turn. If your “memory” is “we keep prepending the full conversation,” then by turn 50 you are paying for tokens 1 through 49 fifty times over, and the model is working harder to find the signal each time. This is the closest thing to a structural cost trap in LLM architecture, and it is almost always invisible in development because nobody runs 50-turn conversations against the dev key.

Anthropic’s prompt caching, introduced in August 2024, helps for the parts of your context that genuinely repeat (system prompts, fixed instructions, large reference documents): cached read tokens cost about 10% of the standard input price. That is real money saved on the parts that don’t change. But caching is not memory. It does not summarize, retrieve, or forget. It just makes paying for the same prefix cheaper. Use it where it fits, but do not let “we turned on caching” stand in for an actual memory strategy.

Memory architecture is cost architecture. They are the same conversation. Any team treating them separately is going to be surprised by one of them.

Patterns That Actually Earn Their Keep

A few that hold up in production (as of this writing, a caveat that I’m guilty of not always stating, and how you should think about everything you read about AI):

Hierarchical / paged memory. MemGPT (Packer et al., 2023) is the canonical paper here: a small “main context” of hot facts plus a larger “external context” the model can page in and out, modeled on operating-system virtual memory. Even if you never use the framework (now continued as Letta), the mental model is the right one. Most context is cold most of the time. Stop paying to keep it warm.

Compaction at boundaries. Summarize aggressively at natural breakpoints (session end, topic change, day rollover). Throw away the verbatim transcript once the structured summary is written. Track what got compacted so you can audit later if a user complains the model “forgot.”

Structured extraction over raw recall. Pull stable facts (preferences, identifiers, decisions) out of conversation into a structured store. Read those on every turn. Let the conversational history age out. The user’s preferred tone of voice does not need to live in 12,000 tokens of transcript.

Retrieval over replay. Index past turns, retrieve only what is relevant to the current input, accept the occasional miss as a cost of doing business. Tune your retrieval thresholds with the same seriousness you tune any other production query.

Skills and procedural memory as a separate tier. “How we do things” is not the same as “what we said.” Keep them in separate stores with separate update rules. Skills change rarely; episodic facts change constantly.

A Practical Framework

Four scenarios, four answers:

A user opens the same chat tomorrow and expects continuity: structured profile plus retrieval over summarized history. Do not replay the full transcript.

An agent loops on a long-running task: hierarchical memory with compaction at step boundaries. Hot working set stays small; cold context pages out.

A system prompt or large reference document is reused on every call: prompt caching. Cheap, easy, do it today.

A model needs to “know how we do things”: procedural / skill memory in its own tier. Keep it separate from episodic memory so updating one doesn’t disturb the other.

The wrong answer in all four cases is “just send the whole history.” That is the architecture equivalent of walking Lucy through the entire relationship from scratch, every morning, in hopes that this time some of it sticks. Romantic in the movie. Expensive in production.

Paddling off into the Sunset

The model forgets. That is not a bug, that is the current limitation of the art. The work is in deciding what your application remembers, where it stores it, when it retrieves it, and what it costs you per turn. Treat memory as architecture and most of the surprises go away.

Sources:

If you found this interesting, please share.

© Scott S. Nelson

Markup is the New Markdown

Scott S NelsonLeave a comment

TL;DR: “HTML is the new Markdown” is an attention-grabbing headline (for some of us), but not something to adopt at face-value, or without more context. Where HTML applies, it genuinely delivers. Where it doesn’t, you’ll just be paying more per token for the privilege of being wrong.

Here’s something I catch myself doing constantly with AI content: skim the headline, fill in the details based on my own context, and run with a conclusion the original post may or may not have intended. I’m not the only one. It’s not laziness, it’s a cognitive defense mechanism in a world full of content, not to mention extra work hours keeping up with all the tools that are supposed to save us work hours.

This one is definitely that.

Earlier this month, Thariq Shihipar, an engineer at Anthropic, posted nine words on X: “HTML is the new markdown.” The post linked to a companion site with 20 self-contained .html files that an agent produced instead of the usual Markdown output. It pulled 8,600+ likes and 11,000 bookmarks. Simon Willison publicly reconsidered his three-year Markdown default. The Hacker News thread was climbing past 30 points an hour.

The reaction was big and fast, which is a sign that many people didn’t read the whole thing, or understand the whole context (ahem, “vibe coding).

So. Let’s look at what this shift actually means, where it applies, how to apply it, and what it does to your token bill.

My HTML Baggage (Relevant, I Promise)

I mastered HTML in the early 2000s. Semantic structure, tag vocabulary, clean markup from scratch. The whole deal. So when Markdown started getting traction among developers in the 2010s, my first reaction was skepticism: why learn a format whose entire job is to produce a subset of what I can already write directly?

The pragmatic case eventually won me over, and it wasn’t even close. By the early 2020s, documentation had moved decisively into Git. Design docs, specs, ADRs, READMEs, changelogs: all .md. GitHub renders it natively. It reads as plain text, commits cleanly, and it became the shared syntax of developer collaboration. Fighting it meant fighting a current that wasn’t going to reverse, so I stopped. The ubiquity was the feature.

I tell you that because when I saw Thariq’s post, I had already settled in mind that markdown is how to communicate with AI and this made no sense to me.  Back to that bad habit of skimming headlines. What I should have done first was ask: back for what?

What Thariq Was Actually Pointing At

The argument isn’t that Markdown is dead or that you should rewrite your documentation in HTML. It’s narrower and more specific than that.

Thariq’s 20 examples grouped HTML wins into categories of LLM output: project status reports, code reviews, diagnostic summaries, data comparisons. The things an agent produces that a human then has to read, navigate, and act on. When one researcher ran all 20 prompts through Claude in both formats, HTML won 17 of the 20 head-to-head comparisons. The 3 cases where Markdown held its own were tasks where the output stays internal to an agent’s loop and never reaches a human at all. (Source.)

Once a person is the end consumer, HTML’s richer vocabulary starts earning its overhead. Collapsible sections. Semantic structure. Tabbed layouts. Inline labels. Color-coded status. Things Markdown has no syntax for, because Markdown was never designed to produce navigable deliverables. It was designed to produce readable plain text.

LLMs have also been trained on billions of HTML pages, so the semantics of those tags are deeply embedded in how these models understand and produce structure. That doesn’t go away just because Markdown became the default output convention.

For human-readable LLM output, HTML deserves a serious look. That part of the headline holds up.

Where It Does Not Apply

This is where the skimming gets expensive.

For input to an LLM, Markdown is still the right default, and by a wide margin. Markdown uses dramatically fewer tokens than HTML for equivalent content. A Cloudflare analysis found that the Markdown version of a typical blog post used 80% fewer tokens than its HTML counterpart. In RAG pipelines, Markdown-formatted inputs have been shown to boost accuracy by up to 35% while cutting token costs by 20 to 30%. On structured tasks like table extraction, Markdown outperforms HTML at roughly 60.7% accuracy versus 53.6% in GPT-based evaluations. (Source.)

Worth noting: Profound ran a controlled experiment across 381 pages on 6 websites to test whether serving Markdown to AI crawlers versus HTML made a meaningful difference in bot traffic. The result was a marginal directional advantage for Markdown (~16% mean lift) that wasn’t statistically significant. (Source.) Which is to say, well-formed HTML isn’t incomprehensible to LLMs. But when you’re paying per token, the math still favors Markdown clearly.

For documentation in repositories, nothing about Thariq’s observation changes the picture. Markdown’s native rendering in GitHub and GitLab, its readability as plain text, and its role as the standard syntax of developer documentation are not touched by this argument. If your docs live in Git and humans need to read and edit them, Markdown is still the answer. Full stop.

The Token Bill Reality

This deserves its own section because it’s where the “HTML is back!” take gets most dangerous most quickly.

The token efficiency gap between Markdown and HTML is real and large. 80% fewer tokens for equivalent content isn’t a rounding error. At any meaningful scale, that’s a direct line to your API costs. HTML earns that overhead only when the output is rich enough, and human-facing enough, to justify it.

If your workflow involves long context windows, high-volume RAG retrieval, or large amounts of text being ingested or passed between agents, the format you choose for that content has a real cost consequence. Thariq’s post is not an argument for switching to HTML across the board. Applied without that nuance, it’s an expensive misread.

The Framework That Actually Helps

Four scenarios, four answers:

A human writes context and feeds it to a model: Markdown. A model produces output that stays inside an agent loop: Markdown. A model produces a deliverable a human will read, navigate, and act on: HTML is worth the token cost. Documentation lives in a repository: Markdown, full stop.

The headline “HTML is the new Markdown” is accurate for exactly one of those four. The other three haven’t changed.

Thariq’s post isn’t a verdict. It’s a recalibration for a specific use case. The fact that it spread the way it did says less about the content and more about how hungry people are for permission to do the thing they already half-wanted to do.

I’m not pointing fingers. I had the same instinct.

Additional Sources:

If you found this interesting, please share.

© Scott S. Nelson

Attitudes About AI Adoption and Acceleration

Scott S NelsonLeave a comment

Much of the misplaced fear and distrust surrounding AI adoption traces back to a single omission in how people are often introduced to its use. Businesses and the media have fixated on the intelligence aspect while often ignoring the behavioral framework required to make it work in the real world.

The early representation of Generative AI suggested it was a shortcut that required very little effort. If users were told upfront about the level of detail, context-setting, and iterative refinement required to get a usable result, the hype might have been quieter (look how long Anthropic was off the radar of the general public), but the real work with these powerful tools might have started sooner for the average person and business (AI Adoption Puzzle: Why Usage Is Up But Impact Is Not, BCG, 2025)

We are essentially trading traditional coding hours for what some call vibe coding: throwing natural language at a problem and hoping the model catches the intent. Vibe coding is a legitimate way to prototype, but it becomes technical debt if you do not eventually solidify the logic. Replacing a clean specification with an open-ended series of guesses is how projects lose their shape before they find their footing.

The most effective approach is not simply plugging a model into an existing process because it looks like it might help. Genuine acceleration comes from a willingness to rethink how things get done, then determining how AI can facilitate those better ways. It is the difference between automating a flawed process and designing a new one.

The success stories often come from teams who looked at a failed output and wondered what specific lever they forgot to pull. They treat the model as a mirror. If the output is off-base, it usually means the instructions provided were incomplete or lacked the necessary constraints. It is an objective way to see where our own requirements are fuzzy.

This is particularly evident in workflow automation. Earlier automation projects often failed because they only mapped the mechanics. We drew boxes and arrows to show what happened next, but we ignored the intent.

AI-driven automation is succeeding where those attempts fell short because the machine requires the reasoning, not just the step. To make an agent navigate a workflow, you have to document why each step exists. This forces organizations to complete their process definitions rather than paper over the gaps. If you cannot explain the logic behind a decision point, the machine cannot execute it. This forced clarity is the real process improvement.

The Double Standard

There is a noticeable double standard in the modern workplace. When an LLM returns a hallucinated mess or fails a logic branch, we iterate. We refine the prompt. We provide more context. We give the machine a level of professional grace and patience that we rarely extend to our human peers.

Think about what that looks like in practice. A new team member submits work that misses the mark, and the first instinct is to question their judgment or capability. The same output from a model and the instinct is to wonder what context was missing from the prompt. One is treated as a character flaw; the other as a specification problem. They are often the same problem.

If organizations applied that same diagnostic instinct to people, treating an incomplete first draft as a gap in the brief rather than a gap in the person, productivity would likely increase. Instead, we frequently demand accuracy on the first pass from humans while subsidizing the machine’s learning curve with endless retry clicks. (The Human Side of AI Adoption: Lessons From the Field, MIT Sloan Management Review, 2025)

The Same Loop Applies to Both

Closing that gap is not primarily a technology problem. It is a management problem, and the same loop applies whether you are working with a model or a person.

Start by acknowledging that a wrong answer is often a sign of a logic path being tested; it is data, not a failure. Reward the attempt at solving the problem; in early iterations, the goal is narrowing the scope, not delivering the final answer. And when the output is off-base, assume the cause is a lack of clear boundaries before assuming incompetence. These are not novel management principles. They are just easier to see when the thing being managed cannot take it personally.

The teams getting real value out of these tools are not looking for a magic button. They treat the AI as a diagnostic tool for their own process gaps. They do not just want the answer; they want to see where the system broke so they can fix the underlying logic.

The One Attribute That Survives

This brings us to the attribute that determines whether a tool gets abandoned or mastered.

Curiosity is the only attribute and attitude that survives the hype cycle.

Expectations without curiosity lead directly to disappointment. If you aren’t wondering why the model failed, you will just conclude the tool is broken and move on. In a technical context, curiosity is the bridge between a strategy and a result. It leads to both the perseverance and the openness to changing the way we think about how things get done. It forces us to reprioritize the work based on what the machine reveals about our own internal logic.

Proficiency in this landscape is not about mastering a specific toolset, because those change every few weeks. It is about an underlying hunger to understand the mechanics of the work. If you have that curiosity, you will find the ROI because you will keep digging until the logic is sound.

Until next time…

Related reading from What IT Is:

If you found this interesting, please share.

© Scott S. Nelson