AI Weekly: Opus 5 Lands, MCP Goes Stateless, and AMD Ships Helios

Week of July 22 to July 29, 2026

Four things moved this week, one in each layer of the stack. Anthropic released Claude Opus 5 on July 24 at unchanged Opus pricing with benchmark results that beat the tier above it. Coding agent vendors kept shipping approval modes and audit surfaces instead of benchmark wins. The Model Context Protocol published its 2026-07-28 specification on Tuesday, the largest rewrite since launch, removing sessions from the protocol entirely. And AMD moved Helios rack-scale systems into production with customer commitments measured in gigawatts.

Starting this issue, the newsletter runs the same four sections every week in the same order: models, tooling, standards, infrastructure. Models set what is possible. Tooling decides who gets to use it. Standards decide whether the pieces connect. Infrastructure sets the price.

Models: Claude Opus 5 Beats the Tier Above It

Anthropic released Claude Opus 5 on Friday, July 24, 2026, available the same day on the Claude API, Claude.ai, Claude Code, and Claude Cowork under the model ID claude-opus-5. It is the company’s fourth model in under two months, following Mythos 5, Fable 5, and Sonnet 5 in June.

The pricing is the headline. Opus 5 costs $5 per million input tokens and $25 per million output tokens, identical to Opus 4.8 and half of Fable 5’s rates. A Fast mode roughly doubles the price to $10 and $50 and runs about 2.5 times faster. Cached input bills at one tenth of the base input rate, and asynchronous batch processing carries a 50 percent discount. Context is 1 million tokens as both default and maximum, with no smaller variant. Maximum output is 128,000 tokens on the synchronous Messages API, reaching 300,000 through the Message Batches API with a beta header. The minimum cacheable prompt dropped from 1,024 tokens to 512.

On benchmarks, the numbers are strong and they come from Anthropic’s own testing, so read them as vendor-reported. On FrontierBench v0.1, a 74-task successor to Terminal-Bench 2.1, Opus 5 scored 43.3 percent at max effort against 18.7 percent for Opus 4.8, 33.7 percent for Fable 5, and 37.5 percent for GPT-5.6 Sol. At the highest effort setting it reached 44.4 percent mean reward. Anthropic’s published tables also show Opus 5 leading on GDPval-AA, ARC-AGI-3, OSWorld 2.0, and AutomationBench. The losses are disclosed too: it trails on legal and health evaluations where Mythos 5 leads, and GPT-5.6 Sol edges it on one agentic coding test.

Two details matter more than the scores.

The first is the effort setting. Opus 5 exposes a per-request low, medium, or high control over how much reasoning the model spends. That turns cost against capability into a runtime decision rather than a model selection decision. A pipeline running the same model at low effort for routine classification and high effort for hard reasoning gets better economics than one that routes between two models and maintains two prompt sets.

The second is the knowledge cutoff. Opus 5 carries a reliable cutoff of May 2026 against January 2026 for both Fable 5 and Opus 4.8. For coding work that touches recent library versions or infrastructure released in the last two quarters, a four-month gap in training data affects output quality more than a few benchmark points do. Anyone writing code against the MCP 2026-07-28 spec discussed later in this issue has a direct interest in which model has seen the relevant material.

Anthropic positioned the release unusually. The company is not claiming a new capability ceiling. Fable 5 remains the most capable public model, with restricted Mythos 5 above it. Product leader Dianne Penn told Reuters that users should pick Opus 5 for value and reserve Fable 5 for days-long autonomous projects. Opus 5 is now the default on Claude Max and the strongest model available on Claude Pro, so most paying subscribers received the upgrade without changing anything.

Two operational notes for teams migrating. The API ships two breaking changes, and code moved over untouched risks 400 errors or truncated output, so read the migration guide before swapping the model ID. And Anthropic tells developers to delete verification prompts. Instructions like asking the model to include a final verification step now cause over-verification, because the model already verifies its own work. Prompt patterns tuned for an older generation actively hurt on this one, which is a good reminder that a model swap is not a configuration change.

On data handling, Opus 5 supports zero data retention, which Fable 5 does not under its 30-day requirement. It also carries less restrictive cybersecurity safeguards than Fable 5 and is described as the most aligned model the company has measured, with the lowest observed rates of deceptive behavior.

Kimi K3 opens its weights

The open-weight side of the market did not stay quiet. Moonshot AI’s Kimi K3 reached full open weights on July 27, 2026 after an API-first launch. K3 is a 2.8-trillion-parameter sparse mixture-of-experts model, the largest open model available at release. It handles text, images, and video natively and supports a 1-million-token context window.

The engineering is worth reading even if you never run it. MXFP4 weight quantization brings storage down to roughly 1.4 terabytes, which puts multi-node self-hosting inside reach for organizations that own hardware. A LatentMoE framework coordinates 896 experts with about 16 active per token. Two architectural additions, Kimi Delta Attention and Attention Residuals, target long-context efficiency, which is the cost center that makes million-token windows expensive to serve.

Pricing lands at roughly $3 per million input tokens and $15 per million output tokens, noticeably below comparable US frontier models. On benchmarks the model took first place across six of seven domains in the Frontend Code Arena and scored 88.3 on Terminal-Bench 2.1. Moonshot also ships Kimi Code, a terminal agent built on the K-series flagship, with a free quota and paid plans starting at $19 per month.

What the release cadence means for your architecture

Trackers now log a notable model roughly every two to three days once strong open-weight releases are counted. Two patterns come out of that.

Price per unit of capability is falling faster than capability is rising. Opus 5 delivers near-flagship results at half the flagship price with no change from the model it replaces. Kimi K3 puts a 2.8-trillion-parameter multimodal model on open weights at $3 and $15. The practical consequence is that the model line item in a budget written in January is wrong by July, and wrong in your favor.

The second pattern is that tier boundaries have stopped meaning much. Anthropic shipped four models in under two months across four tiers, and the mid-tier model beats the tier above it on several benchmarks while trailing on others. Selecting a model by tier name produces worse results than selecting by evaluation on your own workload. Build the evaluation harness once and re-run it on every release. That harness is the durable asset. The model behind it is a swappable part.

Tooling: The Control Plane Became the Product

The coding agent market spent late July competing on operations rather than model quality, and the pattern is consistent enough across vendors that it looks like a shared realization.

GitHub added Claude Opus 5 to GitHub Copilot across supported Copilot applications and IDEs. GitHub describes the model as built for complex, long-running coding tasks that need careful reasoning, effective tool use, and reliable execution across multiple steps, and reports strong early testing results on agentic workflows including autonomous code changes, regression verification, and tasks that coordinate several tools.

Note what GitHub chose to highlight. Not completion quality. Not benchmark scores. Regression verification and multi-tool coordination. Those are the things that determine whether an agent’s output is trustworthy enough to merge.

A late-July roundup of Codex and Claude Code updates makes the pattern explicit. OpenAI’s July Codex notes added interactive forms in task transcripts, Mermaid diagram rendering, prompt recovery, the ability to resume goals that were blocked or hit usage limits, better task lists, and more reliable cross-device task handling. Claude Code’s July updates added in-app browsing, a /doctor command for environment diagnosis, /fork, public artifact sharing, artifact access to each viewer’s own MCP connectors, editor roles, and broader auto mode availability across Amazon Bedrock, Google Cloud’s Agent Platform, and Microsoft Foundry.

GitHub’s July 7 JetBrains changelog added Codex as an agent provider in public preview, expanded the customizations editor with hooks support and richer MCP server management, added custom model support for Business and Enterprise administrators, and added approval settings for Copilot CLI sessions.

Read that list as a whole and the competitive axis is obvious. Approval modes. Resumable work. Credential boundaries. Audit surfaces. Review loops. These are the features an engineering manager asks about before rolling a tool out to fifty developers, and none of them show up on a leaderboard.

The in-app browser in Claude Code deserves specific attention, because it is not primarily a documentation reader. It gives the agent a review loop against websites, dashboards, and hosted applications. An agent that changes a frontend and then looks at the rendered result is doing something categorically different from an agent that changes a frontend and reports that the diff compiled. Verification loops are what turn plausible output into correct output.

The pricing picture shifted too, and it shifted toward metering. Current pricing across the major tools as of July 23 puts GitHub Copilot at free and $10 per month for Pro, running on usage-based billing since June 1 where one AI Credit equals one cent, with a Max tier at $100 per month. Claude Code arrives through Claude plans at $20 per month for Pro and $100 or $200 per month for Max, running Claude Sonnet 5 by default. OpenAI Codex is included with ChatGPT plans on token-based credits and has run the GPT-5.6 family since July 9. Cursor lists Pro at $20, Pro+ at $60, and Ultra at $200 per month, with Cursor’s own documentation noting that daily agent users typically land closer to $60 to $100 per month than $20. Moonshot’s Kimi Code entered the terminal agent market with a free quota and paid plans starting at $19 per month.

The gap between Cursor’s list price and Cursor’s own estimate of what daily agent users actually pay is the most honest number in that whole set. Agentic coding consumes tokens at a rate that flat subscriptions cannot absorb, and every vendor is converging on metering because the underlying economics leave no alternative.

For teams standardizing this quarter, the sequence that makes sense is approval policy first, credential boundaries second, model choice third. Model quality changes every eight weeks. Your policy for what an agent is allowed to do without a human in the loop should not.

How to evaluate a coding agent in August 2026

Model benchmarks have stopped being useful for tool selection because the leaders change every few weeks and the differences at the top are small compared to the differences in how the tools behave in your repository. A better evaluation runs on seven questions.

What does the agent do without asking? Every tool has an approval model. Read it carefully and test the edges, especially around file deletion, dependency installation, and anything that touches a remote system.

Which credentials does it hold, and for how long? An agent with a long-lived cloud credential is a standing risk. An agent that requests scoped, short-lived access per task is a different security posture entirely.

Can it resume? Long-running tasks fail for boring reasons. Network drops, usage limits, laptop sleep. The tools that added resumable goals this month did it because that failure mode is constant.

Does it verify its own work? An agent that runs tests, reads the rendered output, or checks a regression suite produces a different quality of change than one that stops at the diff.

What does the audit trail look like? For any regulated environment, the question of what an agent did, when, under whose identity, and with what approval is not optional. Task transcripts and artifact sharing exist for this reason.

How does it handle your MCP connectors? Agents increasingly reach your data through MCP servers, and the auth story between agent, MCP server, and data platform is where most real incidents will originate.

What does it actually cost at your usage? Run a two-week pilot with real work and measure. The list price is a marketing number.

Agents are showing up outside the IDE

Coding is the visible edge of a broader move. Google Threat Intelligence took its agentic capabilities from public preview to general availability for Enterprise and Enterprise Plus customers, targeting threat hunting, incident response, and daily alert triage, with one workflow staying preview-only. On the industrial side, Altia launched an AI layer inside its human-machine interface workflow on July 21 that connects to any model and assists across the development process, with a notable policy attached: the company says no AI-generated code ships in production.

Those two launches bracket the range of what enterprises are comfortable with right now. Security triage is a domain where the volume is overwhelming and the cost of a missed alert is high, so automation wins even with imperfect precision. Safety-critical embedded software is a domain where the cost of a subtle defect is measured in recalls, so the agent assists and humans still write what ships. Most organizations sit somewhere between those poles, and the honest answer about where you sit depends on your blast radius, not on your enthusiasm.

Standards: MCP Drops Sessions and Grows Up

The Model Context Protocol published its 2026-07-28 specification on Tuesday, written by lead maintainers David Soria Parra and Den Delimarsky. The release candidate had been locked since May 21, giving SDK maintainers a ten-week window to validate changes against real workloads before the final publication.

Start with the scale numbers, because they explain why the changes are what they are. Across the Tier 1 SDKs, the project reports close to half a billion downloads a month, with both the TypeScript and Python SDKs crossing one billion total downloads. A protocol at that adoption level stops being a developer convenience and becomes infrastructure. Infrastructure gets judged on how it behaves at 3 a.m. during an incident, not on how fast you can wire up a demo.

Why sessions were the problem

To understand why this release matters, it helps to remember what MCP looked like at the start. The protocol was designed for a local model: an AI application starts a server as a subprocess, talks to it over standard input and output, and both sides hold a live connection for the duration of the conversation. In that setting a session is free. The connection is the session.

Remote MCP servers broke that assumption. Streamable HTTP arrived in the 2025-03-26 revision and replaced the earlier HTTP plus server-sent events transport, using one endpoint that supports POST and GET with optional streaming for server-to-client messages. Sessions were tracked with an Mcp-Session-Id header. That design worked, and it dragged a long tail of operational requirements behind it.

Every team that ran MCP at scale hit the same wall. A session identifier means a request must reach the instance that holds that session, so you configure sticky routing. Sticky routing means an instance restart drops live conversations, so you add a shared session store. A shared store means a new failure domain and a new latency hop on every call. Autoscaling gets harder because scaling in kills sessions. Blue-green deployment gets harder for the same reason. None of that has anything to do with connecting a model to a tool. All of it was mandatory.

The 2026-07-28 revision deletes the requirement at the root. That is the right place to fix a problem like this, and it is the harder place, which is why it took eighteen months and a breaking change to get there.

The stateless core

The headline change is that MCP is now a request/response protocol instead of a bidirectional stateful one. The initialize and initialized exchange is retired. The Mcp-Session-Id header is gone. Each request carries its own protocol version, client identity, and client capabilities in a _meta field. Clients that want to learn a server’s capabilities up front call a new server/discover RPC, and that call is optional.

The practical effect on a deployment is immediate and large. Before this release, running a remote MCP server in production meant sticky session routing at the load balancer, a shared session store like Redis behind it, and often deep packet inspection at the gateway to figure out what a request was actually doing. All of that existed to reconstruct state the transport assumed but did not carry. With the stateless core, any request lands on any server instance behind an ordinary round-robin load balancer with no shared storage.

The maintainers make an important clarification about what stateless does not mean. Dropping protocol-level sessions does not force your application to be stateless. If a server needs to carry state across calls, the recommended pattern is to mint an explicit handle from a tool and have the model pass that handle back as an argument on the next call. The reasoning behind that recommendation is the interesting part: when state lives in an explicit handle, the model can see it and thread it between tools. When state hides in the transport, the model is operating blind on something that affects its results.

That distinction is worth sitting with if you build agents. Hidden state is the single most common source of agent behavior that looks random. An agent that fetched a result under one session, lost the session, and retried under another has no way to notice or explain what changed. An agent holding a visible handle does.

Multi Round-Trip Requests

The stateless core created a problem the spec had to solve. Some server operations need something from the user in the middle of a call. A confirmation before a destructive action. A missing parameter. A sampling request back to the model. Under the old design those flows used server-initiated requests like elicitation/create, sampling/createMessage, and roots/list, all of which required a stream held open in both directions.

Multi Round-Trip Requests replace that pattern. The server returns a result with resultType: "input_required" plus the specific requests it needs answered. The client gathers answers and retries the original call with them attached in inputResponses. No open stream, no session, and every step is a plain HTTP request/response pair that any proxy in the path understands.

Supabase called this out as the change that unblocks a feature they wanted. Their MCP server runs statelessly, which made elicitation impractical under the old design. With MRTR, their tools can confirm with the user before acting, giving examples like the cost of creating a new project or a query that deletes data. That is a concrete safety improvement, and it exists because the protocol stopped requiring a persistent connection to ask a question.

Header-based routing and cacheable lists

Streamable HTTP requests now must carry Mcp-Method and Mcp-Name headers. Method and tool names travel in HTTP headers instead of only inside the JSON body. Gateways, rate limiters, and web application firewalls route, meter, and authorize on those headers directly, without parsing request bodies.

If you have ever tried to rate-limit an expensive tool differently from a cheap one, or block a specific tool at the edge for a specific tenant, you know why this matters. Under the old design that required a gateway that understood JSON-RPC payload structure. Now it requires a header match rule, which every piece of network infrastructure built in the last thirty years already supports.

Responses from tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope fields. Clients cache tool catalogs for as long as the server says is safe, and list responses have a deterministic order. Deterministic ordering matters more than it sounds: if a tool catalog comes back in a different order on each reconnect, the prompt that lists those tools changes, and every upstream prompt cache misses. Stable ordering plus explicit TTLs keeps those caches warm across reconnects, which shows up directly on the token bill.

Authorization hardening

The maintainers state plainly that authorization is where implementers spend most of their integration time, and this revision goes after several specific weaknesses.

Authorization servers should now return the iss parameter per RFC 9207, and clients must validate it before redeeming an authorization code. That closes the authorization server mix-up attack, where a client tricked into talking to a malicious authorization server hands a code to the wrong party.

Clients now set application_type during Dynamic Client Registration, which fixes a long-running annoyance where authorization servers rejected localhost redirect URIs for desktop and command-line applications. If you have debugged a CLI OAuth flow that died on a redirect_uri error, that was the cause.

Client credentials are now bound to the issuer that minted them, with no reuse across authorization servers. And Dynamic Client Registration itself is formally deprecated in favor of Client ID Metadata Documents. DCR keeps working for backward compatibility and gets removed in a future revision.

Extensions, Tasks, and deprecations

The release locks in a formal extensions framework. Tasks, which handles long-running operations, moved out of the experimental core into the io.modelcontextprotocol/tasks extension, with a poll-based tasks/get and a new tasks/update. AWS contributed that extension. MCP Apps, which covers server-rendered user interfaces, and Enterprise Managed Authorization sit alongside it as extensions rather than core features.

That structure solves a governance problem as much as a technical one. Under a monolithic spec, every capability has to ship on the spec’s release cadence, so useful work waits for unrelated work. Extensions ship on their own timelines and version independently. The core stays small enough that a new implementation is achievable by a small team.

Change notifications move off the old HTTP GET endpoint to a single subscriptions/listen stream that clients opt into per notification type. Roots, Sampling, and Logging are deprecated. They keep working for at least twelve months, and new implementations should not adopt them. The legacy HTTP+SSE transport is officially deprecated with a year-long offramp.

That twelve-month floor comes from a new formal deprecation policy, which is one of the most underrated items in the release. A dated protocol with a written deprecation window lets a platform team plan an upgrade quarter instead of reacting to a surprise. Vendors who need to certify software against a spec version now have something to certify against.

SDKs and ecosystem

All four Tier 1 SDKs speak the new version as of publication day: TypeScript, Python, Go, and C#. The Rust SDK supports it in beta.

The ecosystem response tells you how deep MCP has embedded itself. AWS reports the stateless core available in Amazon Bedrock AgentCore, letting developers deploy MCP servers on standard infrastructure without managing sessions or persistent connections. Cloudflare’s Agents SDK supports the spec from day zero, so developers run MCP servers directly in Workers, with customers like Sentry and Linear picking up the improvements immediately. Microsoft ties MCP to Foundry’s unified toolbox endpoint, describing it as what let them scale from dozens of integrations to thousands while centralizing governance, identity, and observability. Google Cloud framed the stateless architecture as removing friction from deploying agentic workflows at scale.

Two data points from smaller players say more than the platform quotes. Honeycomb reports that nearly 20 percent of all monthly interactive queries on their platform now come from agents. Manufact, which hosts thousands of MCP servers, reports that the new SDK cut their package size by roughly 83 percent and made it about 25 percent faster thanks to the client-server split.

Twenty percent of interactive queries coming from agents is the number to sit with. That is not a pilot. That is a workload class.

Migration reality

This release breaks things, and the maintainers say so directly. Servers speaking 2026-07-28 will not necessarily work with older clients, and older servers will not necessarily work with new clients. Teams that depended on session identifiers have real migration work ahead of them, though the SDK maintainers incorporated early testing feedback specifically to reduce that cost.

Here is a practical checklist for anyone running MCP servers in production this quarter:

1. Inventory every place your server depends on Mcp-Session-Id or on state that lives across calls in memory. Each one becomes an explicit handle minted by a tool.

2. Replace server-initiated elicitation and sampling with MRTR flows. Test the retry path carefully, because the client now resends the original call.

3. Add Mcp-Method and Mcp-Name to every outbound request if you write a client. Add header-based rules to your gateway if you operate one.

4. Set ttlMs and cacheScope on list responses deliberately rather than accepting defaults. Too long and clients miss new tools. Too short and you pay for cache misses on every reconnect.

5. Move off Dynamic Client Registration toward Client ID Metadata Documents. Validate iss per RFC 9207 on every code redemption.

6. Audit for Roots, Sampling, and Logging usage. You have twelve months, which sounds long and is not.

7. Plan the HTTP+SSE transport retirement on the same year-long clock.

Do the inventory in step one first. It usually surfaces state you did not know you were carrying.

What this changes for data and analytics teams

If your team exposes data through an MCP server, this release changes your architecture in four specific ways.

Deployment gets ordinary. An MCP server that fronts a query engine or a catalog becomes a stateless HTTP service, which means it deploys the same way as every other service you already run. Same autoscaling rules, same rolling updates, same health checks. The special handling goes away.

Authorization gets a real story. The issuer binding and RFC 9207 validation changes close attack paths that security review teams ask about by name. If you have been stuck in a review because nobody had a good answer for authorization server mix-up, you now have one.

Tool catalogs get cacheable, which changes cost. A data MCP server often exposes a large tool surface: one tool per dataset, per metric, or per saved query. Sending that catalog on every reconnect was expensive in tokens and in latency. With ttlMs and deterministic ordering, clients cache it and upstream prompt caches stay warm.

Long-running work gets a home. Analytical queries do not finish in a request timeout. The Tasks extension gives long-running operations a poll-based lifecycle instead of forcing you to invent one. For anything that scans a large table, that is the difference between a working integration and a pile of timeout workarounds.

The one thing that does not change is the hard part. A protocol that connects an agent to your data does not tell the agent what your data means. Column names, business definitions, join paths, and freshness expectations still have to come from somewhere, and that somewhere is a semantic layer with governance attached. MCP moved the plumbing problem out of the way. The meaning problem is still yours.

Infrastructure: AMD Ships Helios, NVIDIA Points Agents at Silicon

The hardware news this week was concentrated in one event and one partnership.

At Advancing AI 2026 in San Francisco on July 23, AMD launched its next-generation AI infrastructure and physical AI portfolio, led by Helios rack-scale solutions now in production for deployment at gigawatt scale. CEO Lisa Su used the keynote to move from roadmap slides to shipping silicon, walking through volume production details for the MI400 accelerator family, the Helios rack built around it, and EPYC Venice, the first x86 server processor built on TSMC’s 2 nanometer node.

The customer commitments are the story. AMD confirmed that OpenAI and Meta together account for 12 gigawatts of committed accelerator capacity, with Microsoft Azure and Oracle named as early Helios customers. Meta’s portion is a separately confirmed 6 gigawatt deployment across multiple chip generations, starting with roughly 1 gigawatt of MI450-class hardware in the second half of 2026. Converting gigawatts to chip counts is imprecise because power draw varies by generation and cooling design, but industry estimates put one gigawatt at roughly 25,000 to 50,000 high-end accelerators. That puts the combined commitments in the range of several hundred thousand chips at full deployment.

Anthropic and AMD detailed a partnership to deploy up to 2 gigawatts of AMD Instinct MI455X GPUs in Helios racks, paired with a multiyear engineering collaboration that uses Claude to accelerate AMD software development. The specific targets are workload optimization for Instinct GPUs and ROCm software development, and AMD plans broad Claude adoption across its engineering and product teams. OpenAI and AMD announced a parallel effort to optimize the stack from silicon to software.

The ROCm detail is the one worth watching. AMD’s hardware has been competitive on paper for several generations. The software has been the gap. SemiAnalysis, which in December 2024 gave AMD no chance of breaking NVIDIA’s CUDA advantage, revised that assessment on July 25, 2026 to a strong chance of success conditional on two risks: the Helios rack production ramp, where weak SerDes require retiming up to 85 percent of the backplane with more than 550 Broadcom ethernet retimers per rack, and a persistent shortage of stable internal GPU clusters for software development.

That second risk is exactly what the Anthropic collaboration attacks. Using a frontier model to accelerate kernel and library development is a direct answer to a software velocity problem, and it makes AMD’s competitive position partly a function of how well AI-assisted systems programming works in practice. If it works, that is a meaningful data point well beyond one vendor’s roadmap.

NVIDIA had its own week. The company announced a long-term partnership with Safe Superintelligence Inc. on July 27 to accelerate SSI’s growth. On July 26 it announced a collaboration with Cadence and Synopsys aimed at chip design complexity, and expanded the NVIDIA Agent Toolkit for engineering with PhysicsNeMo and CUDA-X libraries exposed as agent-ready tools and skills.

The chip design angle is a closed loop worth naming. NVIDIA is applying AI agents to silicon engineering because chip complexity per generation is outgrowing what traditional design methods handle, according to Tim Costa, the company’s VP and general manager of computational engineering. Chips designed with agent assistance run the models that power the agents that design the next chips. Every step in that loop that gets faster compounds.

On market structure, TrendForce data cited in the same chip maker analysis puts ASIC-based systems at about 27 percent of 2026 AI server unit shipments, down slightly from an April estimate of 27.8 percent after chip validation and tuning delays at Meta and AWS, against 69.7 percent for GPU-based systems, with ASICs projected to reach roughly 40 percent by 2030. The custom silicon story is real and it is slower than the headlines suggest.

For data platform teams, the practical read on all of this is about supply and price rather than architecture. Two credible accelerator vendors at gigawatt scale means better availability and better negotiating position than a single-vendor market. It also means your inference and embedding workloads need to be portable enough to move, which puts a premium on standard formats and standard interfaces at every layer of the stack.

The Data Layer: Format Work That Makes AI Workloads Cheaper

One story this week connects the protocol news and the hardware news to the storage layer underneath both, and it came out of an Apache mailing list rather than a press release.

The Apache Parquet community voted to add ALP encoding to the Parquet format, with the vote passing on 11 +1 votes, 7 of them binding. ALP stands for Adaptive Lossless floating-Point. It compresses double and float columns by finding a decimal representation that maps values to integers, encoding those integers with existing integer techniques, and applying a fallback scheme for values that do not fit the pattern.

Floating point has been the worst-compressing column type in analytical storage for as long as columnar formats have existed. General purpose compressors do poorly on it because IEEE 754 bit patterns look close to random. That mattered moderately in a world of financial metrics and sensor readings. It matters enormously in a world where a meaningful fraction of stored data is embedding vectors, model scores, and feature values, all of which are float arrays.

Parquet is working the string side of the same problem through the FSST spec, which reached general consensus this week according to Arnav Balyan. FSST builds a symbol table of common substrings and encodes against it, which handles the repeated-prefix and shared-vocabulary patterns that show up in logs, identifiers, and document text.

Parquet also merged a FILE logical type, and the Apache Iceberg community immediately opened a proposal for a matching file data type in Iceberg V4. That gives tables a first-class way to reference documents, images, and other blobs sitting in object storage, with the reference metadata stored in the table itself and queryable through SQL.

Put those three together and the destination is clear. A table where one row holds structured columns, semi-structured JSON, an embedding vector, and a reference to the source document, all in one open format, all compressed properly, all queryable through one interface. That is the storage substrate a retrieval pipeline actually needs, and it removes the usual arrangement where a vector database, a document store, and a warehouse each hold a partial copy of the truth and drift apart.

The connection to the MCP news is direct. Agents that query data through MCP servers are only as good as the data layer underneath. If that layer is three disconnected systems, the agent gets three inconsistent answers and no way to tell which is right. If it is one governed lakehouse, the agent gets one answer with lineage attached.

Where the compute money is going

One number frames the rest of the hardware story. Gigawatts, not chip counts, are now the unit of measure in accelerator announcements. That shift happened because power is the binding constraint. Fabs have capacity. Grid interconnects, transformers, and cooling do not. When a vendor announces gigawatt-scale commitments, the interesting question is not whether the chips exist but where the power comes from and when the substation gets built.

This matters for anyone planning data platform capacity, even indirectly. Inference pricing tracks accelerator availability, and accelerator availability tracks power delivery schedules that run on multi-year timelines. Pricing on frontier models has moved down steadily through 2026, with introductory rates and tiered families becoming standard. The direction is favorable and the volatility is real, which argues for architectures where switching a model provider is a configuration change rather than a rewrite.

The same logic applies to the ASIC question. Custom silicon at roughly 27 percent of 2026 AI server shipments, headed toward 40 percent by 2030 on current projections, means a meaningful share of inference will run on hardware you do not choose and cannot benchmark directly. Your defense against that is the same as your defense against everything else in this stack. Keep the interfaces standard, keep the data in open formats, and keep the ability to move.

What This Week Means If You Build With AI

Five takeaways worth acting on.

Treat the MCP upgrade as a scheduled project, not a background chore. The breaking changes are real, the twelve-month deprecation windows are generous but finite, and the migration surfaces hidden state you probably do not have documented. Teams that do the session inventory in August will have a much better September than teams that discover the problem when a client stops connecting.

Stateless is a scaling decision and a debuggability decision. The maintainers made the case that explicit handles beat hidden transport state because the model can see them. That reasoning applies well beyond MCP. Anywhere your agent architecture keeps state the model cannot inspect, you have created a class of bug that reproduces poorly and explains badly.

Standardize agent policy before agent tooling. The coding agent vendors converged on approval modes, credential boundaries, and audit surfaces this month because that is what enterprise buyers demand. Write your policy for what agents do unattended, which credentials they hold, and what gets logged. Then pick tools that implement it. Doing it in the other order means rewriting the policy every time a vendor ships a release.

Budget for metering. Cursor’s own documentation puts daily agent users at three to five times the list subscription price. GitHub moved to credits. Codex runs on token-based credits. Any capacity plan built on flat per-seat pricing is going to be wrong, and the error runs in one direction.

Keep the data layer open enough to move. Two accelerator vendors at gigawatt scale, four Tier 1 MCP SDKs, and a Parquet format gaining first-class support for float and string compression all point the same way. The parts of the stack that are standardized are the parts you can renegotiate. The parts that are proprietary are the parts that set your price.

The pattern across every story this week is the same one that showed up in the Apache mailing lists: the AI stack is trading demo velocity for operational guarantees. Sessions became handles. Monolithic specs became core plus extensions. Coding agents grew approval gates. Accelerator roadmaps became production deployments with named customers. None of it is exciting in the way a new model release is exciting. All of it is what has to happen before any of this runs a business.

What to Watch Next Week

Four things are worth tracking as August opens.

MCP client adoption rates. The spec is final and the Tier 1 SDKs shipped on day one, but the number that matters is how fast client applications adopt it. A server speaking 2026-07-28 does not necessarily work with an older client. Expect a period where server authors run both versions in parallel and expect the migration guides to get better as the first wave of production upgrades produces real war stories. The Rust SDK moving from beta to stable is the milestone to watch for anyone building in that ecosystem.

Whether extensions actually ship independently. The extensions framework is a promise about release cadence. Tasks, MCP Apps, and Enterprise Managed Authorization are the first test of it. If those three evolve on their own timelines without dragging the core spec along, the framework works. If the next core revision bundles extension changes anyway, it does not.

Helios production ramp reports. The retiming issue flagged in the SemiAnalysis assessment, requiring hundreds of ethernet retimers per rack, is the kind of manufacturing detail that separates an announced deployment from a delivered one. Watch for customer deployment confirmations from Microsoft Azure and Oracle rather than vendor slides.

ALP and FSST reference implementations. The Parquet format vote is the easy half. Reference implementations in Java, C++, and Rust are what determine when these encodings reach the data you actually query. Compression improvements on float and string columns show up on your storage bill and your scan times, so this is worth following even if format internals are not your usual reading.

One broader thing to keep an eye on: the number of places where an AI standard and a data standard now touch each other. MCP servers fronting catalogs. Catalogs deciding how agents authenticate. Table formats adding types designed for the data AI produces. Those used to be separate conversations happening in separate communities. They are converging fast, and the teams that read both sides will build better systems than the teams that read one.

Resources to Go Further

AI moves fast. Here are tools and resources to help you keep pace.

Try Dremio Free - Experience agentic analytics and an Apache Iceberg-powered lakehouse. Start your free trial

Learn Agentic AI with Data - Dremio’s agentic analytics features let your AI agents query and act on live data. Explore Dremio Agentic AI

Join the Community - Connect with data engineers and AI practitioners building on open standards. Join the Dremio Developer Community

Book: The 2026 Guide to AI-Assisted Development - Covers prompt engineering, agent workflows, MCP, evaluation, security, and career paths. Get it on Amazon

Book: Using AI Agents for Data Engineering and Data Analysis - A practical guide to Claude Code, Google Antigravity, OpenAI Codex, and more. Get it on Amazon

Browse the full catalog of 50+ books at books.alexmerced.com.

Alex Merced, Data Lakehouse and AI Evangelist