Microservices changed how we build software by breaking large applications into smaller, independently deployable services. That made systems easier to develop and scale, but it introduced a different class of problems: The behavior of the whole system got harder to see. AI agents are now following a similar path. A workflow that once lived inside a single application gets split across several agents, each responsible for one task. Individual pieces may work exactly as designed while the overall workflow gradually produces worse results. The difference is that agents make these systems far faster and cheaper to create, which makes it easier to repeat the same architectural mistake at a much larger scale.

I learned this the hard way. My name was on the design doc. Splitting that workflow across three agents was a reasonable call, and I would still defend most of the reasoning. But if you’d asked me that afternoon how we would find out when the thing quietly stopped working, I had no answer.

Months later, in a quality review, a reviewer noticed something felt off before any of our instrumentation caught it. Latency looked fine, error rates were flat, and every service in the chain returned what it was supposed to return. What we had was a slow decline in output quality, and it took about three weeks to trace.

The first agent handed a set of documents to the next one for summarization. The summarizer dropped a field it had judged to be a low signal. A downstream agent then made a confident recommendation without that field. Every agent did what it had been designed to do, and the result was still wrong. I should have anticipated it, because I’d been on the product side through the microservices years and had seen this pattern before.

The hangover we already paid for

Breaking down monoliths was a good decision for most teams, but one thing was forgotten. Decomposition did not make the difficult parts of the system disappear. It moved them into the gaps between services, where the people accountable for the overall product could no longer see them. The bill landed around 2019, and it landed on the delivery schedule rather than the incident channel. Teams were running hundreds of services with limited tracing and no contract versioning, and the real symptom was slower delivery. Shipping took longer than before, because engineers spent their weeks picking through those services.

Agents are running the same arc faster, because standing one up takes an afternoon and a prompt instead of a repo and a deploy pipeline. When creating an agent is that cheap, product teams make agents without asking anyone, and nobody keeps track of what the agents are and what they’re doing.

What breaks, and what it costs you

This isn’t only my experience. Cemri and coauthors annotated more than 1,600 execution traces across seven popular multi-agent frameworks and built a taxonomy of 14 recurring failure modes (MAST, NeurIPS 2025). Most of what goes wrong traces back to how the system was specified and how its agents coordinated, not to the models inside it.

Inventory sounds trivial and isn’t. Service sprawl at least showed up in your Kubernetes manifests. Agents get created inside product surfaces and workflow tools, and inside somebody’s weekend automation of their own job. You don’t find out what you have until a compliance reviewer asks which automated system touched a given decision, and then it’s too late.

The visibility gap cost us three weeks. When an agent calls an agent that calls a retrieval layer that calls another agent, and every hop has a model deciding what to pass forward, you need trace context that survives the whole path. Most stacks log prompts and completions per call and stop there. You get each hop and never the chain, and it was the chain that failed.

Compounding confidence is the failure that worries me most. Distributed systems fail loudly, which turned out to be a blessing nobody appreciated. A service throws a 500 and the caller knows to stop. Agents fail quietly and fluently, so when an upstream agent produces a summary that’s plausible and wrong, the downstream agent gets no signal and reasons confidently on top of it. By the time the result reaches the user, it conveys a level of confidence that the initial evidence does not support.

API contracts drifted when someone changed the response format without versioning it, and we built machinery to catch that at build time. Agent contracts drift when someone edits a system prompt. In that case there’s no schema diff and no type check. Nothing breaks until a downstream agent starts getting different output and adapts to it without telling anybody.

What carries over from microservices

A registry is the cheapest thing to build and the first thing everyone skips. When building microservices, we kept a service catalog with an owner and a scope for each service. For agents, we need that same record plus an explicit list of what each agent is allowed to call.

Tracing carries over nearly unchanged, since correlation IDs were invented for this exact problem. OpenTelemetry’s GenAI semantic conventions give you the vocabulary, and an agent run comes out as a span tree instead of a pile of unrelated log lines:

Had we been emitting those spans, the summarizer span and the recommender span would have sat side by side in one trace, and the missing field would have been a diff instead of a three-week hunt. These conventions are still moving, so keep the attribute names behind a thin mapping layer of your own.

Finding the missing field in a trace would have shortened the investigation. I’d also want a test that caught its omission before a prompt change reached production. That’s where I’d apply the contract-testing discipline from microservices: define what the downstream agent depends on, then check that an upstream change preserves it. For the summarizer in this workflow, the evaluation would need to check whether its output retained the information the recommender needed. I’d version the prompts and require changes to pass those evaluations before release. There’s early evidence it pays: SEMAP, a protocol-layer method applying behavioral contract modeling and lifecycle verification on Google’s A2A infrastructure, reported up to roughly 70 percent fewer failures on function-level coding tasks when scored against MAST.

The trust boundary is the thing I’ll argue about in a design review. In 2019 we learned that a service doesn’t get trusted just because it lives inside the perimeter, which is most of what service meshes were for. The agent version is that an agent doesn’t get broad tool access just because we built it and we’re nice people. What an agent is allowed to do belongs in a policy layer the model can’t talk its way past, not in a system prompt asking politely.

Cost is where the analogy between microservices and agents fails. A microservice stuck in a retry loop costs you CPU and an alert at 3 am. An agent stuck in a loop costs real money on every turn and doesn’t saturate in any way that makes itself obvious. This one lands on the product owner instead of infrastructure, because it surfaces as unit economics rather than an outage, which means the PM ends up justifying the number at the end of a billing cycle.

What I ask before approving a split

None of this argues against multi-agent systems, which earn their keep the same way services did. My argument is that operational practices should evolve alongside architecture, without repeating the five-year lag of the previous transition. The person accountable for delivering the product is usually best placed to ensure that happens.

Hence, I push on four things. Can we follow one request all the way through and reconstruct what each agent decided and why? If not, we’re building something we won’t be able to debug. What happens when an upstream agent is wrong, and not whether it can be? If the honest answer is that the next agent carries on as normal, we haven’t designed a failure mode. We’ve designed a failure and left it running.

Who owns this agent, and where is its tool access enforced? A system prompt isn’t enforcement. What does this cost at ten times today’s volume, and what shuts it off when the number goes wrong? I ask that one early, because nobody volunteers it.

The teams that managed service decomposition most effectively incorporated tracing and contract testing into the build from the outset. These practices helped them understand how services interacted and verify that changes preserved expected behavior. That work is a sprint or two now, and a great deal more than that once you’re running 40 agents and someone asks which of them touched a customer’s data.

New frontier models arrived this week as investors showed signs of growing cautious about AI spending. On the latest episode of This Week in AI, we examined those developments, along with research into how models learn and the less visible costs of AI adoption. From unequal pricing across languages to the environmental impact of data centers, the discussion raised questions about who benefits from AI progress and who pays for it.

Frontier models advance as investors question the spending

We started with three model announcements that show how quickly AI capabilities are expanding. Google introduced Gemini 4 Carbon, designed for cybersecurity and complex, multistep tasks. France’s Mistral published the weights for its trillion-parameter Large 4 model, also known as “Le Chonk,” giving developers more control over deployment and customization, provided they have the hardware to run it. Meanwhile, Google DeepMind previewed Genie 4, a world model that simulates environments, physical interactions, and sequences of events. Unlike language models that predict text, world models attempt to predict what happens when objects and people interact. With Genie 4, researchers could train AI systems in simulated worlds, an approach that would be especially useful in robotics, where teams could test AI designed to control robots before trying it on physical machines.

Investor enthusiasm for AI appeared to weaken even as model development accelerated. Anthropic moved closer to a public offering by filing its IPO paperwork publicly, although it hasn’t announced a date or share price. OpenAI has reportedly secured about $11 billion in funding for its latest round, well below its initial $30 billion target. Those developments coincided with sharp declines in several major technology stocks, and the tech-heavy Nasdaq ended October with its worst monthly decline since March 2025.

The scale of AI spending is attracting greater scrutiny, particularly as investors wait for returns. Companies investing in AI should pay attention to more than model performance. The economics of training and running increasingly expensive models could affect pricing, availability, and which providers remain competitive.

Researchers are rethinking how AI models learn

Researchers are investigating how AI models process information, retain knowledge, and generate responses. AI interpretability company Goodfire proposed a project modeled on the Human Genome Project, committing $10 million to begin mapping how large language models work internally. By studying which patterns activate in response to prompts and how changes to those patterns affect behavior, researchers hope to better understand why models produce particular outputs.

Google Research proposed a framework inspired by human cognition that introduces a “sleep” phase. During this offline period, models would consolidate new information and generate practice examples through a process researchers call “dreaming.” The goal is to address catastrophic forgetting, when learning new information degrades previously acquired capabilities, while helping models retain knowledge beyond individual conversations. The approach remains experimental, but it offers a possible way for models to continue learning without sacrificing existing skills.

We also examined Clover, a 35-billion-parameter diffusion language model released by China’s DiffuSpace. Most familiar language models use what’s called an autoregressive approach: They generate text sequentially, one token at a time. Diffusion language models instead work on multiple parts of an answer simultaneously, refining them over successive passes. DiffuSpace reports competitive performance and faster generation on some tasks when compared to autoregressive models of similar size. Alongside Goodfire’s and Google’s research, this work suggests that improvements in AI may increasingly come from rethinking how models learn and generate outputs rather than simply making them larger.

AI’s hidden costs extend beyond infrastructure spending

Research into the “tokenizer tax” revealed how AI pricing can disadvantage people who speak less widely represented languages. Researchers found that some languages require substantially more tokens than English to express the same message. In one example, the Malayalam translation contained slightly fewer characters than the original sentence in English, yet it required twice as many tokens: 26 compared with 13. Because AI providers commonly charge by token, these differences can translate into higher costs for users, particularly in communities where AI services may already be less affordable. Developers building multilingual applications need to consider tokenization efficiency alongside model quality.

In Finland, authorities are investigating Google’s clearing of more than 400,000 trees for planned data centers. The investigation centers on whether the company completed required environmental assessments before clearing the sites. The case shows why environmental reviews need to happen before land is cleared or construction begins. Once that happens, regulatory action can’t immediately restore the affected ecosystem.

Finally, several AI companies said they plan to honor a shared website opt-out signal that would let publishers indicate that their content shouldn’t be used for AI model training. The proposal could give website owners more control over future data collection, although participation remains voluntary. It can’t reverse the use of material already collected for training, and the standard will only help if AI companies follow the instructions publishers provide.

What’s next

This week’s developments show why evaluating AI progress requires more than tracking model releases and benchmark scores. We need to understand how systems learn, whether their economics are sustainable, and how their costs affect people and communities. As more businesses and individuals adopt AI, those considerations will become harder to ignore.

We’ll be back on Monday, November 9, for another episode covering the latest developments in AI research and applications. You can catch previous episodes on YouTube, Spotify, Apple, or wherever you get your podcasts.

Remember back in 2019, when you had only a handful of language models to choose from, all with limited context windows? That world is gone, and it feels like a forgotten past. Today, flagship providers and open source projects compete across model families, sizes, capabilities, and deployment options. Coding harnesses seem to be heading in the same direction.

On the surface, Claude Code, Codex, Pi, DeepSeek Harness, and the other coding harnesses all seem to do the same thing: help you build software with models. Look closer, though, and each one gives you control over different parts of the harness. What can the model see and change? How does it use tools? Where does it run, and what happens when it fails? So instead of asking which coding harness is best overall, ask:

Which layers of the harness do you need to control?

Thanks for all the harnesses! Now what?

Choosing a coding harness isn’t only about which model writes the best code. You’re also choosing what the harness provides, what you can change, and what you must build yourself. If it doesn’t give you verification, durable state, repair routing, or an enforced execution boundary, those responsibilities stay with you. You remain accountable for the workflow’s reliability and governance.

In general, each harness has a center of gravity: a layer that gives you the most direct control. The following table is a deliberately high-level overview of where that center sits. It’s not a feature matrix, and the boundaries overlap in practice. Claude Code can also run noninteractively and inside sandboxes, Codex also reads repository instructions, and all of them are changing quickly. The point is to show where each harness gives you leverage by default, and where the engineering work is likely to stay with you.

Table 1. Where each coding harness puts its primary control

Read the table as a map, not a ranking. A harness that hands you more control also hands you more to build, and a harness that does more out of the box decides more on your behalf. Which trade-off is right depends on which layer your project actually needs to own.

Claude Code: Control inside the run

Claude Code buys you detailed control over how implementation unfolds. CLAUDE.md provides standing instructions, skills add task-specific playbooks, subagents divide the work, and hooks intercept actions before and after tool calls. Unlike a permission rule that simply refuses an operation, a hook can explain the refusal or immediately return a compiler or policy failure to the agent.

These controls let you steer the coding loop extensively, but they operate within Claude Code’s existing lifecycle. If you need to control the outer lifecycle itself, you need another layer.

Codex: Control through separation

Codex buys you separation between a coding task and its execution environment. A noninteractive codex exec run can work on a narrow task in a specified repository, under an OS-enforced sandbox, and return a schema-constrained result.

This is useful for independent verification. You can give Codex a clean checkout, exclude the builder’s instructions, restrict writable paths, and run separate reviews for code quality, test gaps, persistence, or user-visible behavior. The sandbox depends on the operating system, but it moves scope enforcement out of the prompt and into the execution boundary.

Pi: Control over the loop

Pi buys you control over the coding loop itself. Its tools, commands, event handlers, context, models, and session state can be extended or replaced. This lets you decide which steps remain agentic and which follow deterministic policy.

For example, a local defect can return to implementation, a repeated defect can force replanning, and conflicting findings can trigger a recheck or human review. Pi can also run agents inside this lifecycle, so it’s more than a deterministic orchestrator. For my example below, I used its programmability to make the outer decisions deterministic—that was my design choice, not Pi’s definition.

DeepSeek’s harness: Control through composition

DeepSeek’s harness is useful when you want to swap out whole parts of the harness rather than steer or wrap them. Tools, sessions, lifecycle behavior, verification, and governance are all composable plug-ins, and so is the loop itself. That lets you replace one component without rebuilding the rest.

The trade-off is that your control is only as good as the plug-ins you compose. Where Pi gives you a minimal core to build on, DeepSeek’s harness gives you a set of parts to assemble.

A practical example

Let me give you the problem I was actually trying to solve: migrating a legacy Python 2.7 application reliably, without changing years of accumulated behavior or corrupting its persisted data. Getting the code to run on Python 3 was only one part of it. I also needed to preserve behavior, verify the data across both runtimes, control what the coding agents could change, and decide what should happen when a test or verification step failed.

So I approached the choice of coding harnesses from a very different perspective. Instead of asking which one was best, I asked what each one would buy me in terms of control, isolation, and lifecycle management. The answer led me to use more than one:

• Claude Code built the port because I wanted internal steering, specialized skills, hooks, and a factory of implementation and review subagents.
• Codex verified it in isolated runs because I wanted an independent model context, clean workspaces, constrained writes, and structured findings.
• Pi owned the outer lifecycle because I wanted durable state, evidence validation, bounded repairs, replanning rules, and human escalation.
• Frozen acceptance, including Playwright and Python 2/3 differential checks, ran outside the agents so neither the builder nor the verifier could redefine success.

I didn’t use DeepSeek’s Harness here because I wanted a very small outer lifecycle I could read end to end, not because it can’t do the job. To first check whether this setup would actually make a difference, I built a small Python 2 application with the same kinds of traps as the real migration. I then compared the composed setup with a single Claude Code session, in which Claude could verify and test its own code.

Interestingly, both setups passed all 25 hidden behavior tests. Yet the single-session setup silently collapsed two distinct Python 2 dictionary keys, the Unicode u’é’ and byte string ‘é’, into one Python 3 string. After the data was saved, one entry was permanently lost. The single-session setup also changed a Python 2 Unicode value into bytes without documenting it.

The test suite missed it. Claude’s own tests missed it. Hundreds of recorded behavior comparisons missed it. Even my hand-written reference port had the same hole.

But what happened next was even more interesting. Two isolated Codex verifiers independently reproduced the defect. Claude didn’t simply accept the finding; it contested it. Pi then launched a fresh Codex run that received only the finding and Claude’s argument. The independent recheck upheld the finding, and Claude accepted it. Pi routed the defect into a bounded repair, and the next verification round confirmed that both keys and their original types now survived.

It’s also ironic because models are often criticized for being sycophantic. They apologize and rewrite working code the moment you ask, “Are you sure?” Here, the opposite happened. Claude contested a defect that two independent verifiers had reproduced. Its session context contained its own implementation history and passing tests, all of which supported the patch. A fresh verifier context broke that self-reinforcing frame. Independent verification matters not because the second model is automatically right, but because it’s not anchored to the same history.

The important point is that no individual harness deserves all the credit. The better result came from combining the controls I needed: internal steering, independent execution, frozen behavioral evidence, and deterministic lifecycle policy.

How to choose your coding harness

When choosing a coding harness, start with the level of control you need and how much of the remaining harness you are prepared to engineer yourself. A useful comparison could begin with questions like these:

• Do I want to configure an existing coding loop, extend it, or replace parts of it?
• Can I control tools, context, memory, and model selection at the level my project requires?
• Where are permissions, allow lists, and policies enforced: in instructions, application logic, or the operating system?
• Can I intercept actions and lifecycle events before and after they happen?
• How much of the orchestration, state management, and session lifecycle can I change or orchestrate?
• What does the harness expose for observability, verification, and structured evidence?
• Which reliability and governance controls does the harness provide, and which ones remain mine to build?
• Can the harness work with other tools and harnesses if my requirements cross several control layers?

These are some examples to get you started, not an exhaustive checklist. The questions that matter for you will also depend on what you’re building, how much autonomy you’re willing to give the coding agent, and what you remain accountable for when it fails.

Your answers may lead you to Claude Code, Codex, Pi, DeepSeek’s harness, or another coding harness entirely. In the end, the developer’s name only tells you who packaged the runtime, not where your guarantees live. Whether you settle on one harness or orchestrate several, the principle is the same: Choose the tool by the boundary of control it gives you, and ask whether you want the agent to define the terms of its own success.

At our recent Foo Camp, a number of people said something like, “I don’t want someone else’s code any more. I may have my agent take a look at it, but I want to extract just the parts that I want, and may rewrite even those in Rust. It’s just too easy to create just the code that I want.”

This topic was hot enough that Jesse Vincent held an entire session about it. I did not attend, but Jesse gave me a report from his Plaude AI notetaker. Here’s a relevant section of the summary:

Several participants argue that software development’s primary artifact may be shifting from executable code toward natural-language prompts, generation processes, and developer skills. One speaker compares Python to assembly language, suggesting that writing conventional code may become optional as natural-language generation takes precedence. Another argues that open source can survive such a transition because its core values—peer production, capacity building, and shared specifications—do not depend on who or what writes the code.

At the same time, Jesse warns that maintainers are overwhelmed by floods of uninvited, automated, and often low-quality contributions. Participants say that traditional milestones such as pull requests, repositories, and conferences have helped contributors connect and gain recognition; as AI makes code replication easier, communities may need new ways to acknowledge participation and create paths for future developers. Some community interaction has moved to spaces such as Discord and direct messages, but structured opportunities are still needed.

Scientific computing raises particular concerns. One panelist warns that AI-generated forks and agent attacks could threaten carefully verified foundations such as NumPy and SciPy. Scientific systems depend on battle-tested libraries and reproducibility, so thousands of unreviewed alternatives could undermine reliability. Participants suggest bridging traditional open-source communities and modern AI development, which currently may use different tools and artifacts.

Other proposals include treating code as “liquid” and focusing open-source governance on durable infrastructure and specifications; maintaining agent storage independently of ephemeral container lifecycles; and using corporate compliance and safety-monitoring architectures to aggregate organizational traces.

These are important observations, all pointing in the same direction: AI is transforming the mechanisms and the artifacts of software development. For an increasing number of use cases, the software source code itself may no longer be the most important shareable knowledge artifact. This isn’t a new phenomenon. Every major change in technology calls for new mechanisms, new artifacts, and new institutions.

Originally, software developers mostly distributed binaries, then open source developers made sharing source code the norm. Now we need to distribute and share something else: context and patterns for generating code on the fly. Knowledge is being unbundled and can be shared in new forms. A repo may now serve merely as a source of context for solving the exact problem I have, rather than the bundle of problems that the original developer(s) encoded into their library or packaged solution. Some people will keep their context and patterns private, either because they see proprietary advantage in keeping them to themselves or because they are too busy or too lazy to share. But part of the problem is that we haven’t yet figured out what needs to be shared!

The challenge for the software development community is to identify the new knowledge artifacts of the AI economy, and to build new mechanisms and incentives for sharing them.

We’ve all had the experience of seeing a bespoke agentically generated app, wanting something similar, and wishing we could ask for a starting point so we didn’t have to vibe code an equivalent from scratch, with all the attention, false starts, and token costs that comes with that. Even in a world where software is generated by agents, it’s still not costless, and most of us like a good place to start.

Of course, this won’t be all software. There are lots of areas where “sort of alike” software is a recipe for disaster. Imagine a sales and marketing group where everyone had their own vibe-coded CRM tools, with different metrics and capabilities. This is not good. So there is still a place for big SaaS applications, distributed binary software, and distributed source code. You pick the hat to fit the head. But there’s also a need for something new.

The purpose of this article is to start a conversation about exactly what it is that developers should be preserving, sharing, and building on from others, and what mechanisms are still missing to make that virtuous circle work more effectively. I can’t see into the future; I can only speculate. So, as is often the case, I take a historical view. The poet W. S. Merwin wrote, “We are the echo of the future.” I have found that using history to frame the present can be a productive way to get our minds going in the right direction.

Note that while this article focuses on software development, the questions I’m asking here apply to virtually every field. Let me know if you have insights from your work in any area touched by AI.

From code to context

The ease with which LLMs can generate code is paradoxically getting people to focus too much on how easy it is not to produce code. That may be blinding us to the fact that code itself is being displaced as a valuable, tradeable, shareable knowledge artifact. Maybe “displaced” is too strong a word. Different species of value overlap for a long time. Eventually, though, old ones fade and new ones become dominant. This has happened before. Every technology revolution draws not only on new mechanisms but also creates new valuable knowledge artifacts. I talked about this in my recent short keynote at AGNTCon + MCPCon.

The open source revolution depended in part on mechanisms like modular design and source code control, even more than it depended on free software licenses. It birthed new coordinating institutions like GitHub. But it also created a valuable new class of knowledge artifact in the form of the source code repo, and subsidiary valuable artifacts like commit history and reputation. A developer’s public repos became a kind of résumé, and a project’s commit log became a record of who had done what, and how well. This replaced a previous world where binaries were the tradeable objects of the software economy. Microsoft’s fortune was built on selling licenses to binaries, and to anyone who measured the software economy in licenses sold, free software looked like value being destroyed. (Steve Ballmer called GPL’d free software “a cancer” and Microsoft VP Jim Allchin called it “an intellectual property destroyer.”)

There were two ways that I like to think about the effects of open source software. First, value that was based on scarcity was replaced by value that was created by abundance. Back in 1975, Steve Baer described this as “the clothesline paradox,” explaining that when you put your clothes in the dryer, the energy you use is measured and counted, but when you hang your clothes on the line, it is ignored by accounting, despite doing the same job. Open source software was like sunshine, free for the taking, and its value unmeasured. Everyone compared the revenue of free software companies like Red Hat and MySQL to the vastly larger revenues of proprietary software companies like Microsoft and Oracle, noted the fact that they hadn’t even survived as independent companies, and concluded that open source was a less effective business model because its creators captured less of the value. They missed the point that far more value had been created than had been captured. Open source went on to power most of the internet economy, with the value captured by other means than selling the software itself.

Some people might think of this as a kind of failure, but they would be wrong. It is the system working exactly as its creators intended. I remember talking with Bob Scheifler, one of the creators of the X Window System, about whether it was OK that we were building commercial versions of their documentation. He told me that was exactly what he had intended. They put things out with a very permissive license precisely because they wanted others to build on top of them. I remember him saying “We want to raise the floor.” The creators of Berkeley Unix, Apache, and others felt exactly the same way. They didn’t want to win the existing game. They wanted to play a different game.

And they succeeded, big time. As Clayton Christensen noted in 2004, when one thing becomes a commodity, modular and fungible, something else (usually something adjacent) becomes valuable. He called this “The Law of Conservation of Attractive Profits.” At about the same time, I had stumbled onto this principle in explaining the implications of open source software in giving rise to the new paradigm that I was shortly to start calling Web 2.0. Clay and I first bonded when we gave our respective keynotes about essentially the same thing at the 2004 Open Source Business Conference. I later wrote about the conjunction of our respective ideas in a piece called “The Open Source Paradigm Shift.”

New artifacts are often the first visible sign of this value transition. You can see this at work in the evolution of the web. The web was born from the new mechanism of internet-enabled hypertext via HTTP, HTML, and the modular, replaceable software (the web browser and the web server) that made it useful.

At first, the new valuable knowledge artifact was the website with its domain name, associated URLs, and HTML-formatted web pages. DNS was the coordinating institution. People paid fortunes for domain names on the premise that the site was the thing that mattered. And it did matter, and still does. But less than it used to. Over time, Google became the new coordinating institution, and its ability to point deep within websites made the web page, not just the site itself, a valuable knowledge artifact. Social media made “posts” and short-form video into other knowledge artifacts. New kinds of value creation and value capture tumbled out of that unbundling. Packaged software was displaced as the key monetizable artifact and replaced by web applications, which were information- and software-based frontends to vast backend databases.

The click became a new and incredibly valuable knowledge artifact, the unit in which attention and intent were measured, and then priced. First pay per click advertising (Google), then engagement maxing (social media) became the basis of vast fortunes. The people who notice the new artifacts early, while everyone else is still focused on the old ones, then invent new business models based on them, often play a bigger game than those who were still trying to play by the new rules.

When I summed up these ideas in “What Is Web 2.0” in 2005, I talked about the key principles being “harnessing collective intelligence,” “software above the level of a single device,” and “data as the next Intel Inside.” (That is, the next valuable source of lock-in.) The companies that survived the dot-com bust were the ones that understood that the data their users generated through their activity on the internet was the asset that mattered, not just the software that served it. That was an argument about a new knowledge artifact, though I didn’t use those words at the time. PageRank understood that a link was a vote, and a new mechanism to improve organic search birthed new dimensions of the internet economy. Links were bought, sold, and gamed accordingly. SEO (both “white hat” and “black hat”) and search quality became a battlefield.

All those disciplines have had to change now that content has been absorbed into AI models. Books, music, video, web content, sites like Wikipedia, GitHub, and Stack Overflow were all grist for the mill. In the open source era, a voted-on answer to a well-posed question on Stack Overflow was a valuable artifact, and the reputation that came with writing good ones was a subsidiary artifact, just as it was on GitHub. The number of new questions asked on Stack Overflow peaked at roughly 200,000 a month around 2014 and was already sliding before ChatGPT, but the decline accelerated sharply after November 2022. The knowledge in those answers didn’t go away. It was absorbed into the models, which now give their own answers synthesized from all that they have consumed. In that way, they have also consumed much of the traffic that would have gone to the original knowledge creators. New mechanisms to create a circulatory economy of value creation need to be developed.

Software development also changed radically because of the internet. Another of my web 2.0 principles was what I called “the perpetual beta.” It’s easy to forget that in the PC era, software had major releases only every couple of years, with the new version distributed on CDs (and long before that, on 9-track magnetic tape.) I remember talking with Mark Lucovsky, who’d been a developer on Windows NT at Microsoft, shortly after he arrived at Google in 2005. He was exulting at the experience of being able to push a single change live worldwide soon after it had been tested. Eventually, we saw the formalization of new mechanisms like test-driven development (TDD) and continuous integration and continuous delivery/deployment (CI/CD), which we now take for granted, as if they’d always been the norm.

The story isn’t over yet, though. The old knowledge artifacts don’t go away all at once, and they don’t go down without fighting. The new artifacts are only half-formed, and have weaknesses that can be exploited. We’re in the middle of that fight right now. But I suspect the winners will be those who first understand what the sources of deep value will be five years from now.

When code is cheap, what becomes valuable?

When code is cheap to generate, the valuable thing may be the prompts, context, and other artifacts that tell the model what code to generate and how to do it well. I’ve started using the generic term “context bundles” to describe the artifacts that you hand the model to do its work.

In the opening to this piece, I talked about software patterns extracted from code as one kind of new shareable knowledge artifact. But these are only one of many kinds of “context bundles” that are starting to be shared. Spec-driven programming is all about developing context bundles. The spec becomes the thing that is reviewed, versioned, and kept, and the code is regenerated from it as needed. (A lot of people are worried that this might become a return to waterfall development. And it could, if done badly. But done well, with rapid turns? Maybe just right.)

An Agent Skill is another kind of context bundle, a folder of instructions, scripts, and reference material that an agent loads only when a task calls for it. Anthropic released the format as an open standard, and it has been adopted by a growing number of other agent products. An MCP server is yet another mechanism for presenting context that will shape the work of an LLM.

But that’s not all. The agent trace, the record of what an agent tried, which tools it called, and which context it drew on, is the closest thing we have to commit history for work that doesn’t get formalized as code. The log of which context bundles were invoked, and by whom, could also be the raw material for attribution and payment, much as the click was the raw material for advertising. And the stream of what people ask their agents to do may become to this era what the click was to the last, the signal of intent around which the coordinating institutions of the AI economy get built. I’ve often wondered what the agentic equivalent to PageRank will be. Will agents leave “pheromone trails” that grow stronger or fade over time, in the way that links do?

Even a well-formed question or conjecture could be a kind of context bundle. Math and science already value and exchange these, and I’ve started to think that there is an opportunity for building infrastructure for sharing and crediting them. After all, arXiv.org has already pushed the boundary for credit further upstream by publishing preprints rather than just reviewed papers. Why not go all the way to giving priority credit for well-formed conjectures?

The eval, a set of test cases that encodes what good work looks like for a particular task, may also turn out to be one of the most valuable things a domain expert can create, withhold, or share. But there’s a serpent in the Garden of Eden. At Foo Camp, Nick Vincent observed to me that there’s a real risk to evals as a context object, because there is a race going on to acquire massive amounts of data (say on corporate workflows) and sell it to the labs to train on it. But an eval only works if the model being judged hasn’t already seen the answers. Once the test cases leak into the training data, the eval measures what the model memorized rather than what it can do. How do we protect the holdout set for evals? That may be a critical mechanism that is still needed, and one that the people who build evals, and the companies whose workflows they describe, have every reason to develop. IMO, it would be good if there were more transparency into this process, and perhaps even supervision by a neutral body.

How do we come to trust new artifacts?

Part of the work of every revolution is building the mechanisms that help market participants to trust its new artifacts. In his book Nature’s Metropolis, William Cronon tells how Chicago became the center of the world’s grain trade in the 1850s. The mechanisms that enabled this were the railroad, the steam-powered grain elevator, and the telegraph. The coordinating institution became the Chicago Board of Trade. In 1856 the board adopted uniform grading standards. Before that, a farmer loaded his grain into individual sacks, and every buyer along the way had to inspect each lot or trust the seller. Afterward, a load of wheat was inspected by a middleman, dumped into a bin with other grain of the same grade, and its owner was handed a receipt for, say, a thousand bushels of No. 2 spring wheat. The grading standards became a new mechanism enabling trust and the grade receipt the new knowledge artifact certifying it. Together they separated the ownership of grain from the grain itself. Once merchants started trading receipts for grain, it didn’t take long before they were trading promises of grain not yet delivered, and the futures market was born. (That raises an intriguing question: What will be the derivatives of the AI era?)

Cronon’s history also observes that the receipts were only as good as the warehousemen who issued them. Some of them issued receipts backed by no grain at all, or spread rumors that stored grain was spoiling so they could buy receipts cheaply. It took years of fights inside the Board of Trade, and finally state regulation that the Supreme Court upheld in Munn v. Illinois, to make the receipts trustworthy. New knowledge artifacts invite counterfeits.

Even when there’s no fraud involved, there are often missteps in the early days of a new technology. Consider the rise of spreadsheet models that could be filled in with the user’s own data. A model was a set of assumptions and formulas that let anyone ask “what if?” and get an answer in seconds. Magic at the time! And eventually completely taken for granted. The model became an artifact that could be passed around, and used to make business decisions at companies other than the one that had created it. In 1984, a few years into the spreadsheet revolution, Steven Levy wrote “A Spreadsheet Way of Knowledge” about what VisiCalc and Lotus 1-2-3 were doing to American business. Levy warned that a spreadsheet model is only as good as its assumptions. Back then, people taking a poorly-executed spreadsheet model as gospel was the equivalent of some of today’s AI usage fails.

Feeling our way into the future

When people stop valuing the thing they used to value, ask what they are coming to value instead. Being alert to valuable new knowledge artifacts is a superpower. The new artifacts tend to show up well before the institutions that organize them, and long before anyone has worked out how to measure them. GitHub was founded more than a decade after open source software became mainstream, and Google didn’t become dominant till more than a decade after the first websites. My bet is that we are at a similar moment with context, with the artifacts starting to appear and the institutions that will coordinate them still unbuilt.

There is a lot of work that I’m following eagerly, looking to see where, whether, and how it gains traction.

• Duncan Davidson is doing fascinating work on what it would mean to have a home for personal context. I can’t wait till he makes more of this work public and reusable. Relatedly, the open memory protocol initiative is an attempt to define a useful set of mechanisms for exchanging context.
• Sam Schillace has started building a repository of what he calls agent-building patterns. One of those patterns, “Anchor on Canonical Names,” echoes the idea that I wrote about last year in “Magic Words,” and that we are also exploring with the O’Reilly Expert Intelligence MCP. As Sam puts it, canonical names are a way of referencing “a whole coherent methodology the model already learned in training, far more reliably than a paragraph paraphrasing the same idea.”
• There are numerous attempts to reinvent GitHub for the agentic era, including Cursor Origin and Entire, founded by former GitHub CEO Thomas Dohmke. Entire describes itself as “new distributed Git forge that stores your intent alongside your code, built for the scale and throughput of agentic coding.” Instead of traditional pull requests, it uses Trails, an agent-driven review system that logs session traces and automated evaluations so developers can merge code without reading every single line of a diff. Origin is an agent-first Git hosting and collaboration platform designed around structured semantic diffs, machine-readable merge states, and automated agent routing. As commercial products, both of these are examples of existing software distribution mechanisms and artifacts.
• Perhaps most interestingly for the point I’m exploring in this piece, Anthropic is building a proprietary, internal-only replacement for Git itself for its own use. The company published a very detailed description of the system, which it calls Scion. It might even be detailed enough for someone with a big team and a ton of compute to reproduce, using the description as a starting point. But you can see at the scale of what they have built the limits of the “distribute context and specs and rebuild on the fly” model.
• But there are also attempts to build systems that enable developers to share lightweight pieces in a new architecture of participation. Common Fabric is building an entire system premised on disposable agent-generated software expressing repeatable patterns, using data that is associated with users rather than with applications and that carries with it its own rules for how it can be used. In my conversation with cofounder and CEO Alex Komoroske, he described these patterns as small pieces of code that can be fetched from anywhere on the internet or written by an LLM on the fly. Agents will mostly write them, not human developers. But they will mostly write them on users’ behalf, and once someone’s agent has built a pattern, anyone else can use it. Their solution may not be the winning one, but it is definitely a bold leap into what may be a very different future for software.

Don’t get trapped in the past of software development. Root yourself in its history, the soil from which it grows, and imagine its future. What will we want to share, what will we want to reuse, and what mechanisms are needed for us to do so effectively?