2026

TL;DR The 2026 agent ecosystem has, while nobody was paying close attention, converged on three protocols that solve different problems and partly overlap: MCP (Model Context Protocol), A2A (Agent-to-Agent), and ACP (Agent Communication Protocol). MCP is the model-to-tool protocol. It standardises how an agent talks to its tools, data sources, and local context. This is the one that has clearly won its layer. A2A is the agent-to-agent protocol. It standardises how separately deployed agents discover each other, exchange tasks, and pass results. Adoption is growing but the picture is less settled. ACP is the orchestration-and-runtime protocol. It standardises how an agent runtime exposes its lifecycle, state, and operations to the systems around it. Newer, more enterprise-focused, and not yet a clear winner. The mental model: MCP for tools, A2A for peers, ACP for the platform. Build with all three in mind even if you only need one today. Why Protocols, Why Now A year ago “agents” was still a debate about whether the things existed. By mid-2026 the debate has shifted. Agents exist. They do useful work. The interesting question is no longer “will this work” but “how do we connect them to everything else.” ...

TL;DR Kubernetes won the orchestration argument years ago. The question is no longer “should we use Kubernetes.” It is “should this particular team, with this particular workload, with this particular budget, pay the operational tax.” For genuinely large, multi-tenant, multi-region platforms with dedicated infrastructure teams, the answer is still mostly yes. The ecosystem maturity is unmatched and the alternatives lose at scale. For mid-sized engineering organisations, the answer in 2026 is probably not, and increasingly not. Managed serverless, container platforms like Fly and Railway, and the new generation of platform-as-a-service offerings are competitive in ways they were not three years ago. For startups and small teams, the answer is almost always no, and stop pretending otherwise. The honest read in 2026: Kubernetes is the right answer to fewer questions than it used to be, and being honest about that is now a competitive advantage rather than a heresy. How We Got Here Kubernetes was the right idea at the right time. By the late 2010s, every serious engineering team needed an answer to “how do we run containers in production.” Kubernetes provided one, it was open, it was backed by a credible foundation, and the cloud providers all blessed it. Within five years it was the default. Within ten years it was the assumption. ...

TL;DR Artemis III is supposed to land two astronauts near the lunar south pole using a stripped-down SpaceX Starship as the Human Landing System (HLS). The architecture is genuinely audacious - it requires a new super-heavy rocket to fly several times before the crewed mission, on-orbit cryogenic propellant transfer at a scale that has never been demonstrated, and a lunar surface stay enabled by a vehicle three times taller than the Saturn V’s lunar module. The technical risk is concentrated in propellant transfer, boil-off management, engine relight reliability, and crew ingress/egress from a 50-metre tower on a sloped, unprepared surface. The schedule risk is concentrated in everything that has to happen before the crewed flight - and most of it has not happened yet. The mission can succeed. The honest read in mid-2026 is that it will succeed late, and the more interesting question is which of these subsystems is actually the long pole. How Artemis III Is Supposed To Work Artemis III’s architecture is not Apollo. Apollo carried everything it needed in one stack on a Saturn V. Artemis III spreads the mission across multiple launches, multiple vehicles, and two distinct propulsion systems, with a crew transfer in lunar orbit. ...

A technical reader’s guide to where AI and crypto actually meet - without the hype. TL;DR The AI-token sector has stratified. There is a clear top tier of projects with real engineering, real revenue and visible institutional interest, and a long tail of speculation. The total AI-crypto market just crossed $17B and the measurable-infrastructure share is growing faster than the speculative tail. The five tokens worth understanding in May 2026 are Bittensor (TAO) as the conviction long, Virtuals Protocol (VIRTUAL) as the speculative growth bet, Render (RENDER) as the infrastructure hold, Artificial Superintelligence Alliance (FET / ASI) as the deep value play, and NEAR Protocol (NEAR) as the AI commerce layer. Every name on the list has drawn down 60%+ from its all-time high in the last 18 months. The drawdowns are not theoretical and they will happen again. Position-sizing matters more than picks. Worth flagging without putting them in the main basket - Kite (KITE), Internet Computer (ICP) and The Graph (GRT). Worth avoiding - the long tail of “AI memecoin” launches. Nothing here is investment advice. Prices are snapshots from publicly available data (CoinGecko, CoinMarketCap) as of 4 May 2026 and will be stale within hours. Why The Sector Looks Different In 2026 A year ago the AI-token sector was mostly a betting market on which token had “AI” most prominently in its tagline. In May 2026 the picture has changed character. There is a clear top tier of projects with measurable engineering output, real revenue, and visible institutional interest, and a long tail of names whose only product is a narrative. The total AI-crypto market cap just crossed $17B, and the share of that capital flowing into infrastructure with measurable usage has grown faster than the speculative tail. ...

TL;DR Low Earth orbit (LEO) in 2026 contains roughly 40,000 tracked objects larger than 10cm and an estimated 1 million pieces of debris between 1cm and 10cm. Most of it is dead satellites, spent stages, and fragments from past collisions or anti-satellite tests. The economics are a textbook tragedy of the commons. Each launch operator captures the upside of putting hardware in orbit. The cost of debris is shared across every other operator and every future mission. There is no global price on creating debris. The risk is non-linear. Kessler syndrome - a cascade where collisions create more debris that triggers more collisions - is not a hypothetical. We are already in the early stages in some altitude bands. The fix is also a textbook commons solution: price the externality. End-of-life deorbit requirements, debris remediation funds, transparent collision-avoidance markets, and active debris removal services. Some of this exists. Most of it is undersupplied. The realistic 2026 picture: not yet a crisis, on a trajectory that becomes one within a decade if nothing changes, with the most useful policy interventions being the ones that price debris creation directly rather than relying on goodwill. The Numbers Order-of-magnitude figures, drawn from ESA’s space debris office and LeoLabs tracking data, as of 2026: ...

TL;DR The self-hosted vs managed decision in 2026 is genuinely different from the same decision in 2022. The math has shifted in three directions: cloud egress costs, AI workload economics, and self-hosted tooling maturity. Managed remains the right default for most teams. The thing that has changed is that the threshold at which self-hosting becomes worth considering has dropped. Workloads that were obviously managed in 2022 are genuine 50/50 calls in 2026. The most important shift is that self-hosting is no longer synonymous with on-premises. Modern self-hosting often means renting bare-metal in a colocation, running your own clusters in a hyperscaler, or using sovereign cloud providers - all with different economics. For specific categories - AI inference at scale, data egress-heavy workloads, predictable steady-state compute, regulated environments - self-hosting now wins on cost more often than people assume. The honest framing: managed is the right default; self-hosting is the right minority case; the minority is bigger than it used to be. Why This Decision Got Harder For most of the 2010s the answer was easy. Managed services were cheaper than self-hosting once you priced in operational overhead. The cloud providers competed aggressively. Self-hosting was for the regulated, the eccentric, and the very large. ...

TL;DR With the open table format wars largely settled, the strategic fight in 2026 has moved up to the catalog layer - the system that manages tables, namespaces, governance, and access. Four credible open or open-ish catalogs are now in serious play: Unity Catalog (Databricks), Polaris (Snowflake), Apache Gravitino (Datastrato/community), and Project Nessie (Dremio/community). All four implement the Iceberg REST catalog spec to varying degrees, which means clients can talk to them through a common protocol. The differentiation has moved to governance, multi-tenancy, lineage, federation, and developer experience. Unity is the most production-mature and the most coupled to Databricks. Polaris is the cleanest open implementation of the REST spec. Gravitino is the most ambitious in scope - aiming to catalog non-table assets too. Nessie is the most opinionated about Git-style branching for data. The winning catalog will probably not be a single project. It will be the protocol (Iceberg REST) plus multiple compliant implementations plus federation between them. That is the picture 2026 ends with. Why The Catalog Layer Matters Now A table format defines how data is laid out on disk. A catalog defines: ...

TL;DR One year after Polkadot 2.0 shipped its three flagship pieces - Agile Coretime, Elastic Scaling, and Asynchronous Backing - the picture is mixed but mostly positive. What worked: core prices collapsed, network utilization roughly doubled, and the barrier to entry is now hundreds of dollars instead of millions. New teams are shipping that would never have run a crowdloan. What did not: the secondary market for cores is thin, bulk sales are dominated by a small set of repeat bidders, and the developer story for “buy a core and ship something” is still rougher than it should be. The honest verdict: Agile Coretime delivered on the economics. It did not deliver on the user-experience promise. Polkadot 2.0 is a better foundation than Polkadot 1.0 by every measurable metric, but the application layer is still where the network has to prove itself. Where We Were A Year Ago Last September I wrote a plain-English explainer of Agile Coretime. The pitch was simple: stop selling parachain slots like reserved parking spaces and start selling them like a parking meter. Pay for what you use, when you use it. Resell what you do not. ...

The local vs. cloud AI debate used to be simple: cloud was smarter, local was cheaper and private. In 2026 that framing has collapsed. The hardware caught up to the software. Unified memory on Apple Silicon and 24GB+ VRAM cards like the RTX 50-series mean local inference is no longer a compromise - it is a deliberate architectural choice. Professional engineers are not “trying to see if Llama runs on a Mac” anymore. They are building sophisticated Hybrid AI Stacks where local and cloud models each handle the workloads they are genuinely suited for. Here is the tradeoff landscape as it stands today. ...

TL;DR The core trade-off is pay-per-use (APIs) vs pay-for-capacity (GPUs) - APIs are cheaper at low volume, GPUs win massively at high volume (100M+ tokens/day) The break-even point for GPU self-hosting sits around 2 to 5 million tokens per day for premium-model workloads - below that, APIs almost always win GPU utilisation is the most important variable: at less than 50-60% utilisation, self-hosted inference costs more per token than just calling an API Hidden costs matter - real GPU spend is 2x to 5x the raw hardware price once you add DevOps, scaling, monitoring, and networking; API costs can also balloon from poor prompt design and multi-step agent loops Most serious production systems land on a hybrid architecture: APIs for complex reasoning and long-context work, GPUs for bulk inference, embeddings, and fine-tuned models If you’re building anything with LLMs right now, you’ll hit this question sooner than you expect: ...