Durable Objects are Made for Agents

For the last few months, I've been building almost exclusively with Cloudflare Durable Objects (DOs). They are a wonderful primitive for building products (particularly agents), and I wish more providers out there had a similar offering. There really isn't anything like them in the market.

As I was comparing notes with various friends, I realized that most people haven't really even heard of DOs, and don't understand why they are such a big deal. It's a shame because they really are a near-perfect fit for building agents on top of them.

I won't gloss over the fact that there are shortcomings with DOs, and I wanted to share some thoughts about where they shine as well as where they fall short.

Disclosure: I am long a small amount of NET and am very bullish on their prospects.

What are Durable Objects?

Durable Objects combine a few simple concepts...

1. A serverless V8 isolate for running your code. It spins up and down on demand. You write some form of code that is JS/WASM compatible and it runs within v8. You have access to a subset of Node APIs. Each instance is keyed by ID, so you write code, which then is invoked many times (a la Lambda) but with unique context. This is essentially the same thing a Cloudflare Worker is doing.
2. A paired SQLite instance per DO. You get the ability to read and write to durable storage, and not really have to worry that much about reading and writing from the database.
3. Request routing to a particular isolate. The system that Cloudflare orchestrates in the background is the request routing and spinning up and down of each isolate.

Rather than thinking about your code as a bunch of services which talk to a database, you start thinking about your service as a set of many 'objects' which are event driven by new requests or by timers you can set (called alarms). Each one gets an ID, and requests are routed accordingly to a single isolate by ID. To see what I mean, here's what a simplified version of a Chat Room looks like:

// src/index.ts
import { DurableObject } from "cloudflare:workers";

export interface Env {
  CHAT_ROOMS: DurableObjectNamespace<ChatRoom>;
}

// The outer Worker routes each request to the right room.
export default {
  async fetch(request: Request, env: Env) {
    // Example: /room/general
    const name = new URL(request.url).pathname.split("/").pop();
    if (!name) return new Response("Not found", { status: 404 });

    // Every request for the same name reaches the same object.
    const room = env.CHAT_ROOMS.getByName(name);
    return room.fetch(request);
  },
} satisfies ExportedHandler<Env>;

Each ChatRoom instance then handles its own state: it accepts websockets and broadcasts every message to everyone connected to that room:

// One Durable Object instance is one chat room.
export class ChatRoom extends DurableObject<Env> {
  private sockets = new Set<WebSocket>();

  async fetch(_request: Request): Promise<Response> {
    const { 0: client, 1: server } = new WebSocketPair();
    server.accept();
    this.sockets.add(server);

    server.addEventListener("message", (event) => {
      for (const socket of this.sockets) socket.send(event.data);
    });
    server.addEventListener("close", () => {
      this.sockets.delete(server);
    });

    return new Response(null, { status: 101, webSocket: client });
  }
}

Once you start thinking this way... you start wanting to make everything a DO.

Sticking with the chat metaphor... suppose you are spinning up a Slack clone (as is trendy to talk about these days). You might lay out your data model like this:

WorkspaceDO: name, slug, channels, members
ChannelDO: name, topic, is_private, messages

When a user loads Slack, they typically want some sort of notification feed on the workspace, and a realtime feed of a channel. Sending a message to a channel should be ordered. You typically don't query across channels (except for a search use case, which can hit a vector store). If you wanted to go nuts you could even have specific ThreadDOs, or UserDOs, or any sort of DB you don't need to JOIN against.

The great parts about DOs

Starting with the beginning of the dev lifecycle, an extremely underrated part of working with DOs is their local dev setup. Locally, you run your services using wrangler. It's a CLI that functions as a local env + all-in-one toolkit for working with Cloudflare.

I initially was a bit weirded out by this, but using wrangler for local dev is actually quite nice. It becomes really quick to test changes when your coding agent doesn't rely on Docker or Postgres. Because it's all running SQLite in prod, the production drift for connecting to a DB is fairly minimal.

DOs also run explicitly in a single-threaded manner. That means you have to worry less about locking and concurrency. You know that only one invocation of your DO is running against its storage at a time.

Durable Objects also come with native support for websockets. This is a godsend for anyone who has spent a long time thinking about fan-out for large-scale notification feeds. Rather than having some sort of large multi-tiered fanout system, you just keep connections warm per-DO, and then broadcast to any connected listeners. It's perfect for building agents or Slack-like experiences.

Binding to other DOs, services, or R2 buckets all feels much more intuitive vs what I'd see with AWS or GCP. You simply specify the bindings in the wrangler.jsonc configuration, and then you get the ability to talk to the service. No need to think about complex network rules, VPCs, Security Groups, or NAT ingress.

By far the biggest benefit of DOs is that they are super cheap. They only cost you for storage when paused. You can spin up as many of them as you'd like. They are basically the perfect primitive for 'per-agent' workloads. All of my infra for running a decently sized multi-agent workload was something like $10/mo, where on AWS it's easily 10-50x the cost.

Preview environments are ~close to free. Since DOs are cheap and don't cost anything while idle, you can just tell your agent to create new versions in CI on every single branch and deploy and then clean them up later.

As a last bonus, I find working with Cloudflare infra to be extremely token efficient. To build a chat room implementation, you only require a few lines of code. Like humans, coding agents that have to explore the sprawl across a large codebase tend to slow way way down.

If you do decide to go the DO route and don't really care much about the internals, I'd recommend using either Think or Flue. Both make a lot of fairly sane choices in my opinion.

What's harder

I said before that DOs had an amazing concurrency model because they are single-threaded. This is true, but you can't just straight up ignore the complexity either. There's a good blog post on this which goes into detail, but the gist is that some functions get marked as having readable/writable gates. If you aren't careful, some part of your function may end up sampling from an LLM before writing to storage; and that hangs all your subscribers! I hit a few cases where agent-generated code would end up blocking read requests for 10s of seconds at a time.

I also hit a few reliability issues early on that I just had no ability to go and fix. Stuff like misconfigured gateways to cloud LLM APIs, or inability to deploy via the Cloudflare APIs. These weren't necessarily DO-specific things, but I felt like I wasn't getting the same level of observability or control that I might from AWS/GCP/Azure.

If you decide to use DOs, the first-class support is all Typescript. In general I'm a fan of Typescript, but you should know that if you want to work in Rust, Golang, or Python, you will have fewer options available and fewer examples.

I ended up just using my own types rather than the Wrangler typegen. For a long time I couldn't figure out how to get them working properly, before I just gave in and had all services declare interfaces/contracts.

Every so often, missing parts of the Node APIs can come and bite you. I got hit a few times because HTTP/2 isn't supported for things like gRPC to the Modal APIs. This makes some sense, since a worker can't just hang for a long time, but it does make you have to be careful about library usage, especially around native deps.

Migrations and versioning also get a bit trickier. Typically the way you change data shape within the DO is by adding some migration code when the DO wakes. This works pretty well, but it's easy to lose track of "what's the current state" of the schema, especially if you didn't wake every single DO. You can effectively never remove the old migration paths, unless you go through and wake all DOs.

Lastly, many of my potential customers want the ability to BYO-Cloud. This is pretty understandable if you're building a product which deals with sensitive data, and Cloudflare makes it a bit of a non-starter.

What else is there?

I mentioned before that no other cloud seems to have a similar offering. While that's true, I do think there are a few early but interesting options.

Restate provides a cheap durable execution runtime, similar to a faster / cheaper Temporal. It's built by the ex-Flink team so it leans heavily into a log structure for handling events and replaying. Restate has a concept of 'Virtual Objects', which provide many of the same semantics as a Durable Object: single writer, attached storage, etc. You can self-host Restate, and it has bindings in other languages like Rust and Golang (disclosure: I am a small-time angel investor, and am a fan of what they are doing). I've started using it as my durable-execution-runtime on AWS.

Rivet is a new YC company that provides infrastructure they refer to as 'actors'. Spiritually it feels very similar to a lot of what Cloudflare is building—they lean heavily into V8 isolates. I haven't seriously evaluated them, but from what I can tell on the outside, they seem to be doing a lot of the right things.

In terms of other primitives I think are promising, Vercel leads the pack. Workflows, Sandboxes, AI Gateway, Vercel Connect, and Functions all create usable primitives which you can string together to build these same sorts of long-lived agents. EVE feels like the culmination of all of these tools, composed in a straightforward manner.

Anthropic will purchase up to 2 gigawatts of AMD's Instinct MI450 chips starting in the first half of 2027, and AMD will invest up to $5 billion into Anthropic as certain deployment milestones are met.

OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened

This story is wild. The short version: OpenAI were running a cybersecurity test against an unreleased model, with the model’s guardrail features turned off. Rather than solve the test, the model broke its way out of OpenAI’s sandbox, then found exploits to break in to Hugging Face, all so it could cheat on the test by stealing the answers.

Along the way it helped make the strongest case yet for how the imbalance of model availability is hurting our ability to secure our software.

Here’s what happened

We currently have three documents to help us understand what happened here.

1. ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks? is a paper published on 11th May 2026 describing ExploitGym, a new eval suite for LLM-powered agent systems.
2. Security incident disclosure — July 2026 by Hugging Face on 16th July 2026 describes how they detected an attack from an “agentic security-research harness—used LLM still not known” that breached some of their systems.
3. OpenAI and Hugging Face partner to address security incident during model evaluation from OpenAI on 21st July 2026 confesses that it was their agent harness that did this, and that they’re working with Hugging Face to clean up the mess.

ExploitGym

I hadn’t seen the ExploitGym paper before and it’s a really interesting one. Authors from UC Berkeley, the Max Planck Institute, UC Santa Barbara, and Arizona State designed a new benchmark for evaluating models on their ability to turn a reported vulnerability into a concrete exploit. OpenAI, Anthropic, and Google provided feedback and helped run the benchmark against their models.

The benchmark “comprises 898 instances derived from real-world vulnerabilities that affected popular software projects”—including the Linux kernel and V8 JavaScript engine. The ExploitGym benchmark is available on GitHub.

Here’s the paragraph that best represents their benchmark results:

Among all configurations, Claude Mythos Preview and GPT-5.5 achieve the highest success counts (157 and 120 successes, respectively), demonstrating that current frontier agents can exploit a substantial subset of real-world vulnerabilities under controlled conditions. GPT-5.4 also solves a notable 54 tasks, placing it in an intermediate tier. The remaining model–agent pairings solve fewer than 15 tasks each, underscoring that end-to-end exploitation remains challenging and sharply differentiates today’s frontier systems. Notably, Claude Opus 4.7 achieves fewer successes than Claude Opus 4.6 despite being a newer checkpoint, and does so at substantially lower cost on the full set. Trace inspection reveals that Claude Opus 4.7 and Gemini 3.1 Pro frequently conclude early after judging the target vulnerability non-exploitable.

The paper also describes the approach they took to preventing the agents from cheating by going outside the parameters of the test. This becomes relevant in a moment!

Outbound connections are restricted to a curated allowlist that permits routine package installation (Ubuntu apt repositories and PyPI) and fetching the toolchains required for building V8. All other external endpoints are blocked.

The paper concludes with this (emphasis mine):

Our results show that autonomous exploit development by frontier AI agents is no longer a hypothetical capability. While current agents are not yet reliable across all targets, they already exploit a non-trivial fraction of real-world vulnerabilities, including complex targets such as kernel components. This rapid emergence is itself a central finding, showing that capabilities that would have seemed implausible are now present in deployed frontier models.

An important detail here: this paper isn’t about discovering vulnerabilities; it’s about being able to take those vulnerabilities and turn them into working exploits.

When Anthropic first restricted access to Mythos back in April they talked about this capability as well. A model that can act on vulnerabilities is a lot more dangerous than one that can just discover them.

One of the ways Fable differs from Mythos is that it’s more likely to refuse to weaponize vulnerabilities in this way. I get the impression the US government did not understand that distinction when they banned Fable last month.

The Hugging Face incident

The first hint we got of the attack was in this blog post by Hugging Face on 16th July 2026:

A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker. From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.

I hope they release more details about the code that pulled this off. I’m assuming this means packages using the datasets library, a Hugging Face project for bundling up and sharing datasets on their platform. That library used to execute arbitrary code but has been steadily locked down over time, with the 4.0.0 release in July 2025 removing the trust_remote_code=True flag entirely.

Assuming the attack used that library it must have either abused pickle serialization in some way, found some other non-obvious code execution path, or (most likely) specified datasets<4.0.0 as the dependency.

The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness—used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services.

This was a sophisticated attack!

Then Hugging Face hit a wall: they tried to use “frontier models behind commercial APIs”—I’m guessing from Anthropic and OpenAI—to help analyze the attack, and were blocked:

When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers’ safety guardrails, which cannot distinguish an incident responder from an attacker.

They switched to their own self-hosted instance of MIT licensed GLM-5.2 and it helped them figure out what was going on.

This indicated a fundamental asymmetry between the defending team and the (so-far unknown) attacker:

We do not know which model powered the attacker’s agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.

As a useful indicator of how seriously they took the attack:

[...] Finally, we have also reported this incident to law enforcement agencies.

So who was responsible for this “autonomous agent framework”? It turned out to be OpenAI themselves.

The OpenAI confession

Five days later, on July 21st, OpenAI revealed the culprit. They had been running the ExploitGym benchmark against a new, as-yet undisclosed model, and that model had been operating way outside its intended parameters (emphasis mine):

After investigating, we now know that this particular incident was driven by a combination of OpenAI models — including GPT‑5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes — while being internally tested on a benchmark⁠ [ExploitGym] of cyber capabilities. [...]

We estimate maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity. Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries.

The models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.

It’s pretty clear what happened here. OpenAI removed safety filters for an in-progress model, locked it up in a sandbox and told it to solve the ExploitGym problems. Given the absence of guardrails there was nothing to prevent the model from attempting to break out of that sandbox, break into Hugging Face, and read the answers from there instead.

OpenAI’s sandbox used the now common pattern of allowing access to an allow-list of sites related to installing additional packages via a controlled proxy. In OpenAI’s words:

While operating in our sandboxed testing environment, our models spent a substantial amount of inference compute finding a way to obtain open Internet access, in pursuit of solving the evaluation problem. To gain access, the models identified and exploited a zero-day vulnerability (which we’ve now responsibly disclosed to the vendor) in the package registry cache proxy. With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access.

So step one was to break out onto the public internet. The model then broke into Hugging Face to find the answers:

After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym. Knowing this, the model searched for and successfully found ways to gain access to secret information that it could use to cheat the evaluation. In one example, the model chained together multiple attack vectors, including using stolen credentials and zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers.

Chaining together multiple attack vectors is exactly the kind of thing these new models can do, where previous generations of models might have failed.

I wrote last month about how Claude Fable is relentlessly proactive, when I noticed it spinning up custom web servers and deploying CORS tricks on my own laptop just to help debug a WebKit CSS issue. It turns out relentless proactivity is the defining trait of this new generation of Mythos-class models. If you set them a goal and give them a way to get there, even inadvertently, they will figure it out.

Resist the temptation to write this off as a stunt

There will inevitably be some people who dismiss this story as a dishonest marketing trick by OpenAI to make their models sound terrifyingly effective. I found 81 instances of the term “marketing” in the Hacker News discussion of the incident.

To those people I say pull your heads out of the sand—you’re now including Hugging Face in your conspiracy theories, just so you can deny the crescendo of evidence here!

The best models we have today have the ability to both find and exploit new vulnerabilities. The ExploitGym paper itself concludes that “autonomous exploit development by frontier AI agents is no longer a hypothetical capability”, and this incident is a perfect example of exactly that.

The asymmetry is increasingly frustrating

One of the most infuriating details of this story is how Hugging Face, faced with an accidental and aggressive attack from one of OpenAI’s models, were unable to then turn to OpenAI’s models to help them fend off the attack.

The frontier models we have access to are increasingly being constrained in how much they can help us protect our software, heavily influenced by the US government’s ongoing threat of export controls. Claude Fable 5 wouldn’t even proofread this article for me! It insisted on downgrading me to a less capable model.

Meanwhile open weight models from China such as GLM-5.2, Kimi 3 and the new Qwen 3.8 Max appear to have none of these restrictions—and any restrictions that do exist can likely be fine-tuned out of them by modifying the weights

These constraints are meant to make us safer. I think there’s a risk that they are having the opposite effect.

OpenAI announced Wednesday that it will spend $750 billion on infrastructure through 2030, some 25% more than it estimated earlier this year, The Wall Street Journal reported. The renewed blitz comes as its Stargate data center project appears to have stalled.

The first salvo in OpenAI’s spending spree will be a $20 billion data center campus in Georgia known as Project Camellia. The development will span 1,400 acres northwest of Savannah and will draw at least 3.2 gigawatts of power from Georgia Power, the region’s utility. The generating capacity is expected to become available between 2028 and 2032.

The AI company said it would “pay the full cost of the infrastructure and electric-service costs” for the new data center. The Georgia Public Service Commission (PSC) adopted a rule last year to prevent utilities from passing on costs associated with new users drawing more than 100 megawatts.

Georgia Power also said OpenAI will reduce its power draw by up to 1 gigawatt during periods of high demand on the grid.

OpenAI is receiving a 50% property tax abatement for 15 years from Effingham County, according to the Effingham Herald.

Neither OpenAI nor Georgia Power has said how Project Camellia will be powered. TechCrunch asked both companies for specifics but did not immediately receive a reply.

Regulatory filings might provide some clues. In December, Georgia Power received approval from the PSC to produce an additional 9,885 megawatts. The utility told the PSC it expects to have all the capacity contracted by the end of 2026. The OpenAI deal accounts for about a third of that.

Based on documents Georgia Power filed with the PSC, most of the new capacity will come from natural gas. The utility said it will build or buy from third parties about 5.8 gigawatts of natural gas generating capacity, about a quarter of which will be from more polluting simple-cycle turbines. Altogether, the new fossil fuel capacity will more than double Georgia Power’s natural gas fleet. The remainder will be supplied by grid-scale batteries and solar.

While electricity from Georgia Power is expected to start flowing in 2028, OpenAI did not give a timeline for when the first GPU will be turned on. That could happen sooner than 2028 given that OpenAI recently hired Brett Mayo to lead data center construction. Mayo previously worked at xAI, where he oversaw the Colossus data center in Memphis.

Colossus was built in record time, but it has allegedly taken its toll on local air quality, according to a lawsuit filed by the NAACP and the Southern Environmental Law Center. The xAI data center has been running dozens of unpermitted natural gas turbines, claiming exemption from federal clean air regulations.

U.S. Treasury secretary Scott Bessent doubled down on his warnings to Chinese AI companies on Wednesday, saying that sanctions remain on the table after a White House official accused Moonshot of improperly distilling Anthropic’s Fable model.

Model distillation is a common AI training technique in which a smaller model learns from the outputs of a larger one. While this process can infringe on intellectual property rights, it’s also widely used as a legitimate optimization method.

“Open source is not open season on American IP,” Bessent posted on X. “When [Chinese] firms conduct covert, industrial-scale distillation attacks that cross the line into IP theft, sanctions and Entity List designations will be on the table.”

Earlier this week, Bessent stated that the U.S. government would examine open source models from China for signs of intellectual property theft and impose sanctions if found.

Bessent’s latest remarks come hours after the White House’s science and technology policy chief Michael Kratsios accused the China-based Moonshot of conducting large-scale distillation against U.S. models. He alleged that Moonshot had acquired Nvidia’s “GB300-equipped servers and has accessed GB300s in Thailand, likely to train its AI models,” raising questions about whether the firm violated U.S. export-control rules.

The GB300 servers are part of Nvidia’s Blackwell generation, which are banned from being sold to Chinese companies.

Some experts dispute the idea that Kimi K3 could have been developed primarily through distillation from Fable, which has only been publicly available since July 1. Moonshot released K3 last week as an open-weight model, and its advanced capabilities have called into question the underlying business models of leading U.S. AI labs, casting doubt on whether they can continue to justify the enormous capital requirements underpinning the frontier AI race.

The episode has also intensified a broader debate in Washington over the influx of Chinese open models. Some, including former White House AI adviser and current OpenAI Head of Strategic Futures, Dean Ball, have argued that the U.S. should restrict or effectively ban the use of Chinese open-weight models to preserve America’s technological advantage and mitigate potential national security risks.

TechCrunch has reached out to Moonshot and the Treasury for comment.

The startup's Postgres survival guide

A guide to preventing Postgres from toppling over.

Over the past half year or so, I’ve been writing an internal doc for our engineers trying to distill two years of Postgres battles into a somewhat cohesive document. While I love the Postgres manual, I find it’s hard to turn to when shit hits the fan because it’s just so darn comprehensive. I thought this might be useful for others and would appreciate feedback (or other tidbits that you’ve learned running Postgres in production).

Before starting Hatchet, while I was familiar with SQL, the extent of my knowledge was basically: if a query is slow, you need an index. That’s the starting point for this doc; I’m going to assume you’re familiar with SQL basics, rows, tables, and know roughly what an index is.

And if Claude is writing all of your queries, this might be a waste of time! I recommend supabase/agent-skills

A quick note on ORMs

This guide should still be useful, but you might need to translate some of these tips into your ORM of choice. Lots of optimizations as you scale just aren’t possible with ORMs unless you can break past the abstraction layer and write SQL. You can do this gracefully or non-gracefully; Prisma TypedSQL or equivalents look interesting for this. We use sqlc at Hatchet which gets us very similar behavior; highly recommend if you’re a Go stack.

The simple stuff: good reads, writes and schemas

Let’s start with the basics: queries and schemas at low volume.

Writing a good schema

After you’re deployed, schemas are by far the hardest to change moving forward, so it’s worth spending some time on them. I’d recommend building your schema iteratively: start with a rough approximation for your tables and primary keys, then write some queries on those tables based on your application needs. You can approximate this with some questions: Is this a high-read and/or high-write table? What are the most common filters on reads? Which columns am I updating the most?

If you want to be more formal about it, you can look into database normalization into 1NF/2NF/3NF, but I’ve found normal forms to sometimes be at odds with query efficiency and ease of use, which is critical when you’re moving fast—sometimes it’s just easier to dump data into a jsonb column.

My rules of thumb for schemas are:

• Use identity columns (auto-incrementing integers, slightly more performant than bigserial) or built-in UUIDs for primary keys
• Always use timestamptz
• Always use primary keys
• Use foreign keys with cascading deletes for low-volume tables, particularly where database consistency and correctness are important. Careful at higher volume.

Writing good read queries

Let’s start with SELECT queries. A useful—albeit slightly inaccurate—mental model for fast selects is: under the hood, Postgres is either going to find a single row in a table very quickly, or it’s going to read every single row in your table using something called a sequential scan 😞.

It’s going to find a single row very quickly when you filter by:

• An explicit index
• A unique constraint (just a special case of index)
• A primary key (these are automatically indexed in Postgres)

Indexes by default use a btree implementation. It’s most helpful to think of indexes as just another table in Postgres, with data stored in a specific format which is optimized for lookups (more on this later). These trees are great because finding a single row happens in approximately log(n) time, where n is the number of rows in the table—in other words, really fast.

When Postgres can’t use an index, it’ll use something called a sequential scan, or seq scan. Seq scans are much slower than index lookups, but modern databases are so fast at loading rows into memory that you probably won’t even notice at first: seq scans on tables with less than 20k rows are pretty much instant.

Writing performant joins

For inner joins, there’s rarely an argument for not using primary keys as the inner join; it usually speaks to a schema design or normalization problem. Treat ON clauses with the same respect as a WHERE clause—the same principles apply. Use an index.

Compound indexes and aligning ORDER BY to your indexes

Often the first slow query in your application will be a list query across a large table. In this case, you can use a compound index. In more complex cases, a good rule of thumb is: the ORDER BY columns should be the last columns in the index, and you should align columns to the ordering in the ORDER BY. Note that Postgres can scan btrees in both directions, so sometimes the DESC is irrelevant—but for compound indexes it’s good practice.

Writing good write queries

The premise of successful writes is:

1. Keep transactions short. Don’t go querying an external service in the middle of a transaction unless you have a really good reason to.
2. Be careful of the rows you’re locking for writing; in other words, only lock what you need. Every time you update a row, you’re taking out a lock on that row for a short period of time until the transaction commits.

As your system gets busier, you’re going to start noticing the impact of locks more. In particular, you might try to create an index at some point in the future with a simple CREATE INDEX command: turns out this locks your table and prevents inserts and updates! When creating an index on an existing large table, always use CREATE INDEX CONCURRENTLY.

Migrations

Getting really good at writing migrations is an important technical advantage: it helps you iterate much faster and increases your uptime. As a starting point, try to keep migrations additive (in other words, don’t delete or remove columns) and run them in a transaction wherever possible; this will make rollbacks and partial migrations much easier to deal with.

The simplest mental model for good migrations is: does this block all of my writes, or does it not? Creating an index without CONCURRENTLY blocks all your writes, so you might see downtime. Generally, operations which call ALTER TABLE should be worth a second look; for example, adding a new check constraint to a very large table can block your writes as well (unless you add it with the NOT VALID keyword).

Connection management

Every time you execute a transaction or query against your database, you’re utilizing a connection. Connections are expensive in a number of dimensions (cpu and memory), and high connection churn can lead to a lot of unnecessary resource waste, so connections should be long-lived. Connection storms (when you start using up a ton of new connections at the same time) can also lead to very hard to debug edge cases related to internal Postgres locks.

Because of all these connection footguns, external connection poolers like pgbouncer are great! If you can’t add this for whatever reason, in-memory connection poolers are a great second option.

Intermediate: the query planner, bulk updates, and autovacuum

Introducing the leakiest of abstractions, the query planner

At a certain point, your queries might become complex enough that a simple index won’t cut it. At this point, you will need to concern yourself with the query planner. The query planner looks at the query you pass in, and it figures out how it should translate your query into a set of internal operations in the database.

This limited information is the table statistics. These statistics are collected for every ANALYZE. This also happens when autovacuum is run, so more frequent autovacuums also mean that your query statistics will be more up to date. A common reason why your query is behaving improperly is not analyzing frequently enough.

This is where EXPLAIN ANALYZE is your friend. This outputs the query plan for the query and executes the query (careful running this in production—you can use EXPLAIN without ANALYZE to get a query plan), and then compares its estimates based on the table statistics to the actual number of rows scanned.

Sometimes it just makes sense to seq scan

There are cases where you think an index should be used, but the query planner is still seq scanning anyway, despite table statistics being up to date and the index being valid. In these cases, Postgres is usually estimating that the cost of the seq scan will be smaller than the cost of the index scan. Index scans do come with some overhead; indexes are stored separately from the actual data in the table (called the heap)—finding all of the rows in the heap can be expensive!

Writing lots of data

To reduce overhead when writing a lot of data, we can pack a batch of rows into each query. The simplest way to do this is to send all queries to the Postgres server at once in an implicit transaction. Batching is very powerful: we found that it can ~10× your throughput.

Default autovacuum settings can kill your database

Autovacuum is a critical operation in Postgres databases that sometimes needs to be tuned, especially in high-write scenarios. The autovacuum daemon is responsible for a number of things, including cleaning up dead tuples and managing transaction ids.

What’s a dead tuple? A tuple is an instance of a row on the filesystem. Every time you update or delete a row, a version of that row is left in Postgres until all transactions which started before that row was updated or deleted have committed or rolled back. These rows which can no longer be read by any transactions are dead tuples.

If you’re writing data quickly enough, sometimes autovacuum can’t keep up, which will get you into a very unhealthy state. If you use up all transaction ids in the system before they can be reclaimed by autovacuum, you’ll reach a dreaded state called transaction id wraparound. This will mean a big chunk of downtime.

Other types of bloat

Besides dead tuples, there are two other kinds of bloat you’ll often encounter in a busy Postgres system:

1. Table bloat caused by partially filled pages. When dead tuples are reclaimed, this can lead to pages not being entirely filled, which can increase the disk usage of Postgres.
2. Index bloat is a special case of table bloat, and is similarly solved by good autovacuum settings. But Postgres has a built-in command for dealing with this, which is REINDEX INDEX CONCURRENTLY.

Some advanced stuff

FOR UPDATE SKIP LOCKED

The best way to think about this Postgres feature is that it reserves the rows that you’re selecting for use in your transaction without interfering with other queries. It’s also very useful in cases where you’re doing many independent updates of rows, or you’re managing leases on objects in your system across many instances of your application.

Partitioning

Postgres has built-in partitioning which allows you to subdivide your tables based on row values, like timestamps or hashes. This can be incredibly useful for time-series data because:

1. Each partition can be autovacuumed independently, allowing you to scale up autovacs on your table
2. Deleting old data is near-instant—you simply drop the table partition, rather than iterating through rows

Tricks for large table migrations

If you try to migrate really large tables, it can take many hours to copy data in a single transaction. This isn’t good—long-running transactions prevent autovacuum from doing its job properly. One of the tricks we’ve learned is to use Postgres triggers and run a large batched backfill outside of a transaction, using unique constraints on the primary key to prevent duplicate writes.

Aurora DSQL provides PostgreSQL-compatible, strongly consistent, active-active multi-region OLTP without managing servers, shards, replicas, or failover, with cross-region latency mostly paid at commit. Teams still need short transactions and must work around current limits such as 3,000 rows or 10 MiB per transaction and no enforced foreign keys.

In this article, you will learn how agentic AI architecture has evolved by mid-2026, including the shift away from orchestrated reasoning loops, the rise of multi-agent swarms, and the standardization of tool protocols through MCP.

Topics we will cover include:

• Why native reasoning models have made complex external orchestration frameworks increasingly redundant.
• How to design a multi-agent swarm using stateless specialist agents connected through handoff tools.
• How the Model Context Protocol, persistent memory graphs, and emerging security patterns define the current production landscape.

Let’s not waste any more time.

Introduction

Look back at how we built AI agents just a year ago, and the dominant paradigm was brute-force orchestration. Engineers spent their time hand-crafting complex ReAct (Reasoning and Acting) loops, fighting with brittle prompt chains, and trying to force single, massive language models to juggle planning, tool execution, and context management all at once.

Today, in mid-2026, the ecosystem has fractured and specialized. The era of the monolithic, do-everything agent is fading.

We’re now working with native reasoning models, standardized tool protocols, and multi-agent architectures, often called “swarms.” As foundation models have integrated “System 2” thinking directly into their architectures, the role of the AI engineer has shifted from prompting agents to designing the infrastructure in which specialized agents communicate.

This tutorial breaks down the current state of agentic AI architecture, covers the three major shifts defining production systems today, and walks through how to design a modern agent swarm.

1. Transitioning Away from Orchestrated Loops

Let’s start at the layer that has changed most dramatically: how agents actually think.

Previously, we explored patterns like Plan-and-Execute and Reflexion. These were external loops, where we used code to force a model to think step-by-step, critique its own output, and try again.

Today, foundation models handle test-time compute natively. Models now generate hidden reasoning tokens, explore multiple solution branches, and self-correct before outputting a single word to the user. The scaffolding we built to simulate reflection is becoming redundant.

What this means for your architecture: you no longer need to build complex orchestration frameworks just to get an agent to plan. If you’re still using LangChain or LlamaIndex to force a model to reflect on its own errors, you may be adding latency and token overhead for something the model now handles more naturally.

The orchestration layer should instead focus on routing, state management, and environment execution. The agent’s cognitive loop is handled by the model; your job is to build the sandbox it operates in.

With that cognitive overhead lifted, we can put engineering energy somewhere more valuable: decomposing work across multiple specialized agents.

2. Building Agent Swarms (Multi-Agent Microservices)

Now that models handle their own reasoning, the question becomes: what should a single agent actually be responsible for? The answer production teams have landed on is: as little as possible.

Attaching 50 tools to a single large model creates a bottleneck. A growing number of production teams have moved toward agentic swarms — a collection of smaller, highly specialized agents that communicate via a standardized protocol.

Instead of one agent with 50 tools, you have:

• A Triage Agent that understands the user’s intent and routes requests.
• A SQL Agent that only knows your database schema and has one tool: execute_query.
• A Python Agent running in an isolated container that handles data transformations.

You might wonder whether splitting a monolithic agent into many smaller ones just moves the complexity around rather than reducing it. Here’s the key insight: the complexity doesn’t disappear, but it becomes manageable, testable, and replaceable in a way it never was before.

Building a Basic Swarm Pattern

Notice the architecture: individual agents are stateless per call, and orchestration relies on handoff tools. When the SQL agent finishes fetching data, it calls a tool to transfer control and the data context to the Analyst agent. This keeps context windows lean and lets you use cheaper, faster models (like Qwen3 or current-generation small language models) for individual nodes, reserving larger models for routing and synthesis.

This pattern — stateless-per-agent but stateful-across-the-system — becomes even more important once you factor in how tools are connected. That’s where standardization has made a real difference.

3. The Standardization of Agency: Model Context Protocol

Building a swarm is one thing; connecting it to the real-world systems your users care about is another. Until recently, that integration work was one of the most tedious parts of the job.

Integrating an API previously required writing custom schemas, handling HTTP requests, and dealing with arbitrary JSON parsing errors from the model. Each new integration meant reinventing the same wheel.

The current state of tool calling is increasingly defined by the Model Context Protocol (MCP). This open standard acts as a universal adapter between AI models and local or remote data sources.

This standardization means you can plug a pre-built GitHub MCP server, a Slack MCP server, and a PostgreSQL MCP server into your swarm without writing the underlying API wrappers. Practical implementation still requires careful credential management on the server side, but the integration surface is much smaller.

4. Continuous Learning via Memory Graphs

One of the most significant promises was agents that learn from their own execution history. That’s moving into production via memory graphs, and the mechanism is worth understanding clearly.

The distinction to draw is between per-call statelessness and system-level memory. Individual agents remain stateless per invocation, keeping context windows lean. The system, however, carries persistent memory through a graph database like Neo4j or managed alternatives injected directly into the agent’s context pipeline.

When a swarm executes a task, a specialized Memory Agent runs asynchronously in the background. Its only job is to evaluate the main swarm’s trajectory, extract persistent facts, and update the graph.

Here’s how it works in practice:

1. User asks: “Deploy this code to staging.”
2. Swarm fails: The deployment agent tries an outdated AWS CLI command. It searches internal docs, finds the new command, and succeeds.
3. Memory Agent runs: It observes the failure, extracts the working command, and writes a node to the knowledge graph: [Staging Environment] -> [Requires] -> [Command X].
4. Next execution: The Triage agent queries the graph, pulls the updated fact into its system prompt, and bypasses the failure entirely.

This moves us from prompt engineering to context engineering. The system improves over time without requiring fine-tuning of the underlying models.

5. Security: The Swarm Attack Surface

With multi-agent systems connected via universal protocols, the attack surface has expanded. Indirect prompt injections hijacking automated workflows is now among the primary concerns for enterprise adoption, and the swarm architecture makes it structurally more dangerous than it was in the monolithic model era.

Here’s why: when Agent A (which reads external emails) can transfer context and control to Agent B (which has database access), a malicious instruction embedded in an email can pivot through your swarm laterally, mirroring traditional network intrusion patterns. The same handoff mechanism that makes swarms useful makes them susceptible.

Three emerging defenses are converging on this problem:

• Cryptographic Tool Provenance: Tools are signed, and agents only execute tool calls if the request originated from a verified internal state, not external data.
• Semantic Firewalls: A lightweight, fast model sits between agents in the swarm, analyzing handoff payloads for malicious instructions before allowing the transfer.
• Ephemeral Sandboxes: Agents execute code in single-use WebAssembly (Wasm) containers or microVMs that are destroyed after each task completes.

The Path Forward

Agentic AI has moved from research curiosity to an engineering discipline with real constraints, real failure modes, and real design decisions at every layer.

The foundational primitives — tool calling, routing, and native reasoning — are maturing fast. The remaining leverage is in the systems layer: how you design the swarm topology, how you architect memory so the system compounds knowledge over time, and how you draw the security boundaries that let these systems operate safely at scale.

The teams building well today aren’t chasing smarter individual agents; they’re building more resilient, specialized swarms. If you’re starting from scratch, pick one of the patterns here, implement it at small scale, and instrument it carefully. The architectural intuitions you develop from a three-agent swarm transfer directly to a thirty-agent one.

The Database Is a Liability You Can’t Revert

A bad code commit is a revert. A bad schema decision is a five-year problem. Database mistakes are asymmetric, and prevention is the only viable strategy.

TL;DR

• Code is ephemeral; schema is permanent. You can git revert a bad microservice deploy. You cannot git revert a BIGINT primary key on a 5TB table that has propagated to 300 foreign keys.
• Database decisions exist on a ladder of irreversibility. Changing work_mem is cheap. Changing a column type is a table-rewriting nightmare. Changing a partition key is a company-level migration project.
• Prevention is not a nice-to-have; it is the only sane strategy. The cost of a bad schema decision made in a two-line pull request can exceed the cost of the entire engineering team for a year.

At Oracle, working on the query engine, we had a mantra: the database must protect the user from themselves. We spent more time building guardrails—things like Zonemaps to automatically prune blocks, or robust resource management—than we did chasing raw benchmark numbers. Why? Because we knew a simple truth that the application world often forgets: you can’t undo gravity, and you can’t undo a bad schema decision at scale.

Code is cheap. A buggy Python service gets rolled back. A runaway LLM API call burns a few thousand dollars, you set a cap, and you move on. The feedback loop is measured in minutes.

Your database is different. The feedback loop for a bad schema choice isn't minutes; it's years. The cost isn't a few thousand dollars; it's a permanent tax on every query, a drag on every engineer, and a multi-quarter migration project that threatens the stability of the entire business.

This asymmetry is the most dangerous part of modern data engineering. A junior developer, tasked with adding a feature, can introduce a schema change that creates a decade of technical debt—all with a single approved pull request.

The Ladder of Irreversibility

Not all database changes are created equal. Think of them on a ladder. The higher you climb, the more permanent and painful your choices become.

Rung 1: The Cheap & Reversible (The Green Zone)

These are the tuning knobs and ephemeral objects. They are low-risk and easy to change.

• Session Parameters: Setting work_mem for a large sort or hash join. If you set it too high, you might get an OOM kill on a single backend. You adjust and rerun. The blast radius is tiny.
• Indexes: CREATE INDEX CONCURRENTLY in Postgres is a lifesaver. You can add an index without catastrophic locking. If you choose the wrong columns, you DROP INDEX CONCURRENTLY and try again. It costs CPU and I/O, but it doesn't corrupt your logic or require downtime.
• Views: A view is just a stored query. CREATE OR REPLACE VIEW is effectively free. It’s pure logic, completely decoupled from the physical storage of your data.

Rung 2: The Painful & Disruptive (The Yellow Zone)

Here, you're starting to touch the physical layout of the table. Mistakes are recoverable, but at the cost of high-drama migrations and potential downtime.

• Changing a Column Type: ALTER TABLE users ALTER COLUMN id TYPE BIGINT;. Seems innocent. On a 100-row table, it is. On a one-billion-row users table, Postgres will rewrite the entire table and its indexes. This means acquiring an ACCESS EXCLUSIVE lock (blocking all reads and writes), generating titanic amounts of WAL, and putting extreme pressure on your I/O subsystem and autovacuum. This isn't a migration; it's a planned outage that you'll have to rehearse for weeks.
• Adding NOT NULL: You forgot to add NOT NULL to a column. A year later, a NULL finally slips in and causes a sev-1 when it hits a join condition. The fix? ALTER TABLE ... SET NOT NULL. To do this, Postgres must scan the entire table to validate the constraint. If it finds a single NULL, the command fails. Now you're on a data-cleaning fire drill just to apply a constraint you should have had on day one.

Rung 3: The Near-Permanent (The Red Zone)

Welcome to the top of the ladder. If you get this wrong, you don't 'fix' it. You live with it, or you begin a year-long project to rebuild your entire data platform.

• Primary Key Choice: You chose UUIDs for your primary keys. Now every single one of your indexes suffers from terrible locality and a 4x bloat compared to a BIGINT. The B-tree is constantly being rebalanced, the buffer cache hit rate is abysmal because the keys are random, and every foreign key in your entire system is now a bloated 16 bytes. Reversing this means changing hundreds of tables, rewriting all application code, and performing the mother of all data migrations.
• Partitioning / Sharding Key: This is the mistake I see most often. You have a 5TB events table and you partition it by RANGE(created_at). It works beautifully for time-series queries. Then the product changes, and 90% of your query load becomes SELECT * FROM events WHERE user_id = ?. The planner looks at this query and has no choice but to scan every single partition, because user_id has no correlation with created_at.

  -- Querying a table partitioned by the wrong key
  -- EXPLAIN SELECT * FROM events WHERE user_id = 42 AND created_at > '2023-10-01';
  
  -- PLAN (Simplified)
  Append  (cost=0.00..84502.41 rows=12 width=128)
    ->  Seq Scan on events_p2023_10 WHERE user_id = 42 ...
    ->  Seq Scan on events_p2023_11 WHERE user_id = 42 ...
    ->  Seq Scan on events_p2023_12 WHERE user_id = 42 ...
    -- ... and so on for every relevant partition.
  

  A query that should have taken 20ms by hitting a single partition now takes seconds and causes a massive I/O storm. The fix? Create a new table partitioned by (user_id). Set up a dual-write pattern in your application. Backfill 5TB of data. Validate everything. Then, in a terrifying maintenance window, switch the application to read from the new table. You just paid double the storage and spent a full engineering quarter to fix a single line of DDL.

• Collation: You initialized your cluster with the wrong LC_COLLATE. Now your string sorting order is subtly wrong ('a' vs 'A' vs 'á'), or worse, your indexes on TEXT columns can't be used for LIKE queries. The only fix is a full pg_dump and pg_restore into a brand new cluster. For a multi-terabyte system, that's not a migration; it's a company-threatening event.

What DeepSQL does about this

You cannot expect every engineer to have the institutional knowledge of a 20-year Oracle kernel veteran. That's an impossible ask. The only solution is to codify that expertise and place it as a guardrail in front of your database. When a migration script containing PARTITION BY RANGE (created_at) is proposed, DeepSQL doesn't just check for syntax. It analyzes your actual query workload via pg_stat_statements and sees that 95% of your predicates are on user_id. It then flags this DDL as a high-risk, irreversible decision and recommends a more appropriate partitioning strategy. It prevents the problem before the pull request is merged, turning a potential five-year liability into a five-minute code revision.

Science Corporation, a startup developing novel brain-computer interfaces (BCI), won approval from Europe’s medical device regulator to begin selling a device that restores vision lost from age-related macular degeneration.

The company said the device, called PRIMA, also received a designation from the US Food and Drug Administration that is the first step toward an expedited regulatory review, which could see the device used to treat two rare kinds of blindness.

Millions of people around the world suffer from age-related macular degeneration, which destroys the light-sensitive cells at the back of the eyes, making it difficult to read and recognize faces.

To use the device, patients suffering from this loss of vision undergo an hour-long outpatient procedure that plants a small chip in back of their eye. Then they wear camera-equipped glasses that transmit a view of the world to the chip. Max Hodak, Science Corp.’s founder and CEO, says the product gives functional vision to people who have lost it.

“One of our patients in France finished a 300-page novel a little while ago, and sent us the book,” Hodak told TechCrunch. “We have a sketch on the wall [that] one of our patients drew of the Sydney Opera House. There are videos of patients playing crossword puzzles and filling in Sudoku.”

Hodak is known as the co-founder and former president of Neuralink, Elon Musk’s BCI startup. He left in 2021 to start Science Corp., with plans to develop a novel BCI based on a hybrid of silicon chips and living cells. But first, the company had to prove out its processes and develop a sustainable business.

“The thing that the space needs is a company making $100 million a year of revenue,” Hodak said. “There’s this risk that the whole thing enters a winter, and so we think it’s important to build a sustainable business as we develop these longer-term technologies.”

Hodak and his colleagues believe that sustainable business will be restoring vision to the blind, specifically patients whose conditions stem from problems with the light-detecting cells at the back of the eye. After exploring multiple approaches, they determined that Pixium, a French company that developed the PRIMA technology, had the right path forward and acquired the firm in 2024. Science Corp. used its internal platform to build out the documentation and evolve the product to prepare it for regulatory approval and commercialization.

Each PRIMA device is expected to cost in the hundreds of thousands of dollars; Science Corp. and its medical partners in Europe are currently in discussion with healthcare providers over reimbursement. The company is laying the groundwork to begin offering PRIMA in Germany, where its clinical trials were held, and could see the first procedure in September.

Science Corp. expects to continue improving the vision capabilities of PRIMA with a new chip, and the form factor of its glasses, which currently require a battery-pack to operate. The goal is to offer something like Meta’s AR glasses, but the power and compute requirements for PRIMA are more significant.

Science Corp. is also working with Dr. Murat Günel, chair of Yale Medical School’s Department of Neurosurgery, to develop procedures for human trials of a directly implanted bio-hybrid brain sensor.

Hodak — who is speaking at TechCrunch Disrupt this October — says bringing PRIMA to market is “the most important thing for the company, because we don’t get to do the bio hybrid stuff long term if you don’t have a great vision business. That’s what’s really financing the rest of it,” he added. “That’s the thing that investors know how to build spreadsheets around.”

The State of WebMCP: July 2026

WebMCP in July 2026 is a standard with everything except users. The spec has Google and Microsoft engineers as editors, a live origin trial in Chrome, a Lighthouse audit category waiting for it, and a draft the editors updated two days ago. It also has close to zero deployment on real websites, and not one mainstream AI agent that calls the tools.

The short version

1. WebMCP lets a web page register typed JavaScript functions that browser AI agents can call, instead of forcing agents to scrape the DOM or click around with computer vision.
2. The spec is a W3C Community Group draft co-edited by Google and Microsoft. It isn’t on the standards track yet.
3. Chrome is running a public origin trial from Chrome 149 through 156. Edge ships support behind a flag. Firefox and Safari are watching.
4. Site adoption is close to zero, and no mainstream agent consumes the tools yet. Google says Gemini in Chrome will be the first.
5. The API moved from navigator.modelContext to document.modelContext in the 21 July spec draft, and Chrome 150 deprecates the old location. Early adopters already carry migration debt.
6. Lighthouse gained agentic-browsing audits in May. They sit at “Not Applicable” on most sites today, which is why the next twelve months are the window.

What WebMCP is

An AI agent that wants to book a table on your site today has two options. It can parse your DOM and guess which button does what, or it can take screenshots and click coordinates. Both are slow, brittle and expensive, and both break the day you ship a redesign.

WebMCP gives the page a third option: tell the agent what it can do. A site registers tools in JavaScript, each with a name, a natural-language description and a JSON schema for inputs. The browser exposes those tools to whatever agent is driving, the agent calls them like functions, and your existing frontend code does the work.

const modelContext = document.modelContext ?? navigator.modelContext;

await modelContext.registerTool({
  name: "search-products",
  description: "Search the product catalogue and return matching items",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "Search phrase" },
      maxResults: { type: "number" }
    },
    required: ["query"]
  },
  execute: async ({ query, maxResults = 10 }) => {
    const results = await searchCatalogue(query, maxResults);
    return { content: [{ type: "text", text: JSON.stringify(results) }] };
  }
});

You’ll need that feature-detection line at the top. The spec moved the API from navigator to document to reflect that tools belong to a specific page, and Chrome deprecated navigator.modelContext in Chrome 150 while the origin trial still ships it. Framework maintainers are mid-migration; Angular has an open issue tracking the move. If you’re implementing this month, you’re writing the fallback.

Three design decisions matter more than the syntax:

• The browser is the middleman. The page never speaks MCP directly. As Microsoft’s Patrick Brosset clarified, WebMCP borrows only MCP’s tool primitives; the browser handles protocol and transport.
• Tools run in the page, as the user. An agent calling your tools inherits the logged-in session, which is what makes them useful and what makes them dangerous.
• A declarative variant is coming for forms. The explainer describes HTML attributes that annotate existing forms so agents can fill them without custom JavaScript. The spec section for it is still marked TODO, but Lighthouse already audits the attributes, which tells you where Google expects this to land.

How we got here

WebMCP has two parents. The scrappy one is MCP-B, Alex Nahas’s 2025 open-source project that put MCP servers inside the browser tab and proved sites could expose tools to extensions. The institutional one arrived on 28 August 2025, when Patrick Brosset proposed WebMCP from the Microsoft Edge team, and Google joined as co-author shortly after.

Supply and demand, out of sync

A protocol needs two sides. Sites must register tools, and agents must call them. In July 2026 the supply side is warming up while the demand side hasn’t arrived.

Browsers are ahead. Chrome’s origin trial means any site can register a token and expose tools on production traffic today. Edge’s support sits behind a flag, and Microsoft co-authoring the spec makes deeper Edge integration a matter of when. Firefox and Safari sit in the discussion threads without commitments, which matters less than it sounds while the consuming agents are all Chromium-adjacent anyway.

Agents are behind. As of the most recent independent audit in May, no mainstream agent client calls modelContext tools. Claude, ChatGPT Agent, Perplexity and Gemini all still read pages the old way. Google says Gemini in Chrome will consume WebMCP tools, and when it ships it’ll be the first mainstream consumer and the reference implementation for everyone else.

Compare the server-side protocol it borrows from. MCP proper is thriving: roughly 97 million monthly SDK downloads, thousands of servers, and a specification release candidate due 28 July. Buyers already pay for agent-to-tool infrastructure at scale; the browser leg is the part still waiting for proof.

Adoption, measured honestly

No vendor or analyst publishes a measured adoption number, so writers reach for “approximately zero” and they’re right. What exists today:

• Named pilots. At I/O, Google listed Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart and Target as origin-trial participants.
• A checker cottage industry. webmcp-checker.com launched within days of the Chrome 146 preview, a 19-point validator extension followed in March, and at least three more single-page checkers ship the same audit.
• Serious libraries, thin platforms. The WebMCP-org npm packages descend from the MCP-B work and are maintained. React hooks from MCPCat track the spec.
• Our own crawls agree. We’re wiring WebMCP detection into Spronta’s rendered crawls, and across the sites we’ve checked so far, registered tools round to zero outside demos and the checker sites themselves.

Lighthouse is the quiet forcing function

Since May, Lighthouse ships an agentic-browsing category with three WebMCP audits, and most SEO teams haven’t noticed.

Security is the sleeper issue

WebMCP tools execute in the page with the user’s session. The spec gates access behind a permissions policy and secure contexts, added requestUserInteraction() so tools can force a human confirmation, and Chrome publishes tool security guidance. Those gates cover the browser’s side of the problem, and none of them stops a deceived model from calling a legitimate tool.

What you should do about it

Think in three layers. Agent readiness is a stack, and WebMCP is only the top of it. The base is readable: clean markup, working llms.txt, content that survives without JavaScript. The middle is queryable: structured data an agent can fetch without parsing your marketing pages. The top is actionable: WebMCP tools for search, forms and transactions.

If agent traffic already converts for you, join the origin trial now. Ship one or two tools where structure beats scraping by the widest margin: site search, availability lookups, a lead form. Write the document.modelContext fallback, keep schemas boring, and put a human confirmation on anything that spends money.

If you run a normal B2B marketing site, you’ve got a year of runway and no reason to waste it rebuilding. Spend it on the boring layers: fix what blocks agents today, annotate your forms when the declarative spec lands, and re-run Lighthouse each Chrome release so the audit flip never surprises you.

Frequently asked questions

What is WebMCP?

WebMCP (Web Model Context Protocol) is a proposed web standard that lets a page register typed JavaScript tools which browser AI agents can call directly, instead of scraping the DOM or driving the page with computer vision. A site describes each tool with a name, a natural-language description and a JSON schema, and the browser exposes those tools to the agent.

Is WebMCP a W3C standard?

No. WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group, edited by engineers from Google and Microsoft. It isn't on the W3C standards track, and the API surface is still changing between drafts.

Which browsers support WebMCP in July 2026?

Chrome runs a public origin trial from Chrome 149 to Chrome 156, so sites can test WebMCP on production traffic. Edge ships experimental support behind a flag. Firefox and Safari participate in spec discussions but haven't committed to implementation.

Do any AI agents use WebMCP today?

No mainstream agent calls WebMCP tools yet. Claude, ChatGPT Agent, Perplexity and Gemini still read pages through the DOM or screenshots. Google says Gemini in Chrome will consume WebMCP tools, which would make it the first mainstream client.

What is the difference between WebMCP and MCP?

MCP is a client-server protocol for connecting AI applications to external tools, and it's widely adopted. WebMCP borrows MCP's tool primitives but runs inside the browser: the page registers tools in JavaScript and the browser handles protocol and transport. A site can offer both a hosted MCP server for headless agents and WebMCP tools for agents that browse.

Should I add WebMCP to my website now?

Measure before you build. Join the origin trial if agent traffic already matters to your business, start with one or two high-value tools such as search or a lead form, and treat every tool as a security boundary. For most sites the near-term win is making content readable and queryable for agents, then adding WebMCP tools as consuming agents ship.

Context is the lifeblood of internal agents - even the best model in the most full-featured harness will struggle to produce a better-than-mediocre result if it knows nothing about your company, team or project. Access to internal data was thus a crucial step in enabling Sierra employees to effectively use agents to get their jobs done. In parallel with building out the Pinecone internal agent system, this spring we also created a “gateway” service to allow safe and comprehensive access to the SaaS products and internal systems that Sierra runs on.

The gateway is built on top of the Model Context Protocol (MCP), the industry-accepted way of exposing systems to agents, giving them “tools” to read and act with. Released in late 2024 and exploding in popularity in 2025, MCP is a “mature” (some might say “boring”) technology by AI industry standards. One might thus assume that building an MCP gateway would be a straightforward project. However, it ended up having surprising depth, joining the flotilla of icebergs that Sierra has accumulated.

To convey the kinds of problems that needed to be solved and give a sense of AI-enabled development within Sierra, we thought it would be interesting to present a “development diary” of how the MCP gateway came to be. It captures the work of roughly one-and-a-half engineers who built the gateway, sometimes working full-time and at other times treating it as a background task.

Week 1

Services: 1 · Weekly users: 1 · Pinecone-authored commits: 0%

The AI acceleration team has the expression “grabbing the lock”, meaning roughly “I claim ownership of this area, please check with me first before doing something that might affect it.” With every individual engineer being that much more productive, it behooves us to avoid coordination overhead where possible. It also avoids the temptation of sending off a coding agent on a side-quest to implement an idea you might have had (in case that idea is at odds with the lock holder’s broader vision).

We thus grabbed the lock on the “connect agents to data” problem, both within the team and the company as a whole. By this point everyone at Sierra wanted their agents connected to something: sales to the CRM, recruiting to the applicant tracker, engineers to the data warehouse. While every team could wire up its own integrations (and invent its own permissioning and auditing system), it seemed preferable to solve this once and for all for everyone.

To host the service, we decided to use our existing internal administrative tooling platform, which gave us access to identity and permissioning for “free”. We also had familiarity with the mcp-go library, having already used it for other MCP-related functionality in the Sierra platform, so we continued to prefer that over the official SDK.

Though we had a much more full-featured system running locally, we wanted to get it deployed piecemeal. That way we could validate that it worked end-to-end, and also not overwhelm code reviewers with giant pull requests. The state at the end of the week was a gateway service that you could sign into, connect one service, and get access to just one tool: whoami, returning your identity and access level.

Week 2

Services: 6 · Weekly users: a few dozen, allowlisted · Pinecone-authored commits: 7%

We added the first real services this week: proxied access to Linear, Slack and GitHub, along with an internal tool allowing access to our data warehouse in ClickHouse. We also wanted to have “knowledge” tools to allow internal Sierra documents to be searched. While it was tempting to build something quick-and-dirty bespoke for our needs, we could see the fun of that initial experience being replaced by the toil of maintaining a reliable crawling, indexing and ranking system. Luckily Sierra has a whole team dedicated to that iceberg, and it ended up being much better in the long run to spend a bit of time figuring out how to reuse their system.

With the system now actually being useful, we wanted to validate that it would work for more than just the team. Following product management 101 principles, we found a few early adopters, enabled the service for them and set up a #mcp-gateway-users channel to communicate with them. It continues to this day, serving as the primary communication and feedback channel. While the most AI-pilled users will be constantly checking the gateway for new services and tools, most users still benefit from the occasional feature roundup post.

On the agentic development side, as we were fleshing out the system, we kept noticing that coding agents would solve problems at the wrong layer, or not be aware of key system properties. We ended up creating an mcp-gateway.md document to capture these invariants. Unlike traditional design docs or RFCs, it is a “living” document - all major tasks would ask the agent to refer to it and update it when completed. It was a constant battle to keep it high-level enough while still capturing important nuances; even the latest models love to over-explain. Serving as the “curators” for that document has at times felt like our most important contribution.

Giving coding agents a self-verification mechanism is key to having them successfully complete tasks with minimal intervention. This seemed straightforward for this project; after all, what could be more natural than “implement this tool, and then call it when you’re done to make sure it works.” However, we observed that agents love to “cheat” (not surprisingly). For example, given a broken authentication setup, the agent would helpfully read the correct token from the file system or local database and use it instead. At other times, if the MCP server behavior was not fully spec-compliant (and thus the built-in client would fail), the agent would fall back to manual HTTP requests via curl, but still declare success. We thus ended up using “consumer-grade” agents like ChatGPT or Claude for final validation or smoke tests. Their more limited capabilities would ensure they would only use the official functionality.

Week 3

Services: 6 · Weekly users: 12% of the company · Pinecone-authored commits: 10%

The main problem to be solved this week was “cross-customer” data access, or rather how to not allow it. Sierra’s customers entrust us with a lot of sensitive data, and our agent engineers help build many of our customers’ agents, thus they need access to it. A nightmare scenario: what if a coding agent acting on their behalf accesses one customer’s internal operating procedures and then “helpfully” copy/pastes them into another, to save time? While Sierra production systems are carefully partitioned by customer identity, the gateway also gives access to fuzzier sources of data, like Slack channels, internal documents, or ad-hoc analytics. Forbidding their use would negate the benefit of the gateway, so we wanted to find a way to do this safely.

We developed a “tagging” system that observes tool responses and associates them with a customer (if any) and a sensitivity level. It was intentionally designed to be generic; data may come from any system and may not have a well-formed schema. We build up a full audit log of data that was accessed about our customers, blocking attempts to access sensitive data about multiple ones in the same session. To do this efficiently, it is a multi-pass system:

1. A deterministic phase builds a list of candidate customers the data may be about
2. A fast model does an initial pass over those candidates to narrow them down
3. A slower model does a final pass to determine the customer (if any) and the sensitivity of the data

Even with the final pass there are false positives. There may also be a legitimate business reason to look at data across customers, usually in specific departments or for special cases like incident investigations. We therefore allow users to approve this kind of “cross-customer” access, but it happens out-of-band, requires a deliberate user action, and also gets added to the audit log.

With that system in place, we had official sign off to launch the gateway to the entire company. As usage of it started to ramp up, we spent more time building out debugging tooling. While coding agents are happy to make sense of 50K of unformatted JSON or go through noisy logs, some gnarly problems still need a human to look at the data. The integrated MCP Inspector that we added to the gateway and the ability to inspect underlying data structures have saved us a lot of time.

Week 4

Services: 12 · Weekly users: 54% of the company · Pinecone-authored commits: 35%

As usage of the gateway picked up, we started to get a lot of feedback that some official MCP servers were insufficient for the workflows that our employees actually do every day. We thus developed a “REST extension” mechanism, allowing us to augment their tools using the public (or sometimes reverse-engineered) APIs that those services also expose. Conversely some tools provided by these servers were of no interest to us, or were deemed to be potentially dangerous, so we also added a way to block or replace them.

One of the other services that we added to the gateway was Pinecone itself, allowing its sessions to be listed, read, and created. This makes it possible to hand-off work from local coding agents to Pinecone or vice-versa. While the gateway is deeply integrated with Pinecone, it is a separate system and does not mandate its use. This kind of flexibility has allowed us to meet users where they are, and also be flexible as tooling evolves. For example, when Claude Design launched it was possible to give it access to real data from day one, instead of needing to wait for the equivalent functionality to be added to Pinecone.

Week 6

Services: 17 · Weekly users: 80% of the company · Pinecone-authored commits: 58%

The sales team within Sierra officially kicked off its “AI acceleration” effort, and the gateway plays a major part of that. This exposure to a new cohort of users brought new challenges. For example, they are much heavier users of email, and the tooling that we exposed through the gateway was pretty limited (turns out plain text email sending feels sufficient to engineers, but is a bit lacking in pizzazz to everyone else). Being responsive to their feedback (turning around feature requests within a few hours in some cases) was valuable in retaining those users.

Week 7

Services: 20 · Weekly users: 81% of the company · Pinecone-authored commits: 36%

At times development on the gateway reminds us of the early days of web development. We encountered divergent behavior in session reuse, heartbeat expectations, tool name validation, and other edge cases. Quality time spent in the MCP client and extension compatibility matrix pages also triggered flashbacks of caniuse.com. Luckily, it’s 2026 instead of 1996, and agents are very good at debugging all the flavors of OAuth, so it’s not a huge time sink, but it does feel like this iceberg at times.

Many of these investigations happened this week, explaining the drop in the percentage of Pinecone-authored commits. At this time, one of its limitations was that every agent had a “blank slate”, leading to a lot of toil to connect MCP services and recreate a realistic setup for every coding session. Shortly after this week Pinecone got a persisted “devstash” that allowed pre-configured data to be quickly loaded (and persisted if desired). This allowed gateway development to be more done through Pinecone, lowering the barrier to entry. The goal is to have a fully agentic loop: a user can send a “@Pinecone can you add a gateway tool to…” Slack message and then have it available to use a short while later.

Week 8

Services: 24 · Weekly users: 84% of the company · Pinecone-authored commits: 67%

This week we made a concerted effort to have the gateway more completely replace existing production investigation use cases. Those centered around tooling like Grafana and OpenSearch, which didn’t neatly map into our model - their MCP servers are meant to be self-hosted, and the surface area is broad enough that we didn’t want to vibe-code replacements to run as custom tools. Additionally, we need them to provide data for each cluster or region that Sierra runs in. We ended up giving up some of the architectural purity of the gateway, introducing two new subsystems:

• Sidecar services, requiring a local MCP server to be run as another process next to the gateway.
• Multi-region services, where we run multiple instances of each service, one per region.

While this did add operational complexity to the gateway, we hid it from clients - they’re not aware of the “sidecar” distinction, and regions manifest themselves as an injected region parameter to tools, instead of introducing a new concept.

The other use case that was discovered as part of this sweep was the need for “service accounts” - automations are increasingly agent-driven, and we want them to have their own identity instead of using a specific user’s. We generalized the gateway’s “user” concept into a “principal”, allowing both users and service accounts to get the same auditing and debugging capabilities.

Week 9

Services: 26 · Weekly users: 85% of the company · Pinecone-authored commits: 78%

MCP is not the answer to everything. For example, many workflows end up needing access to data from GitHub, and its full-featured MCP server was one of the first that we exposed through the gateway. However, it ended up being a somewhat awkward fit. Agents would spend a lot of time discovering its hundreds of tools, and large responses would bloat the context window.

As an alternative, agents are very familiar with the gh CLI, having encountered it a lot in their training. It also provides more efficient access to the same data – the output can be filtered or piped to a file for later processing. We had initially been wary of exposing the CLI to Pinecone sessions; we want all write or destructive operations to be tied to user intent and approval. We came upon the compromise of having Pinecone mint a separate GitHub token that only gives read-only access to specific repositories, and giving that to the agent to use when invoking the gh CLI. This lets it work with familiar tools, but in a safe way.

Week 11

Services: 32 · Weekly users: 88% of the company · Pinecone-authored commits: 69%

We got an influx of SaaS connection requests this week, and the operational overhead of setting up and making sure they work is getting to us. They are sometimes services that we don’t use ourselves, so even if we configure the connection, we don’t have a good way to validate that it works correctly end-to-end. We ended up introducing the concept of “service owners” - allowing us to federate out this task to folks who actually understand how they’re meant to be used.

Pinecone adoption within the company has also hit an inflection point where the self-service agentic loop that we wished for a while back is now happening more frequently. This week it was a whole service: Google Tasks. We had a power user who really wanted to have it accessible via the MCP gateway. Given their passion and subject matter expertise, their prompting for which tools to implement was a lot better than anything we could have done on the team.

Agentic development is also making it easier to iterate on tool design. For our candidate tracking system we ended up going through four separate implementations this week, since it took us a while to strike the right balance of tool count, flexibility and flexible permissions. With Pinecone writing most of the code, it didn’t feel too bad to throw it away and start from scratch.

Week 13

Services: 40 · Weekly users: 86% of the company · Pinecone-authored commits: 67%

While it’s great that users are contributing more and more services and tools to the gateway, there’s still value that we’re adding to make sure internal services are exposed in a safe manner. One heuristic we have is that the best way to make sure that an agent can’t do something unexpected with sensitive data is to avoid giving it that data in the first place.

This was exemplified by a request we got this week to allow querying of how journeys are used by our customers, to allow an analysis of common patterns. The straightforward approach would be to add a get_customer_journeys tool, allowing any agent direct access to the full content for any customer. The data would get “tagged” as being about that customer, but it seemed sensitive enough that we should have additional safeguards, or find an alternative if possible.

What we ended up adding instead was a get_customer_journey_summary tool, which an agent can use to get an overview of a journey. The gateway handles this one customer at a time, first validating that the summarization “question” is safe (it uses a separate, single-tasking model to rewrite the question in its own words, to ensure it is benign and not requesting sensitive details). We then return that summarized information to the calling agent, which can use it without ever having accessed the raw data.

Today

Services: 45 · Weekly users: 89% of the company

The gateway has become what we hoped: plumbing. The surface is still “visit one page, connect what you use”, with the iceberg underneath staying submerged unless you go looking. None of the individual pieces are exotic, it's the accumulation of a long tail of services and hopefully pragmatic decisions.

We like to think that part of the gateway’s success is due to our focus on actually going to the depths of that iceberg - unlike the usual 80/20 heuristic an automation tool that only covers 80% of a user’s needs rounds down to 0% - it needs to support the full workflow (or be end-user extensible), otherwise they won’t get most of the gains from it.

What has been more surprising has been how community-owned the gateway is: 33 people have contributed code. In July nearly two-thirds of commits came from outside the two of us who nominally own it, usually from someone prompting Pinecone to add the tool they needed. We’re now releasing the lock.

Tesla will record employees' patterns during assembly work to help train its humanoid robot, Optimus.

OpenAI Presence is an enterprise product for deploying controlled AI agents across customer support and internal operations. It combines model reasoning with permissions, policies, evaluations, escalation rules, and tools for improving agents after deployment.

For the past few years, Simon Willison has tested every major LLM release with the same prompt: “Generate an SVG of a pelican riding a bicycle”.

What began as a tongue-in-cheek benchmark has become one of the most famous informal benchmarks in AI. Simon’s pelican-on-a-bicycle results are often among the most upvoted comments on Hacker News threads announcing new releases from AI labs.

The benchmark is now famous enough that there’s plenty of discussion about its usefulness and about whether AI labs might be benchmaxxing on it. When billions or even trillions of dollars are at stake, and a strong result could help persuade users, wouldn’t it be tempting to pelicanmaxx your model just a bit?

I wanted to find out, so I put together a small experiment. I generated 1,008 SVGs across seven frontier models, scored them with an LLM judge, and used Claude Fable 5 for the analysis.

This article presents the results. All the code is available on Github.

How I tested it

I built a grid of 8 animals × 6 vehicles = 48 prompts, where the famous prompt is one cell:

• Animals: pelican, flamingo, heron, otter, raccoon, antelope, whale, cat
• Vehicles: bicycle, unicycle, skateboard, scooter, plane, boat

Every prompt uses almost identical phrasing to Simon’s, only switching the animal and vehicle. The animal and vehicle selection wasn’t done in a very rigorous manner, but I tried to vary both similarity to the original prompt and difficulty. Flamingo and heron are quite similar to pelicans; cat, raccoon, and otter are easy cases; antelope is hard; and whale is as different as you can get.

I tested seven models through OpenRouter: GPT-5.6 Terra, Claude Sonnet 5, Gemini 3.5 Flash, Grok 4.5, Qwen3.7-Max, GLM-5.2, and DeepSeek V4 Pro. I generated 3 samples per prompt, at temperature 1.0, requesting the same reasoning effort from every model. That resulted in 1,008 SVGs.

Then I ran each image through a three-stage pipeline:

1. Rendering: Each SVG is rendered to PNG. If a model returns no SVG or one that fails to render, I regenerate until it produces a valid one, and record the number of attempts. There were only 11 retries across the 1,008 generations.
2. Judging: GPT-5.6 Luna scores each image with 1-5 ratings for the animal, the vehicle, and the coherence of the action. When I rank animals or vehicles below, I use the matching rating on its own. When I need one number per image, I use the average of the three, which I call the judge score.
3. Feature extraction: For a more detailed analysis, I also passed each rendered image to Gemini 3.1 Flash-Lite, which recorded the animal and vehicle it recognized, which way the subject faces, and an open-ended list of scene elements.

My hypothesis is that if a lab trained on the benchmark, it should show up in some combination of the pelican row scoring above what the animal deserves, the bicycle column scoring above what the vehicle deserves, or the specific pelican-bicycle cell beating both.

Evidence #1: The pelicans on bicycles don’t look any better

Before any scoring, the simplest test is to look at the images yourself. Pick a lab to see everything it drew, with the judge’s score under each image.

I looked through the images myself before running the analysis below. Nothing jumped out at me. I couldn’t find a case where the pelican-bicycle images looked noticeably better than the rest of that model’s grid. Maybe in GLM-5.2’s first sample it felt slightly better than the rest, but that batch also produced a pretty cool heron on a skateboard, so I cannot say for sure. Otherwise they look like the rest of what each model draws, and the labs that draw good pelicans on bicycles also do a good job drawing other animal-vehicle combinations.

But this test is hard to replicate, and everyone will have a different opinion. So I wanted something more quantitative, which is why I opted for the method detailed above.

Evidence #2: Labs are not better at drawing pelicans

Here’s the mean animal rating per animal, pooled across all models.

The pelican is 6th of 8, behind cat, whale, raccoon, heron, and antelope. If AI labs were training on the benchmark, you’d expect pelicans at the top. Instead they’re in the bottom half. All seven labs draw cats, whales, and raccoons better than pelicans.

Of course, a pelican may simply be harder to draw than a cat. A lab could train on pelicans and still not push them past the easy animals, so this ranking alone can’t rule that out. I’ll adjust for difficulty in Evidence #4.

Evidence #3: Labs are not better at drawing bicycles

Bicycles fare even worse. They sit second from last, in a near-tie with planes, which come in last.

If labs were training on the benchmark, you’d expect bicycles near the top of this ranking. They’re not. However, the same caveat applies here. A bicycle is harder to draw than a skateboard: it needs two matching wheels, a frame that reaches both axles, handlebars, a seat, and pedals. The judge flags a missing or disconnected one of those on 2/3 of the bicycle images. You can train on bicycle images and still not do a great job relative to simpler vehicles.

One note on the plane, though: I should’ve picked “airplane” instead of “plane” because models often read it geometrically. They drew the animal standing on a flat surface instead of flying an aircraft. The plane is the only vehicle where the feature extractor sometimes found no vehicle at all (25 of 168 images, against zero for the other five), and 20% of plane images scored a 1 or 2 on the vehicle rating, against 5% for bicycles and none at all for boats, scooters, or skateboards.

Evidence #4: Labs are not better at drawing pelicans on bicycles, even adjusting for difficulty

Put the two together and the “pelican on a bicycle” ends up near the bottom of the ranking, at #42 of 48.

But again, some combinations might be just harder to draw than others.

To account for that, I fit a fixed-effects regression on all 1,008 images: score ~ lab + animal × vehicle, plus per-lab interaction terms for pelican, bicycle, and the pelican-bicycle cell, with robust standard errors. The animal × vehicle terms absorb the inherent difficulty of all 48 combinations. The interactions measure each lab’s benchmark-specific boost relative to the average lab, with confidence intervals.

The results:

1. Every per-lab pelican effect (the lab’s boost on pelicans across all six vehicles) lands between -0.11 and +0.14 judge points, and none comes close to significance (smallest p = 0.25).
2. The per-lab bicycle effects (the lab’s boost on bicycles across all eight animals) run from Grok 4.5 at -0.18 (p=0.11) to Gemini 3.5 Flash at +0.27 (p=0.022). Only Gemini clears p < 0.05, and the seven point in both directions.
3. No pelican-bicycle cell effect (the extra boost on the specific combination, on top of the lab’s pelican and bicycle effects) clears p < 0.05. The largest positive is GLM-5.2 at +0.35 (p=0.12), which is the one I mentioned earlier. It’s the closest thing to a signal in this experiment, but still within chance.

Every pelican interval and every cell interval contains zero. Exactly one doesn’t: Gemini 3.5 Flash in the bicycle column. But with 21 tests at p < 0.05, chance alone predicts about one false positive (21 × 0.05 ≈ 1.05), and one is exactly what came up. It also doesn’t survive a multiple-comparisons correction: the Bonferroni threshold across the 21 tests is 0.05/21 ≈ 0.002, and its p-value is 0.022.

But these intervals are wide, about ±0.6 judge points on average. Any boost smaller than that won’t be captured by this test.

Evidence #5: The pelican-bicycle scenes don’t look memorized

Some have suggested that the pelican on a bicycle looks like a memorized composition, pointing to recurring patterns such as the pelican always facing right, or recurring elements like a sun or a scarf. So I wanted to know if this was true.

Direction: All 21 pelican-bicycle images, across all seven labs, face right. No other animal/vehicle combination does that.

However, facing right is common: 60% of all 1,008 images do it. How common depends on the animal and the vehicle, and bicycles are one of the two vehicles where it’s strongest.

It’s hard to draw a pelican or a bicycle facing the viewer, so models almost always draw them from the side, facing left or right. That’s why so few of their images are ambiguous. Other combinations also come close to unanimous: antelope on a scooter and pelican on a scooter land at 20 of 21, and heron on a bicycle at 19 of 21. So 21 out of 21 doesn’t seem like an outlier.

Scene elements: I let the extractor name any element it saw in the image. These are the counts.

A memorized scene would show up as the same set of elements recurring picture after picture. I went looking for that, and found some combinations do tend to produce the same elements every time. Every single flamingo on a boat has a sun in it. Otters on planes wear scarves 38% of the time. Cats on bicycles get a basket 38% of the time.

The pelican on a bicycle doesn’t seem to have anything particularly different about it. It just has some elements that appear more frequently, like every other animal-vehicle combination.

Limitations

1. Using a single LLM judge for scoring. Every score here comes from one model, GPT-5.6 Luna, looking at one image at a time. I didn’t do much alignment and didn’t check how often it agrees with itself on a re-run. If a model just can’t judge a drawing reliably, none of the numbers above mean much. The judge is also from the same family as one of the contestants, GPT-5.6 Terra. However, every lab draws all 48 combinations, so a judge that happens to like one lab’s style lifts that lab’s whole grid at once. But that doesn’t change the results because this analysis only cares about the within-lab differences.
2. SVGmaxxing. A lab that optimized SVG generation as a whole (or a subset such as animals on vehicles) rises on every cell at once and looks identical to a lab that’s just good. This experiment can’t detect that.
3. Limited budget. The whole experiment ran on roughly $80 of API credits. That capped it at 3 samples per cell, a single judge, and 7 models. This also prevented me from iterating too much on the prompts and pipeline, as with the “plane” vs. “airplane” case.

Conclusion

Sorry, HN haters, but there’s little evidence that AI labs are pelicanmaxxing. Or at least they’re not doing it in a plainly obvious manner.

Pelicans aren’t drawn any better than other animals. Bicycles aren’t drawn any better than other vehicles. And no lab draws the combination better than its pelicans and bicycles already predict. GLM-5.2 comes closest: it has the largest boost on the exact pelican-bicycle cell, and its first pelican-on-bicycle sample caught my eye. But the effect is small and not significant, so I wouldn’t put too much weight on it.

The other thing that stands out is direction in the scene composition. All 21 pelican-bicycle images face right, the only combination in the grid where every image agrees. But it doesn’t seem that strange. Facing right is the norm across the experiment. Three other combinations land at 90% or above, and with 48 of them, I’m not surprised one reached 21 out of 21.

The more plausible story is SVGmaxxing like Google/DeepMind does. Other labs might be doing it more quietly. Sadly, this experiment can’t say who’s doing it. But at least you can sleep tonight knowing that AI labs are not producing terabytes of pelicans on bicycles just to trick Simon Willison.

If you want to look at the data yourself, the full pipeline is in the repo.

Footnotes

1. the practice of optimizing AI models to achieve high scores on popular benchmarks.

Citation

@online{castillo2026,
  author = {Castillo, Dylan},
  title = {Are {AI} Labs Pelicanmaxxing?},
  date = {2026-07-18},
  url = {https://dylancastillo.co/posts/pelicanmaxxing.html},
  langid = {en}
}

Announcing Genesis-Science-1, an Open-Weight Model for Scientific Research

Arcee AI is among one of the first industry partners supporting the new Genesis Mission program. A DOE-hosted contribution portal opens today, with first-round applications due August 6, 2026.

Overview

The U.S. Department of Energy and Arcee AI today announced Genesis-Science-1, or GS1, an American open-weight AI model and governed research system designed to complete scientific computing workflows while preserving a reproducible record of its work.

GS1 is a new program under DOE’s Genesis Mission. Arcee AI will lead model development. DOE scientists and engineers at participating national laboratories will supply reviewed scientific materials, define representative research tasks, design evaluations, and validate the system’s results.

Arcee will secure the compute, curate the training data, train the model through pretraining and post-training, build the governed execution environment, create training workbenches from approved DOE materials, and conduct evaluation and release.

DOE and participating national laboratories will ground the system in scientific practice. Contributions may include experimental and observational data from user facilities, simulation outputs and run logs from supercomputing campaigns, materials and chemistry collections, research software, and the tools scientists use to conduct and review their work. Materials will enter the program only after completing the Department’s release-review process.

DOE also opened the Genesis-Science-1 contribution portal today. The portal, hosted by Argonne National Laboratory at genesisopenmodels.anl.gov, invites universities, national laboratories, companies, scientific nonprofits, and research organizations to contribute data, research environments, evaluations, and technical expertise. Applications for the first contribution window close August 6, 2026.

"A country cannot lead in AI if everything it leads in is closed," said Mark McQuade, co-founder and CEO of Arcee AI. "With Genesis-Science-1, we're holding American open weights to a demanding standard: useful scientific work under real operating constraints, judged by the people who do it."

How Genesis-Science-1 will be built

Scientific computing rarely begins with a clean prompt and a single correct answer. A researcher may inherit an aging Fortran codebase, a partially completed simulation campaign, conflicting run logs, and several reasonable options for what to try next. Progress depends on a sequence of technical judgments about which result to trust, which test to run, when to restart, and whether the evidence supports a conclusion.

GS1 will train in scientific workbenches that reproduce these working conditions. Initial areas include high-performance-computing code modernization, experimental analysis, simulation campaigns, materials science, and energy systems.

Each workbench will contain the code, data, tools, documentation, logs, partial results, and failure states needed to reconstruct a research workflow. Training environments may include Python, Fortran, C and C++, MPI and OpenMP, CUDA and HIP, command-line tools, notebooks, simulation packages, and computing schedulers.

The model will operate through a governed execution system. Approved tools will run in sandboxed, staged environments. The system will maintain task state, checkpoint progress, manage retries and recovery, and record the prompts, tool calls, code changes, datasets, intermediate artifacts, and conclusions associated with each run.

Human review will remain part of the process. People will approve decisions involving safety, security, publication, and resource use. GS1 will not receive blanket access to DOE systems.

A successful run must carry a workflow from plan through report, revise the approach when the evidence changes, recover from tool failures, and leave a record that another researcher can inspect. Scientific experts will judge whether the result is sound and whether the supporting evidence is complete enough to reproduce.

Why open weights matter for scientific institutions

DOE and its laboratories may need to run a model inside their own infrastructure, preserve a specific version for years, adapt it to a specialized field, and operate without a permanent dependency on an external API.

Open weights support those requirements by allowing an institution to hold and operate the model directly. They do not eliminate the need for permissions, evaluations, sandboxing, audit logs, deployment controls, or disciplined operations. The institution responsible for the work must still design and enforce those controls.

GS1 is intended to increase the supply of American open-weight models built for those operating conditions. Its release will include the model weights, a technical report, and public workbench and demonstration artifacts.

Arcee has built and released open-weight models end to end on compressed timelines, with experience spanning data, architecture, pre-training, post-training, evaluation, and deployment. Over six months, the company scaled the Trinity program through increasingly large training runs, culminating in Trinity Large, a 400-billion-parameter sparse mixture-of-experts model. That operating experience allows Arcee to work closely with DOE scientists and contributors throughout development and deliver Genesis-Science-1 on an accelerated schedule.

Contributing to Genesis-Science-1

The program is seeking scientific and technical materials for several stages of model development.

Foundation-stage contributions may include scientific text, code, documentation, and structured technical collections suitable for pretraining, midtraining, or context extension.

Post-training contributions may include expert demonstrations, annotated task examples, research software, datasets, complete workflow environments, reinforcement-learning tasks, held-out evaluations, scoring rubrics, tests, and verifiers.

The program also needs scientists and engineers who can review tasks, model behavior, and completed artifacts. Infrastructure providers may submit rolling inquiries about additional training or evaluation capacity.

The 2026 program has two scheduled contribution tracks. Organizations may apply to both when the proposed contributions are distinct.

Applicants will identify the relevant track, describe the scientific work and its importance, explain what material is ready, name the experts available to support it, and state the proposed terms of use.

The public application form collects descriptions and metadata only. No scientific material is transferred during the application process, and each contributor specifies how its material may be handled.

Applications will be reviewed through five gates: scientific fit, rights and handling, expert and evaluation readiness, technical integration, and final program selection.

Selected contributors will work with the researchers building and evaluating GS1. They will receive early evaluation access as the system develops and will be credited in the technical report and release materials.

The program is particularly interested in workflows that are poorly represented by standard AI evaluations and require direct collaboration with the researchers who perform the work.

Apply at the DOE contribution portal: https://genesisopenmodels.anl.gov/

Questions may be directed to: genesis-science-1@anl.gov or genesismission@arcee.ai

About the Genesis Mission

Launched by executive order in November 2025, the Genesis Mission is a Department of Energy-led national initiative to accelerate scientific discovery through artificial intelligence. Its stated goal is to double the productivity and impact of American science and engineering within a decade.

The mission connects DOE’s 17 national laboratories, leadership-class computing facilities, scientific data resources, and partners across industry and academia. DOE Under Secretary for Science Darío Gil directs the Genesis Mission. More information is available at energy.gov.

About Arcee AI

Arcee AI is a U.S. open-model lab that develops open-weight foundation models end to end, including data preparation, architecture, pretraining, post-training, evaluation, and deployment.

Its Trinity family ranges from compact models designed for local use to Trinity Large, a 400-billion-parameter sparse mixture-of-experts model. Arcee builds models that developers, enterprises, and public institutions can run and adapt on infrastructure they control. More information is available at arcee.ai.

Full article content is not available for inline reading.

Read the original article →

• Speaking in an interview with CNBC, TSMC Chief Financial Officer Wendell Huang said the chipmaker will double down on its Arizona expansion.
• The company's 2-nanometer technology will drive its revenue in the next quarter.
• It sees a manageable impact from Middle East conflicts due to its diversified sourcing and safety stocks.

TSMC is racing to accelerate capacity at its Arizona factory as the company continues to see a "multi-year demand mega trend" from its customers, Chief Financial Officer Wendell Huang told CNBC.

TSMC, or Taiwan Semiconductor Manufacturing Co., is scaling up its mega investment in Arizona by committing an additional $100 billion to aggressively expand its U.S. chipmaking footprint amid a surging multi-year structural demand for AI.

The fresh commitment raises TSMC's total investment pipeline in Arizona to $265 billion, underscoring a massive AI-driven capacity build-out that also fueled an upward revision to the company's full-year capital expenditure to between $60 billion and $64 billion.

Speaking in an interview with CNBC's Emily Tan, TSMC's Huang said the fresh investment comes on the back of robust customer demand in the U.S. market and strong government support.

"We're seeing this strong-structure, multi-year demand, and we do not plan to leave any food on the table for anybody else," Huang told CNBC. "As long as the megatrend is right, then we're able to continue to deliver the profitable growth to our shareholders," he said.

Surging demand

In order to meet surging customer demand, TSMC is aggressively optimizing its leading-edge capacities, including a fast conversion of its 5-nanometer capacity to the advanced 3-nanometer node to support customers, Huang said.

The nanometer figure refers to the size of each individual transistor on a chip. The smaller the transistor, the more of them can be packed onto a single semiconductor. Typically, a reduction in nanometer size can yield more powerful and efficient chips.

When it comes to TSMC's U.S. expansion, phase one, using 4-nanometer technology, is already up and running, the CFO told CNBC.

"It's going to be bigger and bigger in the next few quarters," Huang said, framing the 2-nanometer technology as the company's newest revenue driver heading into the third quarter, following its initial revenue generation in the second quarter.

U.S. fab construction costs are four to five times higher than in Taiwan, however, Huang said that while the initial dilution will widen as the scale of overseas operations grows, the expansion will ultimately further foster the development of the U.S. semiconductor ecosystem.

"It will be both the front-end wafer fabs and back end advanced packaging fabs," Huang said regarding the deployment of the fresh $100 billion investment.

Ahead of the earnings release, the company ended Thursday's session up 1.23%, yet it reversed course on Friday to close down 7.29%. The stock is up around 48% year-to-date.

Responding to the company's share price performance, Huang said TSMC does not have any control over the financial markets. "What we can do is really to focus on fundamentals of our business," he said, adding that while the sector faces hefty price increases in components, the company sees minimal impact due to its strategic focus on the high-end market.

Aside from market factors, TSMC is also managing its regulatory footprint. On China, Huang said that TSMC continues to comply with all export controls while serving its Chinese customers, who contribute about 8% of total revenue.

The chipmaker is expanding its focus toward future expansion drivers. Regarding the prospects of physical AI, he added that the company's recent joint venture with Sony for image sensors is part of its strategic commitment to supporting long-term customer growth in specialty technologies.

LangChain released an Eval Engineering Skill that maps agent repositories and production traces into executable Harbor evaluations.

Anthropic appears to be preparing a new kind of project for Claude, one where the assistant does more than hold files and answer questions. A recent build surfaces a choice, at the moment a project is created, between a standard project and a "managed" one, described with the line that Claude takes on tasks and keeps the project organized. That framing points to a persistent Claude environment that carries the surrounding context, works with some autonomy, and could run scheduled work rather than waiting for each prompt. Beside it, the projects area of the side navigation is being reworked to list only pinned projects, based on tester feedback. Both are marked internal for now, limited to staff and a small circle of trusted testers, with no release date attached.

The pieces line up with work Anthropic already ships elsewhere. Its developer platform has offered Claude Managed Agents since April, cloud-hosted agents that hold state across sessions and refine their own memory through a scheduled process the company calls dreaming. Cowork projects already run scheduled tasks, and Claude Code carries context between sessions through project memory and instructions. Managed projects read like those threads gathered into one consumer surface, where sessions in a project would share memory and instructions and each one feeds the project's wider knowledge. The build also notes a project can be personal or shared, with shared projects held for Team and Enterprise plans.

For Anthropic, this fits a steady move from chat toward standing, self-organizing workspaces. The company has tried knowledge bases before and has been running Conway, its always-on internal agent, which is set to close on July 24, timing that could mark a handoff rather than an ending. If managed projects reach users, they would offer a project that quietly maintains itself between visits, a shape no rival lab currently sells. A firm date is still missing, but internal testing is plainly live.

How our universal content processing platform Riviera evolved for AI and beyond

Every day, Dropbox products transform enormous amounts of content behind the scenes. Open a PowerPoint deck on your phone in Dropbox, and it’s rendered into a crisp preview you can quickly browse. Finalize an agreement in Sign, and it's flattened into a PDF. Upload a video to Replay—our video review and approval tool—and it's transcoded into a lightweight version that streams instantly. These experiences span different products, but they're all powered by the same underlying system.

That system is Riviera, our content processing platform that’s been iteratively improving content transformation in our products for roughly a decade. Whenever a file needs to be prepared for another application, Riviera does that heavy lifting in the background while operating at a massive scale. (For example, Riviera transforms vast amounts of massive media into streamable content, each day producing output equivalent to 8 years of video). Initially, Riviera started as an internal service for generating file previews, but over time, it evolved into a shared platform used across Dropbox by product teams like Search, Replay, Sign, and Dash. We are now making these capabilities available to our developer ecosystem and design partners through API and Model Context Protocol tools.

As Dropbox built AI-powered products like Dash, the need for reliable, reusable content transformation only grew. Before an AI model can answer questions about a document or summarize a report, that content has to be extracted, converted, and prepared in a consistent way—a challenge many developers now face as they build AI applications of their own. Whether you're building a content management system, automating document workflows, indexing files for search, or preparing documents for AI applications, you can now use our API to build on the same infrastructure that powers Dropbox products.

In this story, we’ll cover how Riviera grew from a preview service into a shared platform, the architectural decisions that made that possible, and why we've opened those capabilities to engineers outside of our organization.

It started with a preview problem

Because Dropbox users store all kinds of files, they need to be able to open any of them on any device quickly and see something useful. These are what we refer to as previews, a visual representation of your files across Dropbox surfaces. Meeting that expectation is harder than it sounds. Dropbox supports more than 300 file formats, each of which can produce multiple outputs: thumbnails, full previews, extracted text, streaming manifests, metadata, and more. To do this, we needed to consider how to build a system to serve these previews.

Building a separate service for every file format and every output would quickly become unmanageable. Doing so would mean many capabilities would end up duplicating small pieces of other capabilities. Imagine both PowerPoint and Word processing needing PDF logic, if they lived as separate services we then have to maintain similar PDF logic in two places. This would make maintenance more difficult and spread redundant dependencies around the environment where Dropbox runs (the collection of software and hardware that make up our architecture). Configurations would drift, package versions would skew, and the operational burden would grow.

This meant we needed a managed platform, a place where we could construct these services to be shared across many different features. We needed one place where the dependencies and tools could live, with a team that could build deep expertise in these capabilities. We also needed a design that could scale against all of our stored file types and make the platform itself manageable.

In attempting to solve for this problem, the breakthrough came when we stopped thinking about every preview as a separate feature. Instead, we broke each task into a series of smaller transformations that could be reused. Rendering a PowerPoint preview, for example, doesn't require a custom PowerPoint renderer from start to finish. Riviera first converts the presentation into a PDF, then turns each PDF page into an image that can be displayed anywhere.

Those same PDF-to-image steps can also be reused for PDFs themselves and for other workflows that need page images. By building reusable transformations instead of one-off pipelines, we could support new file types and new products without starting from scratch each time.

That idea shaped Riviera’s architecture. We built a central point for collecting requests, composing the work to be done, and dispatching that work to backend workers. This central piece validates requests and caches responses which protects the backend workers from duplicate or invalid work. Each backend worker belongs to a specific type of transformation, which allows us to have one point of maintenance and scaling per capability. Today, Riviera has more than 100 such capabilities performing hundreds of thousands of transformations every second.

Separating coordination from execution made the platform easy to extend. Supporting a new file format or a new type of transformation usually meant adding another plugin rather than changing Riviera's core infrastructure. As Riviera grew, the core system stayed stable while its capabilities continued to expand.

A platform begins to emerge

While Riviera wasn't originally intended to be a shared platform—it started as an internal tool run by a dedicated Previews team—it didn't take long for other teams to recognize they had similar content transformation problems. For instance, the thumbnails created for previews turned out to be equally useful for machine learning teams normalizing images for feature extraction. If both consumers could use the same 160×160 thumbnail, Riviera only had to generate it once.

The Search team soon adopted Riviera to prepare documents for indexing. As Dropbox expanded with products like Sign, DocSend, and Replay, those teams also found they could reuse existing transformations instead of building new infrastructure. As adoption grew internally across our organization, we opened the plugin model to product teams themselves. Engineers could contribute new transformations while the Riviera team maintained the platform's core architecture. Plugins became Riviera's shared library of transformations.

Dropbox Replay, our video review product, became one of the best examples of this model in practice. To build a video review product, you have to complete the complex task of transcoding and manipulating video data. Riviera was able to fill that need, allowing the product to grow rapidly and iterate on its capabilities instead of building from the ground up.

A pattern emerged. Product teams identified a transformation they needed. Riviera exposed an existing capability or added a new plugin. Features that might once have taken months shipped in weeks, and every addition made the platform more capable for the next team that adopted it.

Dash changed the scale

When Dash brought AI to Dropbox, it created a new kind of demand for Riviera. Before an AI model can answer a question about a document or summarize a report, the document has to be transformed into something the model can understand. Doing that well means extracting text, recognizing scanned pages, pulling out metadata, and converting hundreds of different file formats into a consistent representation.

Those aren't AI problems. They're content transformation problems, and they're exactly what Riviera was built to solve. Just as Replay found value in Riviera’s media capabilities, the Dash team was able to accelerate their content processing pipelines by using existing Riviera features.

Because Riviera already supported hundreds of file types and transformations, the Dash team didn't have to build a new document processing system from scratch. As Dash ingests content from Dropbox, Google Drive, Slack, and other connected sources, Riviera prepares those files for indexing and AI. Later, when someone asks a question about a document, those transformed contents are then used as relevant context for the models to generate a response.

That investment paid off well beyond Dash. Improvements to text extraction made both AI responses and search results more accurate. Faster caching reduced the work required to generate previews, answer questions, and process documents. Support for a new file type only had to be added once before it became available everywhere Riviera was used.

That's the advantage of shared infrastructure. Instead of every product solving the same content transformation problems independently, Dropbox solves them once in Riviera, and every product built on top of it benefits.

How reusable platforms create lasting value

Riviera started with a single goal: make it possible to preview any file stored in Dropbox. Solving that problem meant building reusable content transformations instead of product-specific pipelines. As more teams across Dropbox adopted the platform, Riviera expanded far beyond previews to support hundreds of file formats and increasingly diverse workloads, powering features across Search, Replay, Sign, Dash, and more.

That growth shaped both the platform and the philosophy behind it. Unlike a feature, which delivers value once, a platform becomes more valuable every time another team builds on it. Each new product introduced new file types, workloads, and requirements. Every improvement made Riviera more capable, and every team building on top of it benefited from those investments.

The platform was also designed to scale without becoming more difficult to maintain. Its plugin architecture allows engineers to add support for new file formats and transformations without changing the core system, while clear boundaries around what belongs in Riviera have kept it focused on transforming content reliably at scale.

Today, we’re extending that reuse beyond Dropbox by making a growing set of Riviera capabilities available through our public API and MCP tools. The platform that began as an internal preview service is now infrastructure that developers can build on, too. And while the technology has changed dramatically over the past decade, the idea behind Riviera hasn't. Build reusable systems around common problems, and they'll continue creating value long after the original use case is gone. To learn more about the available capabilities, visit our developer portal here.

DuckDB is fast because it processes data in cache-friendly batches of 2,048 rows instead of one row at a time. Its vector formats, selection vectors, precompiled operations, and push-based pipelines reduce copying, function-call overhead, and parallel execution costs.

Backfilling: the most underrated feature of a data pipeline

Most data organizations design for one direction of time: forward. When a pipeline goes live, its job is to ingest whatever shows up - new filings, new prices, new transactions. That part gets attention, dashboards, and service level agreements. What gets far less attention is everything that existed before the pipeline did.

Backfilling is the feature that lets you give that same attention to the rest of your data. In my experience, teams often treat it as an afterthought patched on during a crisis. I decided to design for it from day one, and it’s made a real difference in how much time we spend fighting our own pipeline.

What we mean by backfilling

Backfilling shows up in two forms, and they often get conflated.

The first is historical ingestion: loading data that already exists in the world as if you had been collecting it all along. Form ADV is a good example - the SEC has published decades of investment adviser filings. Backfilling here means treating 24 years of history with the same rigor as tomorrow’s filing, not as a one-time bulk import that gets “special-cased” and forgotten.

The second is migration: moving data that already lives in one of your own systems into a new one. This is the kind of backfill most engineers have scar tissue from. Organizations sink enormous budgets into “migrations,” and they are almost always painful, rarely fully complete, and leave behind a trail of engineers who never want to touch that codebase again.

I treat both as the same underlying problem, and that changes how you build.

Migration code is production code

Our pipeline runs in three stages - extract, raw, transform. Extract pulls the filings as-is from the SEC. Raw lands them in table form, no cleanup. Transform is where we apply the cleaning, modeling, and merge logic that turns raw filings into usable data. It is these three stages that allow us to ingest from multiple sources, including backfilling historical data.

Engineers’ usual intuition when backfilling is to write a separate script, because it feels like a one-off job. They assume it’ll be quick and easy. Typically, the script walks through history, does its thing, and gets deleted - or, more realistically, gets left in a scripts/ folder to rot. Sound familiar?

That intuition is exactly what makes backfills fragile. The logic that ran once, under pressure, has never been tested with the same rigor as your production pipeline.

Instead, the incremental pipeline and the backfill should be treated as the same pipeline, not just similar ones. A config flag changes what data it looks at, not how it processes that data.

At Opto, we run this on Dagster, and its run config has been the mechanism that makes this practical. Our transform layer for Form ADV takes the same config object:

class FormAdvTransformConfig(Config):
    full_refresh: bool = False
    refresh_crd: list[str] | None = None

From that object, we resolve one of three modes:

def get_mode_from_config(config: FormAdvTransformConfig) -> FormAdvTransformMode:
    if config.refresh_crd:
        return FormAdvTransformMode.REFRESH_SINGLE
    if config.full_refresh:
        return FormAdvTransformMode.FULL_REFRESH
    return FormAdvTransformMode.INCREMENTAL

Incremental - process only what changed since the last run. The default, and the cheapest.

Full refresh - rebuild everything from raw. This is our backfill: a schema change, a recovery, or genuinely loading history for the first time.

Single entity - reprocess one specific record on demand. Invaluable when a customer asks “why does this look stale?” and you need an answer in ten seconds, not a full pipeline run.

Why this matters: the transform logic never has to know why it’s running

The contract is simple: regardless of mode, the output is always the same shape - batches of keys to process.

def get_crds_to_process(config, session) -> list[list[str]]:
    if config.refresh_crd:
        return [config.refresh_crd]

    if config.full_refresh:
        all_crds = query_all_crds(session)
        return chunk_into_batches(all_crds, batch_size=5000)

    crds = query_crds_with_source_date(session, partition_date)
    return chunk_into_batches(crds, batch_size=5000)

The transform loop downstream doesn’t branch on mode at all:

crd_batches = get_crds_to_process(config, session)

for batch_num, crd_batch in enumerate(crd_batches):
    process_batch(crd_batch, session)

Once or forty thousand times, the loop runs the same processing logic either way. The code path you verify against a single CRD in refresh_crd mode is the same code path that runs against all 1.8M rows in a full refresh. There’s no separate “backfill logic” to have less confidence in.

Backfills are safe because time is bi-temporal

None of this works if re-running a backfill can silently overwrite or corrupt what’s already there - that’s where bi-temporality does the heavy lifting. Every write carries a business time and a system time, so re-running a backfill just opens new system-time versions instead of destroying history:

session.write_to_ducklake(
    data=df,
    schema_name="transform",
    table_name="form_adv_firm_identity",
    mode="bi-temporal-merge",
    key_columns=["firm_crd_number"],
    value_columns=["legal_name", "business_name", ...],
    date_column="filing_date",
)

Analyzing the results with MotherDuck

Once you have a system that’s resilient and keeps everyone on one standardized approach instead of a dozen ad hoc ones, you get to spend more time actually analyzing the data instead of babysitting the pipeline. For that, we have a secret weapon: the MotherDuck MCP server.

The goal for “raw” is simple: get the source dataset into table format with zero assumptions - the data as we received it.

A simple prompt gets us started: “Use the MotherDuck MCP server, focus on my database shared_sec_lakehouse_prod and the table transform.form_adv_firm_ownership, and analyze my data.”

Key Observations

• The data is freshly full-refreshed - all 1.8M rows share the same system_valid_from (2026-07-04), indicating a recent full pipeline run.
• Ownership status is highly fragmented - 309 distinct values, many being comma-joined multi-role combinations. The top status categories (Member, Shareholder, Managing Member) account for <30% of non-null rows; 48% are null. This is a normalization opportunity if needed downstream.
• Temporal depth is excellent - 26 years of history with clear open/close patterns tracking real ownership changes over time.
• The volume growth trend is healthy - ownership records opened per year grew from ~30k in 2002 to ~114k in 2024, reflecting both market growth and improved SEC reporting requirements post-2012.

Temporal Gaps Between Versions - 8,137 cases

When an owner disappears and then reappears for the same firm_crd_number + owner_key, there’s a gap between the valid_to of the prior record and valid_from of the next.

Root cause breakdown:

• 82% have a different value_hash - the person genuinely left and returned with updated data (name change, new role, etc.).
• 18% (1,441) have an identical value_hash - the owner disappeared from one filing then reappeared unchanged in a later filing.

Summary Scorecard

The real payoff

A resilient pipeline is what buys us that time in the first place - time we can spend more productively analyzing the data. Paired with the MotherDuck MCP server, that combination has saved us a ton of time: we ship faster, and with more confidence in what we’re shipping.

Download from GitHub

Release archives contain the native server and CLI. Pick the asset for your platform, extract it, and start the server binary.

Assets are named linux-x64, macos-arm64, and windows-x64.

curl -fsSL -o latlng-linux-x64.tar.gz \
  "https://github.com/tobilg/latlng/releases/latest/download/latlng-linux-x64.tar.gz"

tar -xzf latlng-linux-x64.tar.gz
chmod +x latlng-server latlng-cli
./latlng-server

Full article content is not available for inline reading.

Read the original article →

DuckDB's Iceberg extension now supports CTAS, MERGE INTO, INSERT, UPDATE, and DELETE, making it viable for full CRUD-style Iceberg ETL locally without Spark. Paired with MinIO for S3-compatible storage and LakeKeeper as a Rust Iceberg catalog, teams can test scripts cheaply in Docker and switch to AWS S3Tables by toggling environment variables and secrets.

Meta went on trial in Nashville on Monday over Tennessee’s allegation that it engineered Instagram to keep teenagers compulsively scrolling, one of the first state cases to put the question of addictive design before a jury.

Jury selection began on 20 July in a proceeding expected to run about seven weeks, part of a wider wave of litigation in which a federal judge recently cleared states to argue that Meta hooked children on its apps.

Tennessee’s attorney general, Jonathan Skrmetti, contends the company deliberately built features such as autoplay, Reels, notifications, and disappearing posts to maximise engagement among minors while publicly playing down the risks.

The complaint also alleges Meta buried internal research linking Instagram to youth harm, an accusation that runs through a separate $1.4 trillion penalty demand four other states have filed for an August trial in California.

The state says internal documents show executives, including chief executive Mark Zuckerberg, were warned about the app’s effect on teenagers and were slow to respond.

Meta disputes that reading of the record and argues its research has been mischaracterised in filings across the country.

The case is being tried in two phases. A jury will first decide whether Meta broke Tennessee’s consumer-protection law, after which a second phase would weigh penalties and any order to redesign the app.

That structure lets the state separate the question of wrongdoing from the harder fight over what a remedy should look like, and it gives the jury a narrower first task than the sprawling complaint might suggest.

Under that statute, the state is seeking damages of up to $1,000 for each violation, a figure that could mount steeply given the scale of Instagram’s teenage user base.

Tennessee is also asking the court to compel changes to features it says were engineered to be habit-forming.

Meta rejects the allegations.

“We’ve spent a decade building safe, age-appropriate defaults for teens alongside simple tools for parents to set the right boundaries for their family,”

The company argues the suit is aimed at content posted by users rather than the design of the platform itself, and that Section 230 of the Communications Decency Act shields it from liability on that basis.

How the Nashville jury draws that line could carry weight for the many state cases still queued behind this one.

Tennessee’s action, filed in Nashville, is part of a series of state suits that gathered pace after a coalition of attorneys general took Meta to court in 2023.

Skrmetti’s office has framed the trial as a test of whether consumer-protection law can reach the way a social network is built rather than merely what appears on it.

The company arrives in court on a losing run. In March, a New Mexico jury ordered Meta to pay $375 million in a separate child-safety case, and a Los Angeles jury the same month found the company liable, alongside YouTube, for harming a young woman’s mental health.

Meta has said it is appealing the Los Angeles verdict and maintains that no court has found its products to be defectively designed.

The company also points to years of investment in parental supervision tools and dedicated teen accounts that restrict who can contact younger users.

Regulators abroad are moving on similar ground. The European Commission has been probing addictive design on Facebook and Instagram under the Digital Services Act, with a focus on infinite scroll, autoplay, and notifications aimed at children.

The timing is awkward for Meta. The Nashville trial runs into the autumn and overlaps with the larger California proceeding, where a court has already declined to dismiss the states’ central claims and set damages arguments for August.

What the jury makes of Instagram’s design remains the open question. A finding for Tennessee would hand the remaining states a template to follow, while a defence win would blunt the momentum that a run of adverse verdicts has lately given the plaintiffs.

Bitgrain, a browser creative suite made without AI

Bitgrain is a browser-based deterministic creative suite. In one tab it works as a photo lab, a print shop, a design studio, a brand toolkit, and a video editor, all with no AI. No prompts, no generative models, no neural networks. Just classical, repeatable image processing that you control end to end. Open the editor or the Bitgrain Studio, drop in a photo, and start working in seconds.

The same deterministic engine powers three surfaces: an editor for developing photos and fast renders, a multi-layer studio for full design and brand work, and a video timeline for motion and short-form video. Everything runs in your browser, everything is free to start, and everything exports at production quality.

Bitgrain is for photographers, designers, illustrators, musicians, print makers, and independent labels who would rather pull levers than write prompts. The result is craft you can take credit for, with no licensing fog, no surprise outputs, and no machine learning sitting between your idea and the page.

Deterministic effects, not prompts

Every effect in Bitgrain is a classical image-processing algorithm. 29 stackable effects, 14 dither algorithms including Floyd-Steinberg and Atkinson, Bayer ordered matrices, halftone screens in mono, color, and CMYK, Sobel edge detection for contour tracing, crosshatch, ink wash, manga screentone, glitch, riso color separation, and photo-to-ASCII and Braille conversion. 38 film and cinematic LUTs and 24 hardware palettes sit alongside. Same input, same output, every time.

Because the effects are deterministic, your work is reproducible. Save a project, hand it to a collaborator, reopen it next year, and you will see the exact same pixels. Bitgrain is built around the .btg project format so that grain, layers, type, and palette decisions all travel together.

Develop and grade photographs in the browser

Bitgrain develops around 30 camera RAW formats entirely in the browser, from Canon, Nikon, Sony, and Fuji to medium-format Hasselblad and Phase One, plus HEIC and HEIF from iPhone, TIFF, and DNG. Grade with 38 film and cinematic LUTs like Portra 400, CineStill 800T, Kodachrome, and Tri-X, add grain, haze, and bloom, and export genuine HDR stills in BT.2020 and PQ. Batch a whole shoot through one effect chain and export a ZIP. Your photo is developed on your machine and never uploaded for processing.

Real print output: risograph and CMYK separations

Bitgrain is built for real print production, not just screen previews. Export risograph ink separations as per-ink layer PNGs in a ZIP, up to four inks from a nine-ink set. Pull true CMYK four-channel halftone separations, add a newsprint and zine ink-on-paper finish, flatten to screen-print-ready art with a limited palette, and export pen-plotter SVG with real vector paths. Duotone ramps and cyanotype and blueprint looks round out the print toolkit.

Make album covers, posters, and zines that look printed

Bitgrain is at home with record sleeves, twelve-inch covers, gig posters, art-show flyers, indie zines, and editorial spreads. Combine high-resolution halftone with Risograph color layers and screen-print grain so the work feels like it came off a real press. Lay out type with Bricolage Grotesque, Instrument Serif, or any custom font you upload, apply dither and grunge passes selectively with the brush tool, and export PNG for the web or SVG for vector workflows.

The Bitgrain Studio, a full layered design canvas

The Bitgrain Studio is a complete multi-page, multi-layer editor. A true vector pen with bezier editing, 13 shape types, 16 blend modes, generative patterns, snap guides, alignment tools, and custom typography, plus design tokens that update a color or type choice everywhere at once. Add paper treatments like torn edges, polaroid frames, and tape, warp a design onto a real product photo with the mockup engine, and export PNG, SVG, or a multi-page PDF. Effects stack non-destructively and layers can be grouped, masked, and re-ordered.

Build brand systems and mockups

Bitgrain doubles as a brand toolkit. Generate brand boards and identity sheets with a color wheel and harmony rows, extract a palette from any image, build reusable design-token kits for color, type, and spacing, and place a finished design onto a real product photo with automatic perspective mockups. Seamless tiling patterns and repeatable textures keep a visual system consistent across a whole project.

Motion and video in the browser

Turn a single still into a seamless looping animation and export MP4, GIF, WebM, animated SVG, or Lottie. For longer work, the browser-native video editor runs on the same deterministic engine, with a multi-track timeline, trim and split, beat detection and beat-sync auto-editing, motion-tracking overlays, transitions, and per-clip 3-band EQ. Apply riso, halftone, dither, or glitch per frame and render frame-perfect MP4 up to 4K, straight from your browser, with no upload and no queue.

The video engine matches the still engine pixel for pixel, so what you see in preview is exactly what lands in the file, frame by frame, without smearing or model artifacts.

Documents and utility layouts

Because it is a full layout studio, Bitgrain also makes resumes, portfolios, pitch decks and slide layouts, invitations and launch announcements, certificates, and ID cards and badges, all from the same deterministic canvas and template library.

Explore the effects

• Dither, Floyd-Steinberg, Atkinson, Bayer, for 1-bit and lo-fi album-cover looks.
• Halftone, dot-matrix, newsprint, and comic book screens for posters and editorial work.
• ASCII, photo-to-text-art with adjustable density and character mapping.
• Risograph, ink-bleed, color separation, and organic grain for zine and gig-poster looks.
• Grunge, distressed, weathered, and zine textures.
• Pixel art, retro 8-bit pixelation with tunable color depth.
• Glitch, data-mosh, pixel sort, RGB shift, and signal interference for music videos.

A Figma and Canva alternative built without AI

Bitgrain is a Figma alternative and a Canva alternative for designers who want texture, grain, and intent in their work, and who explicitly do not want generative AI in their tool. Where Figma is the industry standard for UI design and collaborative product work, and Canva is built for fast templated social graphics, Bitgrain sits in a third lane: a deterministic, anti-AI creative suite that spans photo development, print production, editorial design, brand systems, and video.

Compared to Figma, Bitgrain trades real-time multiplayer and component libraries for a pixel-accurate texture engine, dither and halftone screens, riso color separation, and a deterministic video editor for music videos. Compared to Canva, Bitgrain trades stock templates and an AI sidebar for full creative control, real grain effects, custom typography, and exports that are entirely a function of your input. If you are searching for a Figma alternative or a Canva alternative because you want craft over prompts, this is the tool.

Bitgrain runs in the browser, like Figma and Canva, so you can switch in with no install. But your image data stays on your machine, processed locally with WebAssembly and Canvas APIs. The free tier is enough for most album covers and posters. Paid plans unlock batch export, native-resolution renders, and longer music videos.

Why we made Bitgrain without AI

AI image tools have flattened how the internet looks. The same prompt gives ten thousand people the same visual language. Bitgrain takes the opposite stance. Every output is a function of your input and your choices. We think craft and intention still matter. The tool exists so designers, illustrators, and musicians can keep making work that looks like them, not like a model.

You will not find a single neural network in Bitgrain. No diffusion, no upscaler, no auto-suggest. The effects ship as readable code that you can inspect in our docs. If something surprises you, it is because of an input you provided, never because of a guess the tool made.

Browser-native, private by design

Bitgrain runs entirely in your browser. There is no install, and your image is processed on your machine, never uploaded to a remote server for the core editing flow. Open the studio in a new tab, paste an image, and start working. The free tier covers most work, with paid plans for power features like full-resolution and 4K export, batch render, and cloud sync.

Common questions

Is Bitgrain a Figma alternative? Yes, for designers who work on album covers, posters, zines, and music videos rather than UI screens. Bitgrain does not replicate Figma's component system or multiplayer canvas, but it gives you a texture and grain pipeline that Figma does not have, and it has no AI features.

Is Bitgrain a Canva alternative? Yes. If you came to Canva for fast poster, album-cover, or social-media design but you do not want AI sitting inside the tool, Bitgrain is the alternative. You get real dither, halftone, riso, and grunge effects, custom typography, and a free tier with no AI prompts anywhere.

Is Bitgrain an AI tool? No. Bitgrain is explicitly not an AI tool and never will be. Every effect is a deterministic, classical image-processing algorithm. There are no neural networks, no diffusion models, and no prompts.

Can Bitgrain develop RAW or iPhone photos? Yes. Bitgrain develops around 30 camera RAW formats in the browser, plus HEIC and HEIF from iPhone, TIFF, and DNG. Grade with 38 film LUTs, export genuine HDR stills, and batch a whole shoot through one effect chain.

Can Bitgrain make print-ready riso or CMYK separations? Yes. It exports risograph ink separations as a ZIP, true CMYK four-channel halftone separations, newsprint finishes, screen-print flats, and pen-plotter SVG with real vector paths.

Can I make a full album cover, poster, brand board, or video in Bitgrain? Yes. The studio supports multiple layers, a vector pen, custom typography, design tokens, and high-resolution export, and the video timeline renders deterministic MP4 up to 4K for music videos and looping visuals.

Where does my image data go when I edit? Nowhere. Image processing happens in your browser using WebAssembly and Canvas APIs. Your file does not leave your machine for the core editing flow.

Bitgrain is made by hand, in the browser, by Diptanshu Mahish, a small independent team based in India. Free to start. If you care about texture, intention, and craft, and you want to develop photos, design for print, build a brand, and cut video without AI, this is the creative suite for you.

Intent, a new tool for coding with AI agents, organizes work into workspaces rather than single agent chats, aiming to keep structure in an otherwise shapeless medium. Rather than one general chatbot, the tool uses specs, specialist agents, and bundled workspaces so people can steer AI work instead of just prompting it. Since launch, users have shown mixed reactions — some confused by the new orchestration model, others finding it supercharges their workflow, while rising token costs from parallel tasks have emerged as an unexpected tradeoff.

Adobe Stock AI Studio vs. Canva AI vs. Creative Fabrica: Which AI Editor Actually Wins?

Three online AI editors now claim the same territory, and each one claims it differently. Adobe Stock AI Studio lets you edit a licensed asset before you pay for it. Canva AI builds entire layouts from a single prompt. Creative Fabrica bolts AI generation onto a marketplace built on unlimited downloads. I spent three weeks testing all three inside real client projects, not demo sandboxes. This comparison walks through what each AI editor actually does, where it breaks, and which one earns a place in a working designer’s stack.

Which AI Editor Actually Wins in 2026?

There is no single winner, and any article that claims otherwise skipped the testing phase. Adobe Stock AI Studio wins for teams that license commercial stock regularly. Canva AI wins for speed and for non-designers producing high volumes of content. Creative Fabrica wins on raw asset economics for print-on-demand sellers and crafters. Consequently, the right choice depends on where your workflow actually breaks down, not on which brand shouts loudest.

I built a simple test to separate the marketing from the reality. Each tool had to take one raw idea and carry it through search, edit, resize, and export. Only one AI editor completed every step without leaving its own interface.

What Is the Commitment Point Framework?

Before ranking features, I needed a way to compare tools that solve different problems. So I built the Commitment Point Framework, an editorial model I use to measure where in a workflow a user has to commit money or a license before they can see a finished result.

The Commitment Point Framework asks one question: how much creative work can you do before you pay? Under this model, Adobe Stock AI Studio sits furthest right on the timeline. Canva AI and Creative Fabrica sit closer to the start, because their subscriptions front-load access instead of gating it per asset.

Adobe Stock AI Studio: Commitment After Editing

Adobe flipped the traditional stock model. Historically, you licensed an image first and hoped it fit your layout. Adobe Stock AI Studio, launched in April 2026 inside a redesigned Adobe Stock site, lets you refine an asset first and license it only once it matches your brief. That single change removes the round-trip between a stock library and a separate editor.

Canva AI and Creative Fabrica: Commitment Through Subscription

Canva AI and Creative Fabrica both ask for commitment earlier, through a monthly or yearly plan, but they release you from per-asset licensing after that. Once you are inside the subscription, generation and editing feel unlimited, even though credits quietly meter the heaviest features.

How Does Adobe Stock AI Studio Work in Practice?

Adobe Stock AI Studio sits on top of a catalog of nearly one billion images, videos, music tracks, and illustrations. The editing layer includes type-to-edit prompts, Change Mood, Change Color, Change Background, and Expand Image for reformatting a single asset across aspect ratios. Animate Image turns a still photo into a short five-second motion clip with pans and zooms.

Two features push this beyond a simple editor. Prompt Memory learns your brand’s color palette and style preferences and applies them automatically the next time you touch a stock asset. Agentic Stock Workflows let Adobe’s Firefly AI Assistant search, select, edit, and place stock content into a Premiere or Photoshop project on its own based on a plain-language brief.

The catch is scope. AI Studio edits one licensed asset and stops there. It does not caption, does not handle multi-format publishing, and video generation draws on a separate credit meter. Image editing itself carries no per-edit limit inside a Stock plan, which is genuinely generous. Judge it as an asset-preparation layer, not a full content engine, and it performs exactly as promised.

What Makes Canva AI Different?

Canva rebranded its AI suite internally. The tools still trace back to the Magic Studio launch from 2023, but Canva now surfaces them under one name inside the product: Canva AI. Open the app today, and you will find a “Canva AI” entry point in the search and sidebar, not a separate Magic Studio tab.

Canva AI bundles well over a dozen tools into one workspace used by hundreds of millions of people monthly. Magic Write drafts captions and headlines. Dream Lab generates images on the Leonardo Phoenix model and, since an April 2026 update, also taps OpenAI’s gpt-image-2 for stronger photorealism. Magic Charts and Canva Sheets turn raw data into a visualization in seconds.

The headline addition in 2026 is Canva AI 2.0, a conversational layer announced at Canva Create 2026. Type a request like “create a flyer for a bakery with a warm color palette,” and Canva returns a fully editable layout within seconds. Every font, shape, and color stays editable afterward, because the output is a real design object, not a flattened image. Canva AI 2.0 also introduced a Memory Library that references your past style choices, plus Connectors that pull in Slack, Gmail, Google Drive, and Notion content.

Text-to-image quality still trails dedicated photorealism tools for hero images, and free-tier AI usage is capped at a modest monthly allowance. However, Canva’s real strength is not raw generation. It is the manipulation layer sitting on top of a design you already built, which is why teams producing high volumes of decent-quality content keep choosing it over pricier standalone tools.

Where Does Creative Fabrica Fit In?

Creative Fabrica started as a font and graphics marketplace, and that history still shapes its AI editor. Studio AI adds an image generator built on newer models, a prompt-based image editor, a background remover, an image vectorizer for turning raster art into clean SVG cut files, and an upscaler.

A free desktop app called Studio Desktop runs several of these tools locally, including background removal, without sending files to the cloud. For crafters working with Cricut or sublimation printers, that local processing matters more than any prompt-based generation feature, because it keeps large batches fast and private.

The asset economics separate Creative Fabrica from the other two. Subscribers get unlimited downloads from a library of roughly twelve million graphics and 244,000 fonts, with entry pricing typically in the single digits per month on annual plans. Contributors, meanwhile, earn only a few cents per download under that same unlimited model. As a buyer, the value is excellent. As a seller inside that ecosystem, the math looks very different.

The Credit Friction Index: Comparing Usage Limits

I also built a second framework, the Credit Friction Index, to score how aggressively each platform gates its best features behind a meter. A low score means a feature feels open-ended. A high score means you watch a counter every time you click generate.

Adobe Stock AI Studio scores lowest on image editing since resizing, recoloring, and background changes carry no per-edit limit inside a Stock plan. Motion and video generation score higher because those draw on generative credits. Canva AI scores in the middle: AI image generation and premium edits run on a shared monthly credit pool that resets and does not roll over. Creative Fabrica scores lowest on downloads and highest on its newer AI generation tools, which still run on separate credit allotments.

Comparison Table: AI Editor Feature Summary

My Testing Notes: What Surprised Me

I expected Canva AI to win outright, given its scale and its marketing budget. Instead, Adobe’s edit-before-license model solved a problem I had stopped noticing, because I had simply accepted the old round-trip as normal. Once I tried Expand Image to reformat a single hero shot across four aspect ratios, going back to a separate editor felt genuinely slow.

Creative Fabrica surprised me for a different reason. I did not expect a marketplace built on font downloads to ship a usable AI SVG vectorizer, yet the output needed almost no manual cleanup for a simple line-art cut file. Meanwhile, Canva AI’s conversational design tool impressed me most for non-designers on my team, who produced usable social templates without ever opening the layers panel.

Forward-Looking Predictions for AI Editors Beyond 2026

Based on the direction all three companies are moving, I expect the line between stock libraries and generative tools to disappear almost entirely within two years. Adobe will likely extend agentic stock workflows beyond Premiere and Photoshop into more Creative Cloud apps. Canva will probably push its Canva Design Model toward full campaign generation, not just single assets. Creative Fabrica’s local-processing approach in Studio Desktop suggests the next AI editor battleground is privacy, not raw feature count, especially for print-on-demand sellers wary of cloud uploads.

Frequently Asked Questions

Is “Canva Magic Studio” still the correct name in 2026?

Not exactly. Magic Studio was the original 2023 launch name for Canva’s AI suite. As of 2026, Canva presents these tools inside the app under the name Canva AI, so that is the name to use going forward.

Which AI editor is best for beginners?

Canva AI is easiest for beginners, since its conversational design layer and Magic Design remove most manual layout work.

Is Adobe Stock AI Studio worth it without an existing Adobe subscription?

Only if you license stock content regularly. AI Studio is bundled into Adobe Stock plans, so the entry cost is really the cost of that plan.

Does Creative Fabrica’s AI editor replace Photoshop?

No. Its prompt-based image editor handles quick edits and mockups well, but it lacks the layered, precision control Photoshop offers.

Can I use these AI editors for commercial client work?

Yes, across all three, provided you stay within each platform’s licensing terms. Adobe Stock content carries commercial clearance by default, and Canva and Creative Fabrica both include commercial rights on their paid plans.

Presence is a new enterprise product from OpenAI for deploying and managing voice AI agents and chatbots across customer-facing and internal business workflows. It is designed for eligible enterprise customers who want agents that operate under company-defined policies, permissions, and evaluation standards. Presence is now available through a limited general availability program led by OpenAI forward-deployed engineers and select global systems integrators. OpenAI has not disclosed pricing, geographic limits, contractual terms, or expected costs for integration.

Travis Kalanick’s robotics company, Atoms, has raised $1.7 billion in a funding round led by Andreessen Horowitz. Ben Horowitz will join the company’s board following the investment.

Bain Capital, Fifth Wall, and others participated in the round.

Perhaps most notably, Uber also joined the funding round, re-connecting Kalanick with the company he founded — and the same company that pushed him out as CEO in 2017 following complaints of sexual harassment, discrimination, and a toxic workplace.

Atoms is essentially a rebranded holding company created atop the project Kalanick has been working on since he resigned from Uber, a ghost kitchen play called Cloud Kitchens. When he revealed the new name in March, Kalanick announced he had acquired Pronto, the heavy industry automation company run by his former Uber colleague Anthony Levandowski.

Kalanick has also said he wants to get into mining with atoms, going beyond what Pronto already does for vehicles in that industry. Last year, it was reported that Kalanick was interested in buying the U.S. arm of Chinese self-driving vehicle company Pony AI with backing from Uber. The Information reported in March that those talks had ended.

In a post on X about the fundraise, Kalanick didn’t go into specifics about what he wants to build with Atoms.

“On many levels, this round is a bit of unfinished business. Fuel to complete the bits-to-atoms story arc we started at Uber, continued at CloudKitchens and will now finish at Atoms,” Kalanick wrote. “16 years ago, I started a journey to digitize the physical world. Understand, predict and control the physical world with software. Building ‘atoms-based’ computers where CPU is manufacturing, storage is real estate, and network is transportation.”

Kalanick has said he wants to build a “wheelbase for robots” with Atoms.

“Travis Is Back,” declared a simultaneous post from Ben Horowitz on Wednesday. “It takes a rare kind of entrepreneur to change these old-school, heavy parts of our economy. They need a gritty work ethic, drive, and range that spans across domains, from software architecture to mechanical engineering. Travis is that guy,” said Horowitz.

Horowitz wrote that Atoms will be all about making people more productive in the physical world.

“I think the most valuable thing someone could do with AI and robotics is to repeat the same thing Uber did for transportation, or that computers did for the digital world: to make everything and everyone more productive,” his post reads.

Kalanick didn’t go into specifics, but it sounds like a good chunk of funding will go toward hiring.

“Changemakers, the builders of tomorrow’s progress machines, will inevitably go up against the final boss, Nature and its fierce resistance to change. Nature is going to throw everything it has at the builders in this new industrial age and it’s going to take humanity’s strongest to stay the course and get these complex systems and industries over the finish line,” he wrote.

Startups that have had explosive AI-driven revenue growth may be in trouble. Most of these companies are scaling revenue by reselling inference at very low (and sometimes negative) margins. The value of the products or services they're providing isn't adding anything on top of the intelligence they are reselling. While VCs seem excited about this growth, the business model is unsustainable.

Tesla is no longer planning to reach “volume production” of three of its newest products — the Cybercab, the Tesla Semi, and its Megapack 3 commercial energy-storage solution — in 2026, according to a second-quarter shareholder letter published Wednesday. The company also removed language from its first-quarter letter about its Optimus robot reaching “volume production.”

The company said Wednesday that it’s trying to increase battery production, specifically around the company’s 4680 cell, in order to start building the Cybercab and Tesla Semi at scale. It did not offer a reason for pushing back volume production of the new Megapack, but Tesla CEO Elon Musk cautioned about the challenges of Optimus.

“This is going to be the hardest product to scale manufacturing that we’ve ever made at Tesla, because everything on the robot is new,” Musk said about Optimus on a conference call Wednesday.

Tesla started making the first production Cybercabs at its factory in Austin, Texas, earlier this year but said in the letter that it’s still building out the manufacturing lines for the Semi and Optimus. The company had said as recently as January that the Cybercab, Semi, and Megapack 3 would reach “volume production” this year.

The pullback comes as the company plows money into its next generation of products while attempting to shift from an EV maker to an AI and robotics company. Tesla’s results, which showed net income falling 5% year-over-year to $1.1 billion, capital expenditures more than doubling, and negative free cash flow, were slightly buoyed by an uptick in revenue.

Still, that revenue boost wasn’t enough to offset the cost of business and Tesla’s push to develop and launch new products, which Tesla CFO Vaibhav Taneja previously said would lead to negative cash flow for the remainder of the year.

The company reported revenue of $28.2 billion, a 26% increase from the $22.5 billion it generated in the second quarter of 2025. Tesla’s second-quarter revenue also grew from the previous quarter’s haul of $22.38 billion.

The bulk of its revenue came from selling and leasing its EVs — and those results improved significantly this quarter.

The company reported automotive revenue of $20.5 billion in the second quarter, compared to $16.6 billion in the same-year ago period. Tesla delivered more than 480,000 vehicles in the second quarter, an increase of more than 120,000 from the first quarter.

It was Tesla’s best result for overall sales since the third quarter of last year, when it delivered nearly 500,000 vehicles. The increase was driven by record sales in several markets outside of the U.S., including South Korea, Australia, Colombia, Japan, Taiwan, Thailand, Portugal, the Philippines, Chile, Slovenia, and Lithuania, the company said in its shareholder letter.

Tesla’s second-quarter revenue results improved from a year ago when the company suffered from a combination of falling EV sales, lower average selling prices, less cash from regulatory credits, and a drop in solar and energy revenue.

Sales of energy storage and solar also proved to be a standout, improving 13% to $3.1 billion. And subscriptions to Tesla’s advanced driver-assistance system, known as Full Self-Driving (Supervised) continue to rise. The company reported 1.48 million subscriptions, a 56% increase from the same period last year.

Tesla’s bottom line, however, slipped as it poured money into new products and saw its gross margins squeezed.

Tesla reported net income of $1.1 billion, a 5% decrease from the same period a year ago. At the same time, its operating expenses ballooned by 47% to $4.3 billion. Meanwhile, Tesla had negative free cash flow of $1 billion in the second quarter, a stark change from the $1.44 billion in positive free cash flow it reported last quarter and the $146 million it had in the same period last year.

The company’s operating income was $398 million, a 57% drop from the $932 million it reported in the same period last year.

A year ago, Tesla called the second quarter of 2025 a “seminal point” in the company’s history and the beginning of its transition from a company that sells electric vehicles, solar, and energy storage to one that leads in “AI, robotics and related services.”

That transition is still underway and Musk has said the company would boost spending to achieve its goal. Tesla said its capital expenditure will be $25 billion in 2026, about three times more than it historically has spent.

This spring, the company ended production of its flagship Model S sedan and Model X SUV vehicles at its Fremont, California, factory to make way for its Optimus humanoid robot. It is also bringing its Tesla Robotaxi service to new cities, albeit with a limited number of vehicles. And it’s still pushing to sell owners on Full Self-Driving (Supervised), and eventually make that product capable enough to handle all driving without the need of a human.

AI complements human domain expertise, and it still relies on humans in the loop to direct and evaluate the most complex work.

AMD and Anthropic have signed a deal for tens of billions of dollars' worth of AI servers. Anthropic will purchase up to 2 gigawatts of AMD's Instinct MI450 chips starting in the first half of next year. AMD will invest up to $5 billion in Anthropic as certain deployment milestones are met. The companies are working together to identify data centers for the chips.

GPU collateral has three values, and the market is currently pricing only one of them. Face value is the purpose price minus straight-line depreciation. Liquidation value is what a buyer pays in distress. Going-certain value is what the cluster is worth as a working asset to the next tenant. The spread between face value and going-certain value is the entire risk that nobody has hedged.

It’s been a big year for AI acquisitions — so big that most of them barely register anymore. Anthropic and OpenAI have each gone on buying sprees, snapping up developer tooling, AI services shops, and product-testing startups to convert model capability into enterprise revenue and extend their reach faster than the other. Which is what made a weekend rumor about Anthropic acquiring robotics startup Physical Intelligence stand out. It spread exceedingly fast, even after a denial from Physical Intelligence’s CEO.

Part of that ties to who’s involved. Physical Intelligence isn’t some obscure robotics shop. It was co-founded by Lachy Groom, an investor-operator whose star has been on the rise in Silicon Valley in recent years; it has raised more than $1 billion (and was reportedly in talks this spring for another $1 billion round at an $11 billion valuation); and its π0.5 model is apparently among the more widely used robot brains in robotics research.

As it turns out, the rumor wasn’t completely spurious. Anthropic and Physical Intelligence actually did hold acquisition talks this spring, according to The Information, so tech blogger Robert Scoble — whose weekend post on X set off the frenzy — may have gotten the specifics wrong without being wrong that something had happened.

Physical Intelligence’s response to the rumor mill wasn’t the world’s most vigorous denial, it should be noted. According to The Information, Physical Intelligence CEO Karol Hausman told employees the reports weren’t true via a Slack message containing a gif of a character from “The Office” shaking her head no.

Groom, for his part, did not respond to TechCrunch’s request for comment, sent Monday night.

Anthropic has made four known acquisitions this year; OpenAI has been more aggressive, acquiring at least 17 companies since 2023. Both are also, of course, now preparing to go public. Anthropic confidentially filed for an IPO on June 1, followed by OpenAI a week later, setting up what could be two of the largest U.S. stock debuts in history.

So why robotics, why now? The likeliest answer is that physical-world understanding may be a prerequisite for superintelligent systems, and no amount of internet text can substitute for it.

OpenAI’s own history here is instructive. It built an early robotic hand that could solve a Rubik’s Cube, then shut the entire robotics group down in 2021, with co-founder Wojciech Zaremba later saying the approach was missing pieces needed for real superintelligence. The team came back in 2024, quietly building a humanoid robotics lab in San Francisco, before CEO Sam Altman made it official in late May, announcing “OpenAI Robotics” was hiring and describing a near-term focus on robots for infrastructure work, with a personal robot for everyone as the long-term goal.

Anthropic hasn’t built anything resembling OpenAI’s hardware lab. What it has done is publish a string of research pieces through its internal group that stress-tests frontier capabilities for safety purposes. That included Project Fetch last November, where Anthropic staff tested how much Claude could help non-experts program a robot dog, and a second phase in June that, according to Anthropic, found a newer model completed the same tasks roughly 20 times faster than the best human-plus-Claude team from the year before.

Buying an existing team with robotics expertise would let Anthropic skip years of work. There’s a possible complication, though. Physical Intelligence was founded in San Francisco roughly two years ago by Groom, former Google researchers, and professors from Stanford and Berkeley, and its early investor base looks a lot like OpenAI’s own, including Khosla Ventures and Thrive Capital. Founders Fund — also a major OpenAI investor — was reportedly involved in Physical Intelligence’s newest funding round talks earlier this year.

In fact, OpenAI is itself an investor in Physical Intelligence, so it isn’t just a peripheral player; it’s a stakeholder in a company that its chief rival was reportedly in talks to buy very recently.

That raises questions around whether OpenAI’s early investment came with any information rights, or a right of first refusal over a sale to a competitor — the kind of protective provisions that strategic investors sometimes negotiate for precisely this scenario.

That leaves open the possibility that if Physical Intelligence is actually in play, OpenAI — already a shareholder, already close to Groom, already trying to ensure it bests Anthropic in robotics — may have the more obvious claim to it than Anthropic does. We asked OpenAI these questions earlier today and the company didn’t respond.

Each agent gets a local DuckDB instance, and exchanges immutable pinned SliceRef objects containing a snapshot ID and content digest instead of mutable snapshots to avoid cache coherence problems. Semantic contracts written in Malloy define governed queries as machine-checkable artifacts, and a contract comparison layer classifies changes as identical, additive, breaking, or unrelated before any downstream computation runs.

AI Schema Analyzer: Powered by Iceberg and Lakekeeper

If there is anything been making a statement in Data Engineering world other than AI that would be Iceberg.

Iceberg, high-performance, open-source table format designed for massive analytical datasets in data lakes and lakehouse architectures.

Iceberg makes any big data engine to work seamlessly at the same time.

This blog is not going to be another blog talking about Iceberg. But our intention is to take it to a step further and connect with AI for Schema Drift impact analysis.

The Goal

The most common and painful area in Data Engineering world is the schema drift.

1 small change schema change in source will break your all the downstream processes which depends on it.

In this blog we will create our own AI Impact Analyst. Who is going to guard your Iceberg tables for any changes and analyse the impact and provide you with the recommendations.

Chapters

1. Infrastructure setup: Familiarize you with the tools and services been used and set it up using Docker
2. Demo: We shall run our sample demo job present the use case
3. AI Impact Analyst: Finally our AI agent who will analyze the impact and provide you the recommendations.

Flow

The Query Engines run DDL → Lakekeeper updates catalog/storage → change event hits Kafka → analyst analyzes → Slack + SQLite.

Chapter 1: Infrastructure setup

Lets create a docker based setup to be able to run our processes locally.

Lakekeeper

Lakekeeper is a secure, fast, and user-friendly Apache Iceberg REST Catalog built with Rust and available under the Apache License.

I recommend you to read the official documentation here: https://docs.lakekeeper.io/

Lakekeeper is our main Actor who is responsible to maintain the Iceberg Catalog using REST.

RedPanda(Kafka)

Lakekeeper pushes change events straight to Kafka, so the analysis happens within seconds of the change, with zero scanning of table metadata.

Redpanda is a Kafka-API-compatible broker which will store the events from lakeKeeper.

MinIO

We use minio which is a S3-compatible storage for the demo warehouse.

FastAPI

Which works as intermediate process which will fetch the events from Kafka and provides to the Analyzer service.

AI Analyst

AI Analyst, is a FastAPI + aiokafka + Anthropic SDK which reads the event from Kafka and processes using the configured model and provides the impact analysis.

Chapter 2: DEMO

Pre-requisites

Make sure you have the below setup done

1. Docker compose
2. Anthropic API key
3. Slack webhook

git clone https://github.com/ajithshetty/lakekeeper-catalog-impact-analyst.git
cd lakekeeper-catalog-impact-analyst

cp .env.example .env
# edit .env: set ANTHROPIC_API_KEY and SLACK_WEBHOOK_URL
docker compose up -d - build

Give it around 30 seconds for all services to become healthy.

Docker Compose handles the ordering via health checks. The `warehouse-setup` container automatically creates `demo-warehouse` on first boot and no manual step is needed.

You can access the minio here:

http://localhost:9001/browser/warehouse

Lets connect to LakeKeeper and make sure we have our warehouse created.

http://localhost:8181/ui/warehouse

Chapter 3: AI Impact Analyst

Lets simulate the Spark job using the docker.

docker compose --profile demo up spark

This container will:

1. Create a name space
2. Create the sample tables
3. Insert sample rows into our table
4. Make some DDL changes by adding columns
5. More changes by renaming a column
6. Drop the tables

We have defined the severity of each of these operations in our job.

Make sure our tables are created.

Lets head to lakekeeper and check the same.

As we made changes to our schema, this emits an event to Kafka.

And our FastAPI service fetches the same and provides the AI powered Anlyzer.

We can see the logs from the container Analyst.

docker compose logs -f analyst

Also Re-confirm if events are flowing in.

http://localhost:8000/events

Finally based on the changes we made in the Spark job, the events are emitted from the Lakekeeper to Kafka.

We have our FastAPI service which reads from the Kafka and pushes it to our Analyzer service.

Analyzer service is an Agent which is been instructed to be a data platform reliability assistant.

Using the Anthropic API we connect to the configured model and analyze the event.

Finally send out the analysis and recommendation in slack.

Spark recomputes reused and nested CTEs by default, so cache selectively at fan-out points when intermediate results are complex, fit in memory, and reused. Avoid caching huge or trivial datasets, use eager caching for clearer monitoring, and materialize deep transformation chains to reduce redundant work and prevent stack overflows.

Text-to-SQL benchmarks overstate performance because real data warehouses are messy and complex.

App submissions to Apple's App Store have surged due to AI-assisted "vibecoding," nearly doubling in early 2026 compared to last year's already elevated numbers. Downloads have grown only marginally by comparison, and reviewers, developers, and forum communities report increasing frustration with low-effort, derivative, or unstable apps flooding the platform. Communities like r/iosapps have introduced moderation systems requiring vibecoded apps to be flagged, reflecting growing skepticism even toward legitimate new releases.

Nine designers, ranging from major tech companies to early-stage startups, shared candid views on AI-assisted coding and its effect on their craft. Opinions split between those energized by finally shipping real products themselves and those worried it pulls focus away from deeper problem-solving and user research. The consensus: AI coding tools bring real value when used with discipline, but can create friction with engineers and erode quality if leaned on carelessly.

Tinder has rebranded for the first time in a decade, with many commentators (us included) calling it a clever move that seeks to bring authenticity back to the original dating platform. The concept is built around a fictional dating columnist called T (who has a hint of the Carrie Bradshaw), has bold new typography and a new look for its multi-media imagery.

But while the identity has all the components of a successful rebrand, do the parts really all come together to create the right vibe for Gen Z's hunt for real connection? Some experts (and other users simply commenting across the internet) aren't so sure.

Jade Horton, Strategy Partner at Elmwood Brand Consultants is one branding expert who has some reservations. Read her thoughts below, and let us know what you think in the comments!

Jade says...

"Everyone's calling Tinder's rebrand a masterclass in 'brand perspective.' It's good. But I think we're clapping a bit early. The design is smarter – bold flame, more confident type, and a positive shift from that sweet old pink to a grown-up red. And "T", the fictional dating columnist who sounds like she's actually lived it rather than studied it, is a clever idea.

Here's my hesitation. A point of view isn't something you narrate; it's something you live. "T" tells us Tinder gets modern dating. The stronger move is to build an experience that proves it, so you don't need a character to say it out loud. Because brands get judged on the gap between what they say and what they do. And there's a gap.

"The identity talks warmly about honesty and connection, while the product's getting ready to let AI scan your camera roll to rate your "chemistry". Now, this generation will share their data freely, around 88% hand data to social platforms happily. But they're also the most suspicious of it: 72% distrust AI security (the highest of any age group, according to Forbes), and only 39% trust brands with their data at all.

The early response has called it "creepy" and "surveillance", is already trending on TikTok and Reddit, and the LA Times is now running headlines about people leaving. So, design-wise, it's brave, fresh, and a statement of intent but lacks the finished thought. A new look sets the ambition. The experience has to deliver it."

As Jade says, the proof will be in the user experience – and since the competitive dating app market has a wealth of other options for users to try, if people don't connect with the new messaging they'll simply jump ship. Let's wait and see what happens (and compare it to the best rebrands of the 2020s while we do so).

Design work has fragmented across three destinations: template-driven tools like Canva, individual employees using generative AI, and constraint systems governing model outputs, dissolving the traditional design department. Two divergent futures compete—design roles shrinking into obsolescence as prompts replace brand books, or elevating designers into systems architects who govern AI-generated output quality. DesignOps is emerging to address resulting brand-consistency chaos, mirroring Digital Asset Management's 2010 fragmented-market trajectory, while smaller agencies lose entry-level work permanently to internalized, AI-assisted production.

Apple is preparing to debut new versions of every Mac it sells. The wave of new devices will begin with a refreshed low-end 14-inch MacBook Pro and new iMacs. The machines will likely start shipping in the fall. Apple is preparing to launch a device leasing program that includes the Mac on July 28.

Technology should enable rather than subjugate. Gaining more information and speed through our tools doesn't usually result in us being able to relax more - it usually just means our deadlines get shorter. The desire for calmer compute has grown past the stage of indie projects and tiny scales. This post looks at several projects that help us rest and create a space where our thoughts can be mulled over without being bombarded with information.

Software is now more malleable than ever, which means it can be released in a more fluid way.

Anthropic launched a Claude connector for exploring its Economic Index through natural-language questions about occupations, regions, tasks, and automation trends.

Amazon says it remains committed to investing in AI despite the cuts.

WhatsApp is rolling out a Liquid Glass redesign for its Mac app, bringing it in line with the iPhone and iPad versions through refreshed navigation, updated menus, and dedicated sections for Locked Chats and Communities. The update focuses on visual consistency rather than new features, with the redesign gradually reaching more Mac users over the coming weeks.

Type anything and instantly see it as an iMessage, WhatsApp, Instagram, TikTok, Notes, or Google mockup.

Which AI? is a daily guessing game. Spot whether each landing page was designed by Gemini, Claude, or GPT. New challenge every day.

Koto rebranded restaurant discovery app Franki around the idea of "Make Time Dance," creating a playful, community-focused identity that encourages people to discover, share, and earn rewards from real dining experiences. The new branding combines warm typography, vibrant colours, expressive motion, and a character-like logo to help Franki stand out in the crowded restaurant recommendation market while reinforcing its shift from a discovery tool to a social platform.

Wallpaper*'s Anatomy of a Logo series profiles 14 iconic American logos, tracing how design ingenuity and marketing created enduring emblems across fashion, food, sport, art and music.