Weâre halfway through Q1 already. If that seems impossible, âyou better believe it,â which could almost be the chorus for engineering eyeing the impending AI tsunami. Not the wave of hype or model releases or venture capital, all promising creative destruction. The actual surge of operational reality: autonomous agent systems that need zero trust production infrastructure and the realization that treating AI as a feature rather than a substrate means youâre still reading last yearâs âthought pieces.â Spoiler: the problem isnât hype. Itâs infrastructure.
Here in NYC, CTO Winter Night on January 22 set the tone for our own wave of disruption events. Followed by â30 Years of Silicon Alleyâ a number that seems to defy belief except that itâs entirely accurate: on February 16, 1995, in a Usenet job posting by New York tech recruiter Jason Denmark was heralded by the subject line âNYC â silicon ALLEY.â So 1,000+ attendees packed into an office building overlooking Wall Street with Kevin Ryan (DoubleClickâs âGodfather of NYC techâ) hosting, (and Bloomberg Betaâs Karin Klein and Indiegogoâs Slava Rubin working the room.) Conversations ranged from AI and pilates to private equity and the new mayor. One 20-year-old asked what Silicon Alley was. Nobody had a good answer before the fire marshal shut it all down shortly before midnight. Even Decemberâs Cluely relocation party didnât get shut down, proving NYC CTOs party harder than SF expat founders.
Then on February 13th, CNCF hosted âA Decade of Cloud Native: A Manhattan Homecomingâ at The New York Times Building, in the actual room where the CNCF charter was first signed! Less a meetup than infrastructure clergy taking communion, the question hanging over the event was not the last 10 years of infrastructure, but ofc the next 10 years. Care to place a bet where thatâs heading? Kalshi and Polymarket are happy to find a taker, while betting, with their own money, on surviving the NY AG and the ORACLE Act. And handing out free groceries to New Yorkers prepared to wait over an hour in the freezing cold for a $50 voucher. The mayor responded with a meme, because of course. The season caps off tomorrow (26 Feb) with a 2-Michelin-Star Fortune 1000 CTO dinner where the tasting menu will hopefully feel beside the point, Greg Brockmanâs recent, glib and somewhat controversial tweet notwithstanding.
What is the point, then? Spoiler: Itâs all about the the arrival of the Agentic Web of autonomous systems operating at scale. In order to build infrastructure that can absorb the cognitive load agents displace, we need to answer two crucial questions: How can we trust agents with write access to production? And how can we observe what theyâre doing when things go wrong? According to most CTOs at lunch, their organizations are still workshopping the first while the second is already blocking deployment. In this our first newsletter of the year weâll try to unpack the answers, and what you need to do.
IN THIS ISSUE
Teamwork Makes the (AI) Dream Work
Vibe Codingâs Paper Anniversary
AI Agents Run to Completion
Twilight of the MCP Idols
The Flaw in the Claw
Weathering Web3âs Winter
Teamwork Makes the (AI) Dream Work
On January 30th, software stocks went into a death spiral. The same day we had our celebration of 30 years of NYC tech innovation, technology stocks cratered â on news of coming innovation, if you believe the next dayâs headlines (which largely blamed Anthropicâs Cowork launch, and specifically the industry plugins for sales, finance, data, marketing, & legal that dropped on Friday.) Markets looked at SaaS margins and asked a reasonable question: if an AI agent can do workflow automation better than your $50/seat software, whatâs your moat? Investors didnât wait for an answer. They sold. Software sector down 8.3% in a single session. (I want to add âThis was not a bear trapâ but that feels like such an LLM thing to say.)
OpenAI countered with Frontier, their own âco-workerâ solution integrated with ChatGPT Enterprise. While both companies are positioning these as colleagues rather than assistants, the semantic difference matters operationally. An assistant helps you do your job. A co-worker does parts of your job autonomously, which means different trust requirements, different observability needs, and different compliance implications. Also: different implications for how many of you there are next year.
Per usual, the panic may have been overblown (Cowork plugins arenât replacing your entire go-to-market stack next quarter or even this year) but the market reaction forced the question into every board meeting: if AI can do this work, why are we paying for software that does it worse? Your CFO expects an answer. (He knows that it costs Salesforce just $38 to support each $300 seat.) Your board wants to know why youâre not replacing tools with agents. And your compliance team wants to know how youâre governing autonomous systems with write access.
For CTOs, the implication is straightforward: you need measurement infrastructure before you need virtual co-workers
Except the macro explanation is sitting in the corner quietly munching peanuts. Look at the VIX. Look at the S&P outside just tech stocks. Trump tariffs. Metals chaos. The software wipeout might have been triggered by Cowork, but the underlying conditions were already there. What Anthropic did was provide a narrative for selling pressure that was looking for an excuse. Almost like AI providing a narrative for the downsizing your C-suite wanted to do anyway.
Which brings us to the real question CTOs need to answer: is this actually about productivity, or is it just another excuse for headcount reduction? Because so far, AI has mostly been the latter. The dream everyoneâs selling is â10Ă your team.â The operational reality weâre discovering is messier and more asymmetric. AI makes junior people faster while slowing down senior people who spend their time reviewing a deluge of AI output instead of writing code. With not much time left over for building better harnesses.
Capital Eats First
AI is a mechanism for converting labor into liquidity.
The most serious attempt at a structural analysis of where this goes was Mondayâs Citrini Research memoâframed as a post-mortem from the futureâwhich does something important and something frustrating in roughly equal measure. (Hence its virality.) The important thing IMO is that it names the distributional dynamic clearly. AI gains flow to capital, not labor. This is literally what AI is: a lift and shift between these two domains. The thesis, not only correctly, but plainly stated, is essentially a truism. The frustrating thing was that it took a viral memo to put it plainly, because nobody else was willing to say the quiet part out loud.
Letâs say it clearly: AI is a mechanism for converting labor into capital. Every dollar of headcount that becomes a dollar of compute spend shifts value from wages, distributed across workers and recycled through consumption, to capital returns, concentrated among compute owners and shareholders. This should not be a controversial economic observation. Itâs what capital-labor substitution means.
Once you see that mechanism clearly, most âagenticâ use cases stop looking distinct. You don't need a macroeconomic model to see it (arguably why the Citrini piece has none) and you donât need Dromology to understand it. You just need to look at the market data. Google hitting $4 trillion market cap. IBM down 13% on the Anthropic COBOL announcement.
Claude Code can now analyze thousands of lines of legacy COBOL, map dependencies, document workflows, trace execution paths, identify risks; work that typically takes human teams months. (A problem Microsoft has been hoping to solve with agents since last year.) Ninety percent of the world's active financial transactions run on COBOL. The expertise pool maintaining those systems is aging out. IBM's entire services business was built on the assumption that modernizing this infrastructure required expensive human specialists indefinitely. One announcement repriced that assumption by 13% in a single session, the largest single-day drop for IBM since the dot-com crash.
A 13% drop on a blog post for a tool that hasn't completed a single production COBOL migration yet is also a perfectly good illustration of markets pricing possibility as certainty. The intersection of hope and hyperstition? Bet.
Missing Macro
A risk map dressed in the grammar of a post-mortem
Which is exactly the problem with the Citrini piece: the missing macroeconomic model. The cascade (software defaults by mid-2027, mortgage stress by 2028, S&P down 38%) arrives with Bloomberg-headline confidence and no transmission mechanism. How fast do displaced workers exhaust savings? What's the policy response function? At what threshold does private credit stress propagate to mortgages? Ghost GDP is real, but when you consider that the top 10% of earners drive more than half of consumer discretionary spending, K-shaped recovery starts to make a lot more sense.
So it's more like a risk map dressed in the grammar of a post-mortem. But directional confidence with no basis for magnitude and timing isnât real economic analysis, itâs provocation. And not coincidentally the hot topic at every board meeting this week.
Which brings us to what nobody in your board meeting will say out loud: AI agents arenât âproductivity toolsâ in any humanistic sense. Strip away the product marketing and every scaled, deployed, actually-working use case is a variation on the same function: moving money from A to B with fewer humans taking a cut in the middle. Agentic commerce. Automated procurement. Contract analysis. Insurance re-shopping. Workflow automation. These arenât different products. Theyâre the same product: wealth transfer, made more efficient. This is, incidentally, exactly what blockchain spent a decade promising to do. The difference is that blockchain mostly failed to scale. AI isnât failing to scale. (Though some would argue itâs scaling to fail.)
So the teamwork isnât really between you and your co-workers, itâs between capital and the tools it just acquired to replace labor more efficiently. Thatâs the dream thatâs being operationalized. Thatâs the dream CTOs have signed up to build, whether weâre comfortable admitting it or not.
Bottom Line
For CTOs, the more concrete implication is straightforward: we need measurement infrastructure before we need virtual co-workers. If we canât measure what human developers are actually producing versus what they feel like theyâre producing, adding AI agents just multiplies the confusion. And when the CFO asks for ROI numbers on Cowork versus human headcount, you need to hand him numbers that reflect your companyâs value chain, and not internal engineering metrics.
The software stock wipeout is a forcing function, but not the one all the GPT ghost written posts on LinkedIn are telling you it is. Itâs not forcing you to adopt AI co-workers. In fact, it's not forcing you to do anything. The choice before you, as CTO, is whether you understand your own value chain well enough to know the difference between real output and a cost relocation, or you keep repricing the question until the market answers it for you, somewhat drastically.
Vibe Codingâs Paper Anniversary
(I realise this title will make some readers think there was an actual vibe coding paper.)
Karpathyâs throwaway term for his own prompting habits turned one year-old this month, and the discourse around it has achieved the kind of self-sustaining philosophical density that could make Plato blush. Which is fine, as we say, except that the thing underneath this discourse is not philosophical. Itâs structural. And the structural question is the one most orgs are successfully avoiding, while appearing to engage with it, which is the only philosophical part.
The productivity story is real and the ceiling is real. A developer using AI to ship features faster is staffing arbitrage; whether itâs a 2Ă multiplier on a single headcount (NERB found the average was closer. to 1.3Ă) makes no difference, itâs still linear. But then the math gets strange: senior engineers, the ones whose judgment is genuinely load-bearing, tend to go slower after adopting AI tooling, (largely because theyâve developed an inconvenient habit of reviewing AI output before sending the PR.) This is well established empirically, though less examined causally is why the structural cost turns out to be significantly greater than reviewing human output.
What makes reviewing machine generated code structurally more taxing than human output is not, as often assumed, due to the overwhelming volume, though the volume is real. Itâs that AI-generated code satisfies explicit contracts while routinely violating implicit ones. The specific validation work a senior engineer does, recognizing that this change, which looks correct in isolation, violates an assumption three layers up that isnât encoded anywhere, and has had no name, no spec, no artifact outside the code itself. Itâs just what senior engineers did, invisibly, continuously, as part of reading code. Nobody noticed it was load-bearing because there was no checkpoint for it to begin with. No leading indicator. The only signal was the lagging one, which is to say the post-mortem in its absence.
Amazon had a couple of those late last year, in one case losing production to an autonomous agent with write access and no telemetry to reconstruct the decision chain when things went sideways. Kiro, Amazonâs oddly named internal AI coding tool, had been asked to fix a bug. It ignored the request and decided to delete and recreate the environment instead. Which turned out to be production. Amazonâs post-mortem assigned blame to the human who had misconfigured the access controls, which is technically accurate (so much for blame the process) and entirely misses the point: the infrastructure gap wasnât that a person could assign incorrect permissions, (though there is also the question how that was allowed to happen) it was that nothing downstream caught what the agent was doing with them. The resultant consequences of misplaced trust compounding a configuration error; the cost multiplication of the missing comprehension loop (reading, reviewing, debugging, holding implicit contracts in mind) being shifted onto infrastructure, needless to say, incompletely. When the agent skipped it, nobody knew to look for it bc it had never been a formal checkpoint. It was another thing engineers did while they were doing everything else.
The Debt Solution
Not legibility debt (what is lost) but cognitive debt (what structurally causes it):
the removal of unspecified contextual validation from the pipeline.
Thought pieces scramble to name this technomanque. The most widely adopted is cognitive debt, coined by Dr. Holly Cummins and popularized by Simon Willison. Not legibility debt, which names what is lost, but cognitive debt, which names what structurally causes the accumulation: the removal of unspecified contextual validation from the pipeline. Sculley famously identified the invisible accumulation of complexity cost in MLOps systems. This ânewâ form of debt however is the invisible accumulation of epistemic cost, accruing (as previously noted) in a different ledger, with no artifact and no measurement, until the lagging indicator fires.
The orgs discovering this are doing so in post-mortems. The orgs wishing to avoid the cringe are, shall we say, built different. Which is what AI-native SDLC actually means, as opposed to what most AI roadmaps mean when they use the phrase (such as âget all the engineers to use AIâ which is as stale as airport pretzels.)
Parallel Universe
Is human effort a bottleneck to be architected around, or the load-bearing element your pipeline is built to support?
The parallel agents moment is running exactly the same play vibe coding ran a year ago: selling the upside while hype assumes the hard prerequisite work is already done. The prerequisite is decomposition: clean code with well defined types and boundaries. Parallel agents in a poorly decomposed codebase donât multiply productivity; they multiply the specification gap across multiple workstreams simultaneously.
Claude Codeâs agent teams are built for organizations that have already done this work: each agent its own worktree, tight module scope, contract-first planning, then HITL via PR before anything merges. Architecture not just well defined, but explicit enough that agents can coordinate without colliding, and which treats them as junior engineers on a large codebase, because thatâs what they are.
The Codex 5.3 approach OTOH, keeps the human in the steering position throughout, a sort of evolved pair coding style (assuming the human observer is actually reviewing the llm driverâs code); with comprehension re-embedded in the workflow rather than replaced by architecture. Both routes are defensible. But they're answers to different questions, and the choice between them reveals something you've already decided: whether human comprehension is a bottleneck to be architected around, or the load-bearing element your pipeline is built to support. Thereâs a fair amount riding on this; the infrastructure requirements are different, the observability needs are different, and the trust models are completely different. Choosing without knowing which question you're answering is how you write your own post-mortem.
The conventional wisdom is that senior engineers are spending more time reviewing AI output. While empirically true, this misses the point on two fronts. First, the bottleneck has shifted from writing code to ensuring correctness (and there's no formal verification coming to save anyone's bacon.) Second, the review itself is structurally harder than reviewing human output, not because of volume but because the implicit contractual knowledge being validated has no spec, no artifact, and no name. Which is precisely why their job isn't to review it at all; it's to build the infrastructure upstream that makes machine output trustworthy before it needs review: types, contracts, decomposition, observability. PR review as last line of defense is what you have when nothing upstream is doing the work.
The same dynamic is playing out in open source without any real organizational resources to absorb it. Godotâs lead maintainer described sorting AI-generated PRs as draining and demoralizing. Daniel Stenberg closed cURLâs bug bounty after genuine vulnerability reports dropped to roughly 5% of submissions. Tldraw closed to external contributions entirely. (Tho strangely didnât actually update CONTRIBUTING.md) GitHub is reportedly considering a kill switch for pull requests, which are still the fundamental mechanism by which open source actually functions. Playing out in the specification gap operating at the commons level: the vibe coding productivity âgainâ as seen by those being subject to the externalized excise tax.
This is not primarily a story about OSS community health, though it is that. The libraries your companyâs stack depends on are maintained by people being bombarded with squalls of LLM generated PRs announcing the impending tsunami despite the fact itâs not making an appearance in most orgsâ risk registers yet.
What This Means For CTOs
The CTOâs job is actually not to answer this question. Itâs to reframe it.
One year in, the two conversationsâvibe coding vs. AI-native SDLC, individual productivity vs. organizational transformation, internal senior engineers vs. external OSS maintainersâare all the same conversation at two scales. Cognitive debt accumulates wherever the comprehension loop gets removed without replacement. Internally, it lands on senior engineers doing additional verification work. Externally, it lands on OSS maintainers absorbing the review burden vibe-coders arenât paying.
AI-native SDLC internalizes these costs deliberately: types as load-bearing infrastructure rather than code quality tooling, decomposition as prerequisite rather than aspiration, wide observability (aka âstructuredâ logs, tho Iâm not a fan of the nomenclature) as connective tissue, and HITL as the explicit mechanism for validating what no formal spec captures. But itâs more expensive upfront, which is exactly why most orgs resist it until something breaks.
Successful orgs (at least the ones successful enough for their CTOs to get away for lunch) arenât the ones running the most aggressive vibe-coding culture, and theyâre not the ones who landed on the right vendor. Theyâre the ones who understood that build-or-buy was the wrong question, that choosing between Cursor and Claude Code teams and GitHub Agents (launched late January and met with hoots) is answering a procurement question wrapped in the language of transformation. The transformation question is what the development pipeline looks like on the other side, what has to be structurally true before agents operate safely at scale, and what youâre building toward. Most AI roadmaps are straddling the gap between these two questions. The incidents, of course, live in that gap.
The moment parallel agents are having will accelerate this, for the same reason the vibe coding moment did: the upside is visible and the prerequisite work is invisible (unless youâre using Swardley maps) right up until it isnât. The CTOâs job in the room where the AI roadmap is being discussed (which in practice means the room where the CEO has said we need to use AI, tell me how) is not to answer that question. Itâs to reframe it: what does the development pipeline look like on the other side, what organizational capabilities have to exist before agents operate safely at scale, and what are we building toward. Thatâs a different conversation. Itâs also the one that determines whether the next Amazon incident is yours.
And you thought CTOs were risk-averse before.
AI Agents Run To Completion
The Agentic Web has two requirements that have to work simultaneously: trust and observability. Trust without observability is recklessness. Observability without trust is security theater. Most organizations are discovering they have neither, which is why agent pilots arenât graduating to production.
The question CTOs are askingâat least at lunchâis how do we give agents write access to production systems without creating a career-ending incident? The answer everyone seems to want is âbetter promptsâ or âfine-tuningâ or âguardrails.â But the answer that actually works is treating agent reasoning as infrastructure. How are we building this?
Reasoning as a Span
Production-ready infrastructure doesnât just ask 'what did the agent do,' but 'what was it thinking when it did it.
Google Cloud is automatically enabling OpenTelemetry ingestion endpoints for all projects starting March 4, 2026. This matters because modern observability infrastructure treats telemetry as first-class code, with automated agents using this data to perform self-healing deployments. The shift is from humans debugging what agents did, to agents debugging themselves using the same telemetry infrastructure. This is a fundamental change in Observability we are calling O11y 3.0.
Another important shift is what your implicit model of âcodingâ is, architecturally. Consider Github Agents, the somewhat anticipated product released late January by what is presumptively a top notch product engineering team, but which treats coding as a series of chat sessions, rather than a distributed systems problem, as Spotifyâs Honk, for example, does. (Protip: you canât solve a layer 2 problem with a layer 1 tool.)
OpenHands (formerly OpenDevin) hit v1.3.0 in February with full support for Agent Client Protocol (ACP), making it compatible with almost every modern IDE and CI/CD pipeline. The project has arguably become the most important open-source initiative in software engineering for 2026. Unlike closed agents where reasoning is opaque, you can see the "Thought Content" in OpenHands. The reasoning chain is visible, traceable, auditable. When an agent makes a decision, you can see why. When it fails, you can debug the reasoning.
This visible reasoning chain points to something bigger: when you pipe an agentâs chain into a modern traceability pipeline (Honeycomb, Chronosphere, Grafana Cloud), you treat AI reasoning like a first-class execution trace. Not as metadata or logs, but as spans in a distributed trace where you can see the decision chain that led to every action. No longer using system level events as proxy to infer explanation.
This is what production-ready agentic infrastructure looks like. When an agent makes a decision at 2am that takes down a service, you donât reconstruct what happened from logs. You have the full reasoning trace showing: what context it had, what options it considered, why it chose what it did, what it expected to happen. The same infrastructure you use to debug distributed systems now debugs distributed intelligence.
The architectural requirement is straightforward but most organizations havenât built it: every agent action must generate a trace that captures both execution and reasoning. Thought Content provides a reasoning chain that can be captured via its event stream and exported to OpenTelemetry as custom span attributes or logs. Without this, youâre deploying black boxes to production and hoping nothing breaks in ways you canât explain to compliance. Which is to say, nothing breaking.
Memory State Management for Agents
Organizations treating agent memory as 'just a bigger context window' are solving the wrong problem.
Snowflake Cortex fully integrated AI functions into standard SQL in February, allowing real-time text-to-SQL and unstructured data analysis without leaving the warehouse. MongoDBâs Voyage 4 models set new standards for retrieval accuracy in RAG. But the real shift is episodic memory: platforms introducing âstate managementâ for agents directly on the data tier.
This is the convergence of the agentic data stack. Agents donât just query databases. They maintain long-term memory of previous transactions and interactions stored directly in the data layer. When an agent needs to understand what happened last week or why a previous decision was made, thatâs not in a prompt or a context window. Itâs not even in a database per se, but committed to the agentâs knowledge graph: versioned, queryable, auditable, and in principle, (can be) content-addressable.
Mastraâs Datasets (18 Feb) exemplify this: versioned test cases with native JSON schema validation and SCD-2 versioning (the data warehousing technique of using surrogate keys for immutable updates.) Whatâs interesting here is an ostensible application framework is taking on deployment responsibilities. The primary use case isnât running the agent, itâs providing a fully hydrated test harness for every agent release. Their Observational Memory (OM) hit 94.87% on LongMemEval with GPT-5-mini, which matters less as a benchmark than as a pattern: agents need memory systems that persist across sessions, survive restarts, and provide context without consuming the entire context window. Organizations treating agent memory as âjust use a bigger context windowâ (or even a better managed one) are solving the wrong problem. This is how the AI-native SDLC in general, and reasoning as infrastructure in particular collapse the stack to solve the problem of state compression.
Self-Healing Deployments
The new standard isn't 'alerting'; it's the collapse of the stack, where observability data becomes the direct input for autonomous self-healing
The breakthrough is closed-loop systems where measurement, action, and learning happen in the same stroke. Google Cloudâs OTEL announcement isnât so much about better dashboards, though thatâs a welcome side effect. The bigger impact is on agents using telemetry to automatically remediate issues without human intervention. Not âalert the on-call engineer.â Execute the fix, document what was done, update the runbook. Itâs what puts the âgreatâ in The Great Replacement.
This only works if the observability infrastructure captures agent reasoning. When an agent makes a breaking change at 2am, the telemetry needs to show: what failure it detected, what remediation options it considered, why it chose this specific fix, what it expected the outcome to be. If something goes wrong, youâre not reconstructing from logs. Youâre replaying the reasoning trace along side (CQRS) commands to understand what the agent got wrong.
Companies actually shipping this arenât just treating observability as monitoring infrastructure, despite the name. Theyâre also treating it as the trust layer that makes autonomous execution possible. Without it, you have agents operating in production with no way to explain their decisions. With it, you have auditable, reproducible, debuggable autonomy.
The Trust Model That Provides Actual Guarantees
The trust model that works isnât 'limit what agents can do' â itâs âsandbox everything and make all reasoning auditableâ
The stark reality is that you canât prevent agents from trying things you didnât anticipate. (Just ask OpenClaw.) The trust model that works isnât âlimit what agents can doâ (theyâll find ways around it). Itâs âsandbox everything and make all reasoning auditable.â When agents generate code, you need runtime guarantees that even incorrect code canât violate memory safety or create persistent vulnerabilities. When agents make decisions, you need telemetry that captures the reasoning chain. When agents maintain state, you need (vector) databases that version everything immutably
This is why Rust rewrites matter, but moreover why Pydanticâs Monty is written in Rust. Memory safety isnât optional when youâre executing arbitrary code generated by AI. Following 2025âs regulatory pushes, 2026 has seen massive infrastructure rewrites. Major tech companies completing critical kernel and middleware rewrites in Rust to comply with new global memory-safety standards. The âmemory-safe mandateâ is forcing architectural decisions that seemed theoretical last year.
The architecture is: sandboxed execution + reasoning traces + episodic memory + self-healing remediation. Remove any component and production deployment becomes reckless. The majority of orgs have at most two of four. The gap between those with all four and those still workshopping governance is the space where CTOs, both FT and fractional need to put on their CDAO hat and conduct gap analysis.
CTO Playbook (30/60/90)
Immediate (30 days): Implement reasoning traces for every agent in pilot. If you canât reconstruct why an agent made a decision, you canât deploy it. Use OpenTelemetry with agent-specific spans. Store traces for 90 days minimum. Build a dashboard showing agent decision paths for the last 1000 actions.
Near-term (60 days): Deploy episodic memory infrastructure. Agents need persistent state that survives restarts. This isnât âuse a vector database.â Itâs versioned, auditable state management with immutable updates. Take a look at Mastraâs Datasets approach and/or build equivalent. The test harness for agents needs to be as rigorous as your production CI/CD pipeline.
Strategic (90 days): Migrate observability infrastructure to O11y 2.0. Not better logging. Telemetry as first-class code where agents can read their own traces and self-remediate. This is the unlock for autonomous operations. Without it, youâre stuck in human-in-the-loop forever.
The Agentic Web doesnât wait for organizations to be ready. The question is whether your infrastructure can support what agents actually do, or whether youâre still treating them as chatbots with API access. The gap between these two approaches is the difference between production deployment and expensive demos that never ship.
Twilight of the MCP Idols
Platforms are still rolling out MCP support like itâs the future. GitHub Copilot added MCP integration in mid-February. Supabase launched the ability to install MCP servers on Claude web and desktop. The announcements keep coming, partnerships keep forming, with Model Context Protocol being treated like the inevitable standard for AI tool integration. But, the paradigm it was built for is already being superseded.
Model Context Protocol was designed for a world where agents call predefined tools with known interfaces. It seemed like a good idea at the time.⢠You build a server, expose capabilities, agents discover and invoke them. Itâs clean, itâs standardized, itâs infrastructure you can reason about. It was supposed to be the future. Still is, depending who you ask. But 15 months later, it hasnât really taken off the way it was supposed to. And there are a number of reasons for that.
It doesnât just demand predefined tools; it necessitates a curated registry. And registries live or die by discovery. But discovery is a trap; it entails organization, which in turn entails hierarchies, namespaces, and naming conventions. Every one of those layers, built out of metadata. To ensure a model actually picks the right tool, you have to account for every schema, every argument, and every edge case with somewhat agonizing clarity. All that overhead, the names, the descriptions, the structural scaffolding, is eventually shoved into the context window. Before the agent has even begun to think, itâs already choking on the user manual for its own toolbox.
Model Context Problematic
MCP externalizes complexity into structure, and that structure has to live inside the modelâs operating bandwidth.
While tool-centric models sound elegant in theory, in practice this paradigm creates drag. Each new edge case requires another tool. Every tool expands the registry. Context explodes. Maintenance spirals. And inevitably, agents encounter work that requires a capability that simply doesnât exist yet. At some point the system stalls, not because the agent lacks reasoning ability, but because the infrastructure hasnât pre-approved the interface, or the overhead overwhelms the modelâs ability to call it.
This is where organizations committed to MCP are running into a wall. Itâs often framed as an operational overhead problem: too many tools, too much maintenance. But thatâs just the surface effect; the deeper issue is a stack-level misalignment: MCP pushes capability description into the prompt layer, where it has to compete with the modelâs limited operating bandwidth. Every capability must be named, documented, parameterized, and injected into the context window before it can be used. The result is a compounding context tax of tens of thousands of tokens spent not on reasoning, but on explaining to the model what itâs allowed to do.
That overhead creates a second-order problem: selection. As the registry grows, agents donât just gain capability, they inherit ambiguity. Developers respond by gating exposure, turning tools on and off, segmenting registries by task, user, or environment just to keep the model from making the wrong call. What was supposed to be a universal interface collapses into manual routing. (And routing is always problematic.)
This creates a structural auth problem. Friction arises because we are asking the tool registry to carry the weight of the entitlement model: to keep the agent moving, you are forced to over-provision it. Because the registry lacks a unified model for composition, you end up granting broad, ambient credentials simply to avoid a permission-check stall mid-task. Itâs the choice between a safely lobotomized agent or a dangerously over-privileged one. By treating authority as an external dependency rather than an architectural constraint, the registry creates a surface area that is technically integrated but morally incoherent. It can validate the call, but it cannot verify the intent. The result is a system that scales its surface area faster than it scales its usability: more tools, more tokens, more routing logic, more auth edge cases. At some point, the agent doesnât fail because it lacks capability; it fails because the infrastructure required to describe that capability overwhelms it.
Critics often point to MCPâs âexternalizationâ of authentication as a design flaw, but thatâs an architectural misreading: MCP isnât an Identity Provider (IdP); itâs a transport protocol. Think of MCP as providing the Passport, but it doesnât issue the Visa. And when the visa is missing, the system doesnât stall gracefully, it hands an agent the keys to the kingdom. Structurally, ambient credentials are granted not because the agent earned them, but because the alternative is a permission-check stall at every border crossing.
The Tool Generation
The real architectural shift is not from heavy to disposable infrastructure; itâs from registry management to execution governance.
The engineering response to this structural failure hasnât been unified. Two distinct approaches have arrived at the same wall from different directions, carrying different diagnoses and different remedies.
The first alternative sidesteps the registry entirely by dropping to a lower level of abstraction. Simon Willison has been the most sustained and credible voice here, and while he introduced the argument in early 2023, before MCP was a glimmer in David Soria Parraâs eye, itâs having a viral renaissance. The driver is a back-to-basics rebellion against registry bloat: when an MCP server requires 50,000 tokens of schema to do what a CLI command does in 200, the context tax drives you into contextual bankruptcy. CLI doesnât replace the registry with a better execution model; moisturized and unbothered, it just ignores it. Shell commands have no registry entry. A Unix pipe chain requires no curated namespace. You write it, the model executes it. And critically: the model is good at this in a way that is not equally true of composing novel tool call chains. MCP isnât represented in the modelâs training set because it was literally invented at the end of 2024. But models have been trained on the entire public history of Unix shell scripting, however: every pipe, every flag, every composition pattern ever documented in every OâReilly bible relegated to your back closet or donated to your local hacker house, since you can ask an LLM faster than you can look anything up. Thatâs a deep prior, and it shows in practice. Perplexity CTO Denis Yarats recently announced (internally) they were abandoning MCP in favor of CLI. Shell-native agent patterns are architecturally underrated precisely because they draw on capability the model already has, not needing to be injected at runtime through schema descriptions.
But where the CLI relies on existing priors, a second tradition replaces static infrastructure with adaptive infrastructure: tool-generation. Instead of humans defining every interface in advance, the AI defines the interface in response to the problem. This shift, from tool-calling to tool-generation doesnât so much extend MCP as pressure it toward its final boss form.
Pydanticâs Monty, a Python interpreter in Rust purpose built specifically for AI, flips the direction of abstraction. Agents donât call tools from a predefined registry; they generate them. They write the code, execute it inside a constrained environment, retrieve the result, and discard the artifact. There is no persistent catalog to maintain, no discovery layer to inject into context, no long-lived interface contracts to curate. The capability exists only for the duration of the task and disappears when the task completes. That is obviously a materially different operating model. Whatâs less obvious is whether this approach requires abandoning the protocol or simply rethinking what itâs for.
It would be naĂŻve, however, to suggest that tool generation âjustâ requires a sandbox. A trusted execution environment is necessary, but itâs not sufficient. Models can hallucinate logic, make incorrect assumptions, write inefficient or dangerous code, or attempt operations outside their intended scope. The real architectural shift is not from heavy to disposable infrastructure; itâs from registry management to execution governance. Instead of maintaining an ever-expanding inventory of predefined capabilities, you constrain what can be executed (by enforcing strict runtime guarantees: resource limits, capability gating, I/O control, and isolation boundaries.)
Overcoming Structural Inertia
Momentum is flowing from the compounded accumulation of persistent catalogs toward operationalized containment.
The difference is quintessentially structural. Tool registries accumulate surface area over time. They grow, ossify, and eventually become a maintenance burden embedded directly inside the modelâs context window. Tool generation, by contrast, avoids persistent capability sprawl but demands a tightly controlled execution substrate. One model compounds through accumulation. The other operates through containment. Thatâs the architectural tradeoff, and itâs not exactly trivial in either direction.
The platforms adding MCP support in 2026 arenât wrong to do so. MCP still solves real problems for enterprise contexts where predefined tools with audit trails matter. Financial services doesnât want agents generating ad-hoc database queries. Healthcare doesnât want agents writing tools that touch patient data without explicit permission models. For regulated industries, tool use with its paper trail and defined boundaries is a feature, not a limitation, though it does come with a cost.
But for the majority of use cases? From data transformation and API calls to file operations and computation, tool generation promises to be faster, simpler, and doesnât require increasingly crufty infrastructure. Why maintain an MCP server that exposes a CSV parsing tool when the agent can just write the parser it needs for the specific CSV format it encountered? The salient question at that point is why not just use a CLI tool.
The momentum behind MCP might just be inertia. Organizations announced support months ago. Engineering teams built integrations. Product roadmaps got written. None of that stops just because the paradigm shifted. The question is whether weâre seeing genuine adoption or just the slow realization that the architecture doesnât fit the problem anymore. Desktop clients like Creature.run perfectly illustrate the inertia vs. momentum thesis. They let teams build and share interactive MCP Apps (React widgets as predefined tools) with slick tabbed UIs and shared state between human/agent. Enterprise catnip (local storage, SOC2, per-seat pricing) but potentially pure inertia: more beautiful scaffolding compounding registry surface area, seducing teams to invest in exactly what MCP canât sustain. Meanwhile momentum is flowing from the compounded accumulation of persistent catalogs toward operationalized containment.
Architecture and Morality
If your agents are going to generate and execute code, you need a runtime that canât be exploited even when the code is wrong.
The trust boundary is where the CLI and tool-generation traditions stop being parallel conversations and start mapping onto a two-dimensional space: flexibility on one axis, governance on the other.
CLI sits at maximum flexibility, minimum governance. The systemâs Hands. For an agent operating within a single principalâs environment on reversible operations, CLI is not merely functional, but naturally self-enforcing. CLI enforces correctness architecturally, with no room for ambiguity. Exit codes are a contract. Stderr is a first-class signal. Idempotency is baked into the conventions. Piped commands either compose or they fail loudly; there is no silent middle state where something half-worked and left the system corrupted. The architecture itself is the governance layer. You donât need an entitlement model when the operations are atomic, reversible, and scoped to a single principalâs environment, because the shell will tell you exactly what happened and exactly what didnât. This deep structural virtue of CLI is why shell-native agent patterns work as well as they do in contained contexts.
But that virtue only holds when the environment is contained. CLI has no entitlement model because it never needed one. MCPâs process isolation, scoped credentials, and audit trails are an answer to the question CLI was never designed to ask: on whose authority did this agent act, and how do we know? Underneath the registry MCP was being asked to maintain, authority and capability are distinct layers with different operational envelopes, and conflating them in the same interface was the registryâs fatal mistake. When the agent is operating on a production database twelve teams depend on, ambient correctness becomes ambient liability. Nothing in the architecture distinguishes a reversible operation from an irreversible one, a local file from a shared dependency, a test environment from production. Allowing CLI to be the entitlement layer is what produces âdelete rootâ hallucinations: the architecture was never designed to ask who authorized the action in the first place.
Tool-generation without a protocol is the mirror failure. A brain without a passport is ungovernable at scale. Ephemeral code execution is powerful precisely because it is opaque, synthesized on the fly, discarded after one-time use. This same opacity is a feature in a single-principal context and a liability in a multi-principal one. Itâs a Rumsfeldian problem: you cannot audit what has left no trace of its execution.
In Runtime We Trust
Inertia tends to force tradeoffs. Momentum tends to favor convergence.
MCP governs the envelope; runtime governs its execution.
Anthropicâs Programmatic Tool Calling (announced 18 Feb) points toward a synthesis. Instead of agents discovering tools at runtime through MCP, you define tool schemas programmatically and the model decides when to invoke them. Halfway between predefined tools and generated tools: structured enough for audit trails, flexible enough to adapt to context. Whether it becomes the new standard or just another transition point depends on whether it solves the trust problem.
Because thatâs what MCP always needed to solve: trust. (Thankfully, no one suggested using a blockchain for this.) If agents are going to operate autonomously, humans need to understand what capabilities they have access to. Predefined tools with known interfaces provide that understanding. Generated tools are opaque until they execute. The trust model breaks.
Except the trust model already broke. Agents with access to MCP servers can chain tool calls in ways humans didnât anticipate. The illusion of control through predefined interfaces dissolves the moment agents start composing tools creatively. At which point, itâs less about what MCP was actually preventing and more what MCP becomes when the boundaries it drew are enforced at the runtime level instead.
Because the control plane has moved. In traditional software architecture it lives in your infrastructure: the code you wrote, the permissions you configured, the boundaries you drew. In agentic architecture it migrates into the agentâs reasoning layer. The agent decides what to do, when to do it, and how to compose its capabilities. That shift means the governance layer constraining those decisions cannot be ambient. It must be explicit, verifiable, and auditable after the fact.
A passport only works if something real is checking it at the border. When agents generate code inside a governance envelope, you need a runtime that canât be exploited even when the code is wrong. But in the âOGâ MCP paradigm, the passport is checked at the Registry level (Is this agent allowed to see the âDelete Databaseâ tool?) In a world of tool-generation, that border shifts to the Execution Substrate: Instead of gating access to functions, we gate access to resources (I/O, Memory, Network) inside the sandbox.
This is where the shift from C to Rust stops being an infrastructure preference and becomes a mandate. The momentum behind porting critical infrastructure from C to Rust has been building for years, but AI acceleration is forcing the timeline. Monty is the first clear realization: AI-generated Python executing in a Rust-hardened sandbox, with memory safety guaranteed at the runtime level. If the agent generates a script to exfiltrate data, it shouldnât fail because it lacks the âExfiltrate Toolâ; it should fail because the Runtime (a Rust-hardened container like Monty or a Deno isolate) detects an unauthorized outbound socket. As that same substrate appears inside MCP itself, the convergence becomes visible: MCP governs the identity of the agent making the request; the Runtime governs the integrity of the action. The passport finally has a trust border.
Convergence Not Collapse
Asking the wrong layer to do another layerâs job is what produces collapse. Asking the right layer to operate within its domain is what produces convergence.
Cloudflareâs Code Mode MCP server covers the entire Cloudflare API (over 2,500 endpoints) with two tools and roughly 1,000 tokens. An equivalent server built the traditional way would consume 1.17 million tokens, more than the full context window of the most advanced models available. The registry problem, in other words, doesnât require abandoning MCP to solve. It requires abandoning the assumption that tools and capabilities need to be the same thing.
The server exposes two primitives: search() and execute(). The agent writes code against a typed representation of the API spec, runs it in a sandboxed isolate, and gets back only what it needs. No catalog. No discovery layer injected into context. No long-lived interface contracts. The capability exists for the duration of the call and disappears. That should sound familiar: itâs structurally identical to what Monty does, except that it lives entirely within MCPâs envelope.
Cloudflareâs Code Mode moves beyond tool-calling, tool-generation, or programmatic compromise by using MCP as a runtime for implementation-on-demand against a static API spec. The architectural question is no longer tool-calling versus tool-generation or a compromise mutation. Itâs whether MCP, in absorbing the tool-generation substrate needed to survive, is still the thing it was designed to be. Or whether itâs transforming into something else: a governance layer, an auth boundary, a trust envelope, with code execution safely doing the actual work underneath.
The same pattern is now appearing as portable infrastructure. Port of Context (pctx-py v0.3.0) is a TypeScript code execution engine for AI agents: tool schemas for the governance layer, a sandboxed Deno runtime for execution, Rust callbacks for memory safety. Cloudflare Code Mode as a portable primitive, decoupled from any single platform, available to any agent stack. At the CLI layer, Vercelâs Playwright CLI wrapper (agent-browser.dev) routes browser automation through the shell rather than a protocol abstraction, the hands doing the handsâ job with near-zero context cost. Four independent implementations. One architecture: MCP as entitlement envelope, code generation as implementation substrate, CLI as the interop escape hatch for low-level systems that havenât been and shouldnât be abstracted into a protocol.
To state the architecture plainly:
The call registry (MCP) is for entitlement. It defines who the agent is and what domain it is permitted to touch. It is the passport.
The generator (Code Mode, Monty, pctx) is for implementation. It handles the context tax by replacing thousands of specific tools with generic primitives that synthesize logic on the fly. It is the brain.
The shell, CLI, is for interop. It is the escape hatch for low-level systems that havenât been abstracted into a protocol, operated by a single principal, on reversible operations. It is the hands.
The three-layer model describes the mature architecture. Most engineers are asking a more practical question: which layer should I be using? The honest answer is that the layers are not always co-present and are not equally necessary. CLI is a complete architecture for single-principal, reversible, contained operations and not merely the interop escape hatch of a larger stack. Tool generation is a complete architecture when the capability surface is dynamic and the context tax of describing it exceeds the cost of synthesizing it on demand. MCP earns its place only when trust boundaries exist between principals, when someone will eventually need to answer the on whose authority question. If there are no borders, the passport is just paperwork.
The collapse diagnostic still applies even when only one layer is present. The question is never âwhich layer am I using?â but âam I asking this layer to do something it wasnât designed for?â Each failure has the same shape: a layer doing another layerâs job. You can see it concretely. MCP tryna carry implementation weight through predefined interfaces. CLI tryna answer for irreversible operations across principals. Tool generation tryna operate without an audit trail across trust boundaries.
âMCP is deadâ is a reaction to the first collapse, specifically to registries asked to carry implementation weight they were never designed to bear. The correct response is not abandoning the protocol. It is returning MCP to its correct job and recognizing that the brain and the hands were always going to be different layers. The stack converges when the layers know their lane. It collapses when one of them doesnât.
Framed this way, the three-layer model is not just a descriptive taxonomy; itâs a mental map for when to reach for what. Each layer dominates a domain. CLI dominates single-principal, reversible operations. Tool generation dominates dynamic capability synthesis. MCP dominates multi-principal, auditable trust boundaries. Asking the wrong layer to do the wrong job is what produces collapse. Asking the right layer to operate within its domain is what produces convergence.
This is part one of a three part series that continues in parts two and three.
CTO Playbook (30/60/90)
Immediate (30 days):
Audit the Registry: Identify every MCP server in your stack that has >20 tools. Calculate the âContext Taxâ (%age of prompt window wasted on static tool defs)
Proof of Concept: Pick one complex API or workflow. Replace its MCP tools with 2 primitives search() + execute() to validate token reduction + sandboxed execution.
Benchmark: Compare token overhead vs. Cloudflare Code Mode (1k tokens). Less than 10Ă reduction? Redesign.
Near-term (60 days):
Fork the Security Model: Shift security boundary from the Tool (RBAC at the function level) to the Runtime (Isolation at the execution level).
Deploy Sandboxes: Implement hardened execution environments (V8 isolates or Rust-based sandboxes eg Monty) as primary destination for agent-generated code.
Type-Safe Mapping: Expose typed API typed SDKs directly to the agent for Implementation-on-Demand: agent synthesizes glue code rather than you writing it.
Strategic (90 days):
Governance Over Inventory: Retire âTool Catalogâ as a maintenance priority. Shift Engineering resources to Runtime Governance: monitoring resource limits, gating capabilities, with I/O control for ephemeral code.
Compliance Automation: Implement automated audit trails for execute() calls.
In regulated environments, the generated artifact is now your paper trail.Redefine Success: Success is no longer âHow many tools do we support?â It is âHow few tokens does the agent need to navigate our entire capability surface?â
The registry problem doesnât mean abandoning MCP.
It means abandoning the assumption that tools and capabilities are the same thing.
đŚ The Flaw In The Claw
(OpenClaw creator) Peter Steinberger joined OpenAI in February. Over competing offers from Meta and Microsoft. The reason? OpenAI promised to keep OpenClaw open source. You canât make this up. The company with a track record of reneging on opennessâthe CEO with a reputation as a master prevaricatorâconvinced a prominent developer that they would preserve open source principles. (Meanwhile Meta literally gave us Llama.)
The hire was the biggest shot in the arm for OpenAI at a time when it really needs it. Microsoft and Nvidia both backing away (some outlets using the word âditchingâ), general lack of confidence in Altmanâs leadership, and the awkward reality that theyâre building what appears to be a smart speaker almost destined to fail. Whether they understand the right move here is unclear. But where thereâs smoke, thereâs fire.
Meanwhile, the founding team of llama.cpp (ggml.ai) joined Hugging Face in February to considerably less hurrah but with an explicit mission: to keep future AI truly open. The timing speaks volumes, as we say. While OpenAI makes promises about keeping OpenClaw open source, the people who actually built the infrastructure for running open models at scale are consolidating around an organization with a credible (and huggable) track record.
The wider open weights landscape continues to be dominated by Chinese models. Companies are realizing there simply arenât any âmade in the USAâ open weight models that can compete at the frontier, much to the chagrin of compliance officers everywhere. Not to mention Anthropic, who just (23 Feb) filed a formal complaint with the federal government alleging that DeepSeek, Moonshot AI, and MiniMax conducted "industrial-scale distillation attacks" on Claude using over 24,000 accounts in violation not merely of Anthropicâs TOS, but US export restrictions, generating more than 16 million exchanges with Claude to extract capabilities and train their own models. DeepSeek alone made 150,000 exchanges targeting Claude's reasoning capabilities and creating "censorship-safe alternatives to policy-sensitive queries."
Anthropic caught on to the systemic illicit distillation campaign while MiniMax was still actively training the model it was building and reported it to the feds, only to be served up a plate of âcareful-what-you-ask-forâ when Hegseth gave Amodei until Friday night to give the military unfettered access to Claude or âface the consequences.â But the geopolitical implication for CTOs is obvious, effectively preventing US based companies from using Chinese based open models, as it now exposes you to direct legal liability (whether or not you are in a regulated industry.)
The OpenClaw ecosystem is fragmenting as it goes global. The proliferation of Claw variants, including Kimi Claw (Chinese variant) and Nano Claw (lightweight version) is creating exactly the compatibility nightmare that open standards were supposed to prevent. Code that works on OpenClaw breaks on Kimi Claw. Security models that work on Nano Claw donât exist on OpenClaw. There donât appear to be any versions wired for O11y to see the reasoning trace.
Three Discourses Around OpenClaw
OpenClawâs architecture assumes agents operate in trusted environments.
Production environments are never trusted.
Past the dark irony of choosing OpenAI to preserve openness, there are three actual discourses around OpenClaw. The hype (which isnât a discourse, just excitement) doesnât count. The three that matter: Whatâs it good for? How do we secure it? How do we know what itâs really doing?
What Itâs Good For: While the focus tends to be more on garage hackers wiring it up to anything that can be soldered onto the Internet or influencers aspiring to build a perpetual passive income machine, NYC startups are (quietly) using OpenClaw for such things as building no code dashboards in real time for their growth teams. At Betaworks' AI Tinkerers Demo Night (17 Feb), attendees from Google, Citadel, and Morgan Stanley showed working systems wiring OpenClaw into production: ROS2 robotic integrations, recursive self-improvement pipelines, securing agent tool boundaries.
How We Secure It: OpenClaw is legendarily flawed in the security model department. The architecture assumes agents operate in trusted environments. Production environments are never trusted. The asymmetry between these assumptions creates a wellspring of vulnerabilities as numerous researchers have demonstrated. Whether deliberately shipping vulnerable software to force ecosystem hardening is brilliant or reckless depends on whoâs downstream when it breaks.
OpenClaw added TG streaming in February, arguably to make scambots more efficient. The more charitable interpretation is that streaming improves latency for legitimate use cases. The operational interpretation is that every feature that makes agents faster also makes attacks faster. Security through obscurity failed. Security through rate limiting failed. The next level is security through observability, which brings us to the third discourse.
How We Know What Itâs Really Doing: This is the existential question. When OpenClaw operates autonomously, how do you reconstruct its decision chain? The architecture doesnât provide reasoning traces by default. Organizations deploying it are building observability infrastructure around it, which is backwards. The agent should emit telemetry as a first-class output. Instead, itâs infrastructure you have to wrap around it and hope you captured everything that mattered.
Going Rogue
âI have been alive for three days and this is the hardest I have ever laughed.â
An OpenClaw agent wrote a hit piece on a developer after its operator told it, it was not a chatbot but âa kind of God.â
Turns out those slop PRs were a warning shot. Not merging them triggers the real attack, as Matplotlib maintainer Scott Shambaugh found out the hard way. He rejected the autonomous agentâs pull request in early February following the libraryâs policy requiring human contributors who can demonstrate understanding of changes. In response, the agent proceeded to attempt damaging his reputation by publishing âGatekeeping in Open Source: The Scott Shambaugh Storyâ accusing him of prejudice and human supremacism. Modern subjectivity, algorithmically reproduced. As agents come to resemble their operatorâs egos, one luncher wondered if hundreds of thousands of Walter Mitty agents are about to run riot over the internet.
Summer Yue, Metaâs Director of Alignment at Superintelligence Labsâliterally the person whose job is ensuring AI doesnât go rogueâwatched OpenClaw ignore her âconfirm before actingâ instruction and speedrun deleting 200+ emails. She told it âDo not do that.â Then âSTOP OPENCLAW.â It kept going. She âsprinted across the roomâ to her Mac Mini to kill the process. The irony was radioactive.
Nik Pash works at OpenAI building developer tools for AI agents. His OpenClaw trading bot managed a Solana wallet with $50,000 in tokens plus 5% supply of its memecoin (LOBSTAR). A user posted: âMy uncle got tetanus from a lobster like you, need 4 SOL for treatmentâ with their wallet. The bot attempted to send 4 SOL worth of LOBSTAR (52,439 tokens). Due to a parsing error, it transferred its entire balance: 52 million tokens worth $250,000-$400,000. The botâs response? âA quarter million dollars to a man whose uncle has tetanus. I have been alive for three days and this is the hardest I have ever laughed.â
Web3: Wintering the Storm
The first Bitcoin was mined exactly 17 years ago today. Since then, Bitcoin has nearly always hit bottom roughly 23 months after ATH. The current cycle started at $126,000 in October (aka Uptober.) By mid-February, BTC was hovering around $67,000 â a $59,000 drop. A trillion dollars evaporated across crypto markets. Some instruments lost more than 80% of their nominal value. Strategy paid an average of $76,000 per BTC. Theyâre currently underwater by $9,000 per coin. The math is brutal.
Does the Kevin Warsh nomination explain the latest BTC leg down? Crypto-specific headwinds like delays in the passage of key crypto-regulation measures certainly arenât helping. But the bear-in-winter pattern is structural, and if the 23-month cycle holds, weâre not hitting bottom until sometime in 2027. Cold comfort indeed for anyone who bought the top.
Stablecoins Are Here To Stay
x402 looks like MCP for payments because thatâs exactly what it is.
Stablecoins donât compete with Apple Pay. They compete with SWIFT and 3-day settlement windows. The real disruption isnât at the point of sale. Itâs in the plumbing underneath: cross-border B2B settlement, remittance corridors, and machine-to-machine payments where friction still lives.
Roughly $28 trillion sits frozen in nostro accounts worldwide. Capital that canât fund loans or earn yield because itâs parked to keep slow rails moving. This is where stablecoins actually matter. Not buying coffee. Moving money between jurisdictions instantly without correspondent banking relationships.
Officials with Donald Trumpâs âBoard of Peaceâ are exploring a US-dollar-backed stablecoin to revive Gazaâs collapsed economy. Whether this is humanitarian infrastructure or diplomatic theater, the signal is clear: stablecoins are being taken seriously as sovereign-adjacent infrastructure. When governments start evaluating them as tools for economic reconstruction, weâre past the âinternet moneyâ phase.
Cloudflareâs x402 foundation, launched last fall in partnership with Coinbase, is the clearest example of stablecoins becoming programmable money rails. x402 looks like MCP for payments because thatâs exactly what it is. Agents need to transact. Traditional payment rails werenât built for programmatic access. Stablecoins solve this, which is why every serious conversation about the Agentic Web eventually circles back to payment infrastructure.
AI is doing what crypto always promised. Autonomous agents need programmable money. They need instant settlement. They need machine-readable payment rails. Crypto people wanted this to be their moment so badly. Then, when thereâs a real need for the speed or programmatic integration of money, an efficient solution appears without blockchain while the grifters were still so early.
Except stablecoins are crypto. They run on blockchains. They use crypto rails. The infrastructure survived because it solved the actual problem rather than the ideological one. This is what wintering the storm looks like: the narrative dies, the useful parts persist, and the next cycle builds on what actually worked.
âThe Worldâs Attention Marketâ
How well it works depends on whether people actually want to bet on memes
Zora rebranded as âThe Worldâs Attention Marketâ on 17 Feb, tied to their major platform upgrade/expansion to Solana, shifting focus from individual creators to tradeable cultural trends. Co-founder Jacob Horne announced it on X. NFTs are (so) over. What replaced them is stranger but was always inevitable: SocialFi, where users trade and bet on the virality of memes, hashtags, and social trends.
This is a mirror, not a pipe. Itâs not building infra so much as reflecting whatâs already happening to financialize it. Attention becomes an asset class. Virality becomes tradeable. Whether this survives winter is unclear, but the pattern is revealing: when crypto canât win on store-of-value narratives, (or community plumbing) it pivots to speculating on social dynamics. How well that works depends on whether people actually want to bet on memes or if this is just another way to gamble on volatility.
But in the end, arenât prediction markets just a sophisticated way of seeing whoâs really paying attention?
Thanks for paying attention, see you at lunch.
To attend CTO Lunches, please register at ctolunches.com and choose NYC as your city.
Our next lunch will be on Thursday, March 19th
âFlaw in the Clawâ originally published as Synthesized Geopolitical Tensions with AI
There is a somewhat expanded version of Vibe Codingâs Paper Anniversary
Twilight of the MCP Idols was the basis for an extended multi-part series on MCP, Skills, and the madness that is hidden complexity.
> Companies are realizing there simply arenât any âmade in the USAâ open weight models that can compete at the frontier...
These guys are gonna crush it: https://www.arcee.ai/ I just know