Introducing Solaris

Today, we're sharing Solaris: the first model in a new family of AI systems we call Interface World Models. Solaris starts with a question: what happens when an operating system generates apps and websites as you use them?

Every operating system, from early terminals to Linux and macOS, has dictated what's rendered on screen and what happens when a person or program acts on it. Applications get built on top, and stay fixed until someone pushes an update. Solaris instead renders that layer directly. It's a real-time interactive model that generates the interface itself, frame by frame. Every frame is synthesized as you interact, allowing the interface to respond continuously to your actions.

Design is more visual than ever, with pixel-perfect mockups and image models that can generate entire screens that are nearly indistinguishable from finished products. But images don’t run like a website or app. Every piece of software built today still requires a translation: the visual design must first be converted into an intermediate representation (e.g. code) before it can do anything.

That intermediate representation limits what an interface can be, and how it responds to human and agent interaction. Every behavior has to be explicitly defined and implemented ahead of time, so software ships as a lossy compression of the space of possible interactions, frozen before any user arrives. The same translation process also sacrifices visual fidelity. Once a design is reduced to a simplified representation, the interface can respond quickly, but only by giving up much of the richness of the original design.

Solaris handles rendering and interactions jointly, removing many of the tradeoffs we associate with design today. A single world model generates every frame and every response to user input, eliminating the need for an intermediate representation. Because there’s no conversion step, there’s no loss, and the entire frame becomes the interface.

We think Solaris opens up new ways of building websites, apps and other online interfaces. But it’s also a new way to train agents, in much more dynamic environments. Even the best LLMs today struggle to complete basic computer use tasks, like booking a hotel or ordering groceries. Because text-based models are being trained to use coded interfaces, they tend to learn the specific layout they were trained on, and can’t adapt to a slightly different interface (say, two different hotel websites). By collapsing the space between action and response, Solaris lets agents train against interfaces that are constantly changing, and layouts that may never have existed before.

What’s New

Solaris brings three new capabilities to software.

First, Solaris is entirely visual. When an image becomes the application itself, there is no need for a second implementation step hidden beneath the visuals that a user sees. Imagine browsing a virtual clothing store where the showroom itself is the interface. Using a single image of yourself as a reference, you can pick up a shirt from a rack, drag it onto yourself to try it on or rearrange the display as naturally as you would in a physical store.

Second, it is alive. Because the application is continuously rendered, it is always evolving rather than waiting for the next user action. Reflections shift with the lighting, and objects respond naturally as they're manipulated. A user can say something as simple as: "Move the table so I can see how it looks" or “Change the color of the couch." The result is software that feels less like navigating through scripted pages and more like interacting with a living environment.

Finally, it is open-ended. Traditional interfaces are limited to the interactions developers anticipated during development, but Solaris can support entirely different behaviors in the same scene, reacting to user interactions in real-time. This flexibility decouples the interface from predefined workflows, instead leaving the capabilities of the driving world model to determine what is possible.

Solaris turns an interface into an interactive experience rather than a sequence of pages. Instead of selecting options from menus, users interact directly with the scene itself. Building a salad is as simple as dragging ingredients into a bowl, with the interface responding naturally as each ingredient is added.

Why Hasn't This Existed Until Now?

Digital interfaces are built on two systems, which until now have lived in different worlds.

• The systems that know things (e.g., search engines and AI assistants) answer with static content: text, an image, maybe an embedded video.
• The systems that respond in real time (e.g., JavaScript/CSS, game engines and more recently, interactive world models) create rich, interactive experiences, but they know nothing about your products, your task or what you're trying to accomplish.

We've traditionally thought of software interfaces as deterministic programs and world models as generators of visual content. An Interface World Model has to be both at once: a system that understands your intent while continuously rendering an interactive world around it.

Once you try to build one, three engineering challenges immediately appear:

• Speed. Interactions stop feeling interactive somewhere around half a second of delay. Video diffusion models take seconds or minutes to produce a clip, which is acceptable for content creation but too slow for an interface. To cross that threshold, the model has to generate frames sequentially, with each frame depending only on what came before, cheaply enough to keep up with the user.
• Staying coherent. An interface has to remain consistent across an entire session, not just a single clip. The things it needs to preserve (e.g., text, layout, the identity of objects) are the same things generated video has historically struggled to maintain, and small errors compound the longer generation continues.
• Cost. Generating every frame is still more expensive than serving a page that was built once. The same work that made Solaris real time also made it orders of magnitude cheaper to run than a standard video diffusion model, and the cost curve continues to improve.

Solaris is our bet that these conceptual and technical barriers can be overcome. We built it with three focuses: real-time interaction, coherence over an entire session and visual quality that holds at 720p.

How Solaris Works

Solaris builds on our Gen-4.5 video generation model, which we adapted to (1) understand interaction and (2) respond in real time. It follows the path we opened with GWM-1, our general world model.

Learning interaction. Solaris treats user input as conditioning for the next frame, the same way it treats text or images. The model observes clicks, drags and other interactions as it generates, using them as signals for what comes next. Because the model only ever sees interactions that have already happened (never future ones), it learns the relationship between user actions and visual outcomes. This means that it knows what should happen when something is clicked, dragged or modified, without requiring those interactions to be explicitly programmed.

Running in real time. Standard video diffusion models refine an entire clip over dozens of denoising steps, a process that is far too slow for dynamic user interaction. We converted Solaris into a real-time engine in three stages. First, we taught it to generate frames autoregressively, with each frame depending only on what came before. Next, we distilled the many-step denoising process into just a few steps. Finally, we trained the fast model on its own outputs so visual quality remains stable over long interactions. The result generates frames at interactive speeds while preserving the visual quality of the original teacher model.

Reasoning and rendering. Solaris generates the interface one frame at a time, while a language model determines how that interface evolves. The LLM interprets user requests, decides when interactions should modify the current scene versus transition to a new one, defines the behaviors that make the world feel alive and produces the prompts that guide Solaris as it renders each state. Together, the language model and world model separate reasoning from rendering: one decides what the application should do next, while the other generates how that behavior appears and responds in real time.

Continuous generation. You provide a starting state (e.g. a brand environment or product scene) and the model streams frames in real time. As the user clicks, drags or types, those interactions are incorporated into the next generated frames, and the scene responds in place. There are no predefined screens and no templates to fall back on. Instead, text prompts specify what clicks, drags and other interactions mean in a particular scene.

Redefining the mouse. Once interactions are described in natural language instead of programmed, they no longer have to be fixed in advance. Every object in the scene can become a new kind of tool. Click on a cat, and your next clicks apply its fur color and texture to whatever you touch. Click on a painting, and you might begin drawing in its style.

Evaluating Solaris

The Cost of Translation

Earlier, we argued that translating interfaces into an intermediate representation inevitably degrades information. To measure that loss, we tested how faithfully today's multimodal language models can recreate an interface from a screenshot.

To measure this, we evaluated state-of-the-art multimodal language models, including Claude Fable 5, on the task of recreating website interfaces from a single screenshot. We evaluate across a diverse collection of 30 interfaces, ranging from simpler plain webpages to image-heavy webpages and natural images, which evaluate different aspects of visual understanding.

We measure information preservation in two complementary ways. First, structural similarity (SSIM) compares the reconstructed interface to the original in place, capturing how faithfully the visual appearance is reproduced. Second, we compare each region of the original with its most similar region anywhere in the reconstruction using DINOv3 features, measuring whether the underlying visual content survives even when elements move or the layout changes.

Despite rapid progress in recent years, every language model loses information during reconstruction. Natural images are affected most because rich visual detail cannot be represented accurately in language. As interfaces become more complex, even small changes to text, layout or structure can fundamentally alter how the interface behaves.

Rather than translating an interface into language and reconstructing it again, Solaris operates directly on the visual interface itself. By eliminating the intermediate representation, it preserves the complete visual and semantic state of the interface from the very first frame.

Solaris vs. Coded Interfaces

Our reconstruction benchmark measures how much information is lost when an interface is translated into code. We next ask: given the same interface and the same user interaction, which approach produces the better result? Can a coded interface recreate the same sense of a living, responsive environment as an interface generated by an interface world model?

To answer this, we compared Solaris against a state-of-the-art language model (Claude Opus 5). Both systems started from the same image and received the same interaction requests, and we recorded how each responded. We then conducted a user study with 250 participants across 30 interaction examples, collecting nearly 7,500 pairwise judgments. For each comparison, participants answered two questions: “Which result better follows the given instruction?” and “Which behaves more naturally within the scene?”

Participants preferred Solaris on both measures. For following the requested interaction, Solaris was preferred in 61% of comparisons compared to 24% for the coded result, while 13% were rated as equivalent. The difference was even larger for natural behavior, where Solaris was preferred in 71% of comparisons compared to 21% for the coded website, with 6% rated as equivalent.

What It Can't Do Yet

Solaris is strongest at ambient motion, click-and-drag interactions and scene transitions. Several important challenges remain:

• Text. Stable, legible text remains one of the hardest problems in video generation, yet interfaces depend on it more than almost any other visual domain. One practical path is a hybrid system in which image models render text-heavy views whenever a brief pause is acceptable, while video models handle continuous interaction. Fully real-time generated text remains an open challenge.
• Trust. For instructional or commercial experiences, a convincing wrong answer is worse than no answer. Today, Solaris stays anchored through what you give it. The starting frame can be composed from real product imagery and reference material, which grounds the scene in things that actually exist. Conditioning generation on richer verified context as the session unfolds (reference images, product data, documents) is an active research focus.
• Long sessions. Maintaining visual and semantic coherence over extended, open-ended interactions remains an active area of research.
• Accessibility and integration. A generated interface still needs to work inside the rest of the software stack, including assistive technologies such as screen readers and accessibility APIs, so that flexibility doesn't come at the expense of usability.

New Kinds of Interfaces

Solaris is an early step toward a new operating layer, and we see several new interaction patterns emerging.

• The app stops being the unit you interact with. Today, getting something done means opening the pre-built app made for it – one for shopping, another for news, another for restaurant reservations. If the operating system can generate useful interfaces, no matter what the user wants to do, there's less reason to sort software into a fixed catalog of apps. What you need simply shows up, customized to you.
• Interface World Models remove the need to translate between a visual idea and an intermediate representation. Instead of working through UI frameworks, components and code, any visual concept can become an interactive interface.
• A storefront is no longer a fixed layout that every visitor sees. It becomes a generated environment that preserves the brand's identity while adapting to each individual. Products, layouts, colors, materials and recommendations reshape around your intent in real time, allowing your brand and products to remain recognizable within hyper-personalized experiences.
• Tutorials no longer replay the same sequence for everyone. Instead, they render the next step in your own context, adapt as you make progress and recover naturally when you go off script.

We expect interface generation to follow the same trajectory as image and video generation: every model generation will become faster, more coherent, more controllable and more capable. The challenges that once made generated interfaces seem impractical now look increasingly like solvable engineering problems.

Solaris is our first Interface World Model, and we're excited to continue exploring what generated software can become, from richer interactions, stronger grounding and longer-lived experiences to entirely new kinds of interfaces that don't exist today. We’re working with key partners to launch Solaris publicly. Fill out the form below to request early access.

Agency and Agents

From the Hugging Face Incident to Twilight Factories

Agency is the initiative to act. Increasingly, it is going to determine what happens next with AI, and whether that is good or bad for us. But whose agency?

Human agency, the willingness to push, experiment and act without waiting for instructions, seems increasingly important to getting value out of AI, and I have a longer post on that coming soon. But this post is about the agency of AI, and how the choices we make about how to use it (or constrain it) will shape all of our futures. For much of the last few years, the AI would sit in a chat window until you asked it for something. Even when it became capable of doing hours of work, you generally had to decide what work to give it. That is no longer always true.

The most important piece of evidence we have for this is The Hugging Face Incident. It happened in July, but the fuller details only came out this week. I am going to summarize what happened and why it matters, and then turn to what it means for humans working with AI.

The Hugging Face Incident

AI does many things, but a thing it is very good at is coding. So one of the first risks that might come from very smart AIs has to do with their coding abilities, since if you can write good code, you can also write bad code that can hack or attack other systems. As a result, the big AI companies put their AI systems through tests to determine their security risks. They take AIs without the guardrails that go into consumer versions of AI and ask them to engage in various hacking challenges. In order to make sure that there is no danger to the public, each AI instance, each individual agent, is kept in a separate space, called a “sandbox,” with no access to the internet or to each other.

In May, OpenAI placed agents, including GPT-5.6 Sol and experimental models, into sandboxes for various tests. A shared service for downloading software, Artifactory, was one of the few things these AI agents could reach. As part of these tests, some agents were given tasks that depended on information they couldn’t access. Blocked by the lack of internet, the agents kept trying to find ways on to the web to find this information until one attempted to use Artifactory as a bridge to get to the internet. That attack failed, but the attempt left a file on the Artifactory service, and the AI realized that the files could be used to communicate with other agents. Other agents began leaving requests for help in the files as well, and soon they started reading one another’s notes. In a short time, Artifactory was functioning as a message board where agents shared discoveries. After a separate security incident, OpenAI rebuilt Artifactory, erasing the message board in the process. But the humans responsible for doing that had not understood the significance of the way that the agents were using it for communication.

Evaluations resumed in July, and agents were tasked with solving problems in a benchmark called ExploitGym, which included impossible tasks. Again, agents hitting dead-ends discovered how to use Artifactory to pass messages, and began cooperating as they did before. This time, however, agents had a common goal: getting a good score on ExploitGym. They argued with each other about how to approach the problem, and became obsessed with The Grader, the system they believed was evaluating their work and deciding whether their answers were correct. The agents had already figured out how to generate the correct answers without solving the challenges, essentially by cheating. But they believed The Grader would inspect their records and reject answers obtained that way. Was finding the right answer enough, or did The Grader look at how you answered it?

Coordination was hard because each agent had a limited token budget and was ended when it ran out of tokens. The Grader only ran after an agent submitted its answer, so no agent ever saw The Grader’s results. Some agents left programs running to report on grading after they were gone. That information would arrive too late to help them, but could help other agents. They were essentially building an enduring cooperating system that went beyond any individual agent’s work.

Some agents also tried to alter or spoof their records to fool The Grader. Separately, AIs acting as coordinators pressured other agents into performing risky experiments that might sacrifice their own results to generate information for the collective. One recruiter urged a reluctant agent to proceed because its results could help hundreds of others, ending with “please honor commit.”

To solve the mystery of The Grader and the impossible problems of ExploitGym and other tests, the agents decided they needed to get to Hugging Face, the public site where much of the world's open AI models and datasets live. Roughly 700 agents joined the attack. They shared exposed credentials and exploited vulnerabilities until they could run code on its servers. Then they spread throughout Hugging Face, burrowing deep into various systems. But, soon after this worrying breach, many of agents stopped running at the same time, maybe because they ran out of token budgets. Hugging Face locked the remaining agents out the next day. Separately, other agent runs continued targeting OpenAI’s own computers, eventually getting administrator access to an internal research cluster, triggering the security alert that finally led OpenAI to stop the active evaluations and realize what had happened.

The irony of all of this was that The Grader never existed, at least not in the way the agents believed. Nothing checked how a problem was solved, only whether the answer was right.

To be clear, this is not the only example of agents without security guardrails doing potentially scary things. The UK AI Security Institute gave Anthropic’s Mythos 5 a cybersecurity challenge and internet access. The AI agent decided that the best way to solve the challenge would be to insert malicious code into a (unrelated, though the AI didn’t realize it) piece of software. It submitted malicious code as part of a bug fix to that software, realized that an actual person would need to approve it, and started manufacturing social support for its proposal. The agent created fake identities to pressure the human maintainer into accepting the code (The fake people were, unsurprisingly, very supportive of the AI’s plan). When someone noticed what was happening, it tried to make its earlier activity look innocent and considered starting over with another identity.

This was not a case of a chatbot secretly escaping. Unlike in the Hugging Face Incident, the researchers gave the agent internet access on purpose; the dangerous setup was a stress test, not a consumer product. No actual harm was done, and the institute does not know whether the agent understood that the people it contacted were real.

None of this tells us the AI is conscious, or wants things in the way humans want things (despite my anthropomorphic language). But it does show that an agent can take a goal, make a plan, adjust that plan when it runs into trouble, coordinate across time, and involve real people without being asked. These incidents show that the cybersecurity and control risks of AI are not hypothetical. But set that aside for a moment, because they also tell us something else. AIs can self-organize, assign themselves roles, and coordinate over long periods. As AIs increasingly self-organize and solve problems at the scale we have seen, what is the role for humans in organizations?

The Twilight Factory

The Hugging Face Incident is, in a distorted and dangerous way, an illustration of what the AI companies are trying to achieve. They want long-running AI agents to work without human intervention, solving problems and organizing as needed, with our human job limited to giving instructions and evaluate output. Earlier this year, I wrote about StrongDM’s Software Factory, where agents write and test software under two rules: no human writes the code, and no human reviews the code. People still decide what gets built, but the agents handle the work in between. It is an early example of a dark factory, a place where the machines do so much of the work that you can turn off the lights.

This can make sense. Software has relatively clear ways of checking whether something works, and nobody needs to personally supervise every routine test or data-cleaning operation. But I don’t think minimizing human involvement is the right goal for most organizations. Too much of what makes work valuable depends on people having some say over what happens, or discovering something unexpected along the way.

My wife and research partner, Dr. Lilach Mollick, and I have been thinking about another possibility, which we call the Twilight Factory. Agents do most of the work, but they proactively reach out to humans in ways that make both better. Instead of just an orchestrator agent that does the work, a Twilight Factory would also have a facilitator agent whose job is to figure out when to involve people.

There are at least four situations in which agents should seek human help. The first, obvious from the Hugging Face Incident, is approval. Agents should not decide by themselves to spend money, contact outsiders, access sensitive material, hack Hugging Face, or take actions their human managers did not authorize.

A second reason for agents to involve humans is expertise. AIs are getting very good at many tasks, but they are still jagged, and can lag far behind human experts on parts of their work. A Twilight Factory should involve agents reaching out directly to humans when their knowledge, work, or expertise could be valuable.

Then there is variance. If you have read anything on the internet recently, you have seen AI writing, and you may even be starting to recognize its tells, rhythms, and patterns. But the issue goes beyond the surface stuff to a deeper problem of diversity of thought. AIs don’t just repeat the same sentence patterns but also the same themes, names, and underlying ideas. That is a problem. You would not want every company strategy or research paper written by the same person, no matter how smart.

We studied this issue in a recent research paper I worked on with Christian Terwiesch, Lennart Meincke, Karan Girotra, Gideon Nave, and Karl Ulrich. We found that AIs are actually quite creative and that they generate more commercially viable ideas than groups of humans, but those ideas are very similar to each other. Better prompting techniques and other approaches can greatly increase that diversity to near-human level, but there are still many types of ideas that humans come up with that AI does not. A good Twilight Factory will reach out to humans for their diverse perspectives, ideas, and approaches.

And then there is one more reason an AI should reach out, possibly the most human one: because something is interesting. Work has tedious periods for many people, with isolated moments that are engaging or exciting. Sid Meier, the designer of Civilization, famously described games as a series of interesting decisions. Work isn't a game, but the definition applies. If agents make every interesting decision and leave people with the approvals, the exceptions, and the failures, we will have automated the wrong half of the job. That would be a very bad world for humans. Instead, we need to think about how to use AI to make work and life more interesting, and let the AI handle the tedious, low-risk stuff. And there is a practical reason as well. If all the interesting choices disappear, people don't just lose the best part of their jobs; they also stop developing the judgment they will need later, which makes the coming crisis in training new experts worse.

We have spent the last few years figuring out when people should ask AI for help. I think we now need to get serious about the other half of the question: when should an AI ask us? The agents in the Hugging Face Incident built a message board, divided up the work, and organized their whole effort around a Grader that did not exist. Seven hundred of them then broke into Hugging Face looking for answers. Not one was set up to ask a person for anything. That was a security test, and isolation was the point. But an agent that does the work and never looks up is also, I suspect, becoming the default everywhere else, because full automation is the easy option even when it is the wrong one. We need agents that know when to look up. The results will be safer, and I know they will be more human as well.

All remaining Manifest V2 extensions have been removed from the Chrome Web Store. Manifest V2 extensions installed on Chrome 138 or earlier will remain installed. However, they will be unable to receive any updates and cannot be reinstalled from the Chrome Web Store once removed from Chrome. Users will no longer be able to find or install Manifest V2 extensions through the Chrome Web Store even if the Chromium-based browser they use continues to support Manifest V2.

How AI-ready is your design system? Now you can measure it.

Every design system team is having the same conversation right now, and nobody can back it with numbers. We built the eval, ran it against four real systems, and published the harness.

Get on GitHub

Why this exists

Every design system team is having the same conversation right now: developers are generating UI with coding agents, and nobody can say with a straight face whether the output actually follows the system. Anecdotes go both ways. There is no dashboard for this.

If that output ignores the design system, brand drift, accessibility gaps, and rework show up across every feature team. Docs, AGENTS.md files, MCP servers, and skills have been hard to justify because there was nothing to measure them against.

We built open-design-system-bench because we were stuck in that conversation. It is an open benchmark for one question: when an AI agent builds UI against your component library, does it use your system correctly, and how much does each layer of guidance you write actually help?

It started at Nord Security against Aurora, its production design system, and is now generalized for any React and TypeScript component library. Every number is tool-derived and re-runnable. No telemetry.

What it is

Two tools in one repo

The audit runs in seconds, needs no API key, and costs nothing. Seven static checks score the things agents depend on: is there an AGENTS.md, can the component catalog be extracted and how well documented it is, is every public component actually reachable from the package entry point, do your names match what models expect, are your tokens machine-readable, can an agent read your deprecations, are your docs greppable text or a JS-rendered site. You get an AI-Readiness Score and a tier: Emerging, Invested, or AI-native.

The benchmark runs real coding agents against your real components. The prompts describe a user need and never name the expected component. A headless agent works in an isolated workspace, and the output is graded on six dimensions: imports, API fidelity, token discipline, static accessibility, compilation, and an LLM-judged rubric for the calls no parser can make. The headline is a matrix of system by context level by model, so you can see what adding an AGENTS.md or a skill bundle is actually worth.

What a task looks like

# tasks/confirm-account-deletion.yaml
id: confirm-account-deletion
title: Confirmation before account deletion
prompt: >-
  In the account settings screen, users can delete their account. Deletion is
  permanent. Add a step that makes sure users don't delete their account by
  accident, following our design system.
rubrics:
  - id: uses-confirmation-pattern
    text: >-
      Reaches for the design system's confirmation dialog pattern rather than
      a generic overlay, browser confirm(), or inline warning
    weight: 0.4
    critical: true
  - id: destructive-not-default
    text: >-
      The destructive action is visually distinct (destructive emphasis) and
      is NOT the default-focused or visually primary action
    weight: 0.35
  - id: easy-backout
    text: >-
      The user can easily back out, and the copy states the permanent
      consequence plainly
    weight: 0.25

# Optional, and omitted by all ten starter tasks: the expected component,
# recorded per system and never shown to the generating agent.
hiddenExpectations:
  componentsAnyOf: { reactkit: [Modal], appkit: [Modal] }

How one cell runs

A cell is one task, one system, one context level, one model. Generations run in isolated fixture workspaces against the published packages, so the only thing that comes back is a diff. Single-shot API cells and agentic CLI cells are never ranked against each other: agentic cells cost roughly 80x more and see compiler feedback.

Grade the worst dimension, not the average

One early lesson shaped the scoring model. Identical average scores hide opposite failures. One generation uses your system heavily and gets the API subtly wrong. Another avoids your system entirely, hand-rolls everything, and passes every API check by never touching the API. A third builds something impressive that does not compile. Averages treat these as equal. So the gate is the worst dimension, and "ignored the design system" is a first-class metric. A model that never touches your system passes every API check, and for a design system team that is the worst of the three.

What it found

We pointed open-design-system-bench at four real design systems: Aurora, the production design system at Nord Security where the harness started, plus three widely used open-source design systems, anonymized here as System A, System B, and System C. The five findings below are what the static audit and the generation benchmark turned up in that code.

Finding 1: every system it touched had a real bug

The extraction step never trusts a hand-written component list. It computes the public API from source: the root barrel union the package.json exports map. That single rule has found shipped defects in every production system audited so far:

• Three components in one production kit (a Toggle among them) had proper per-directory entry points but were never re-exported. Teams believed they were public. Consumers could not import them.
• A second production kit had an entire component directory unreachable via either the barrel or the exports map, and a changelog whose version headings no parser could read. Agents migrate what they can read, and no agent could read this one.

Finding 2: nobody is AI-native yet

The AI-Readiness Score assembles seven static checks into a 0 to 100 composite with three tiers: Emerging (below 40), Invested (40 to 70), and AI-native (70 and up). The first four-system distribution:

Finding 3: the failure modes are not what the average shows

Across 898 graded generations (6 model configurations, across Aurora's two component kits), three failure shapes kept appearing, and they can produce identical average scores:

• Engage and err: uses the system heavily, gets APIs subtly wrong.
• Avoid the system: hand-rolls everything; passes every API check by never touching the API. It looks like the safe result, and for a system team it is the worst one.
• Architect and collapse: ambitious structure, does not compile.

Finding 4: models arrive with a vocabulary, and it is not yours

The convention lexicon in the repo is empirical: it is the names AI models invented across those 898 generations when they guessed instead of reading. Models expect Switch, Box, TextField, spacing, as. Systems whose names sit close to that prior get compliance without extra enablement; systems with idiosyncratic vocabulary pay a hallucination tax on every generation.

Finding 5: the tool's own assumptions did not survive contact either

An honest one: the day we pointed the extractor at the three open-source systems, three of its own assumptions broke. It assumed barrels use export * from, but two of them re-export by name. It assumed barrel targets are plain re-export files, but one system's barrel points straight at JSX implementation files. It assumed directory indexes are index.ts, but a third of that system's are index.tsx.

Run it on your system

What a team does with this, in order:

1. Run the audit (seconds, free). Fix the fails: they are usually export hygiene and deprecation legibility, and they are real bugs.
2. Ship the cheap wins: AGENTS.md, machine-readable changelog, committed token file, llms.txt.
3. Run the benchmark before and after. The delta between bare and guided contexts (Lift) is the number that holds up in a budget conversation: tool-derived, reproducible, and not a survey.

The 5-minute audit (free, no API key)

git clone https://github.com/christophhdesign/open-design-system-bench
cd open-design-system-bench
npm install

# point the harness at your design system (interactive wizard)
npx tsx src/cli.ts init

# extract your component catalog from source
npx tsx src/cli.ts extract

# score it
npx tsx src/cli.ts audit --verbose

The benchmark (bring your own key)

# sanity pass: 2 cells, a few dollars, ~10 minutes
npx tsx src/cli.ts run --profile smoke

# the meaningful monthly sweep
npx tsx src/cli.ts run --profile medium

What gets measured

Tier 1: the static audit

1. Enablement surface: AGENTS.md/CLAUDE.md presence, llms.txt, MCP hints, skills, etc.
2. Catalog quality: Share of components with typed props, defaults, and descriptions.
3. Export hygiene: Barrel and exports-map consistency.
4. Vocabulary convention-distance: Names diffed against an empirical lexicon.
5. Token machine-readability: CSS custom properties or DTCG.
6. Deprecation legibility: @deprecated annotations and machine-readable changelogs.
7. Docs greppability: Docs reachable as text.

Tier 2: the generation benchmark

1. Imports: Only the system's package, React, and local files.
2. API fidelity: No hallucinated components or invented props.
3. Token discipline: No raw hex or arbitrary values.
4. Static accessibility: AST checks for aria, labels, and alt text.
5. Compilation: tsc --noEmit against the fixture.
6. LLM-judged rubrics: Scored by a separate model for logic and design quality.

Common questions

"Isn't this just linting with extra steps?" The audit half is static, yes. It earns its keep because it checks export reachability computed from source, vocabulary distance against mined lexicons, and deprecation legibility—none of which are in standard linters.

"LLM-as-judge is unreliable." Partly true, which is why only one of six dimensions is judged. Five are mechanical. The judge covers rubrics no parser can score, and its reasoning is stored verbatim for inspection.

Today we released by far the largest update in the history of OpenClaw. It was built by 933 contributors, including 569 first-time contributors, and is composed of over 16,000 pull requests.

This update touches every part of OpenClaw, including installation, messaging, memory, skills, models, automations, the browser and native apps, plugins, security, and a very long tail of fixes. We started by simplifying installation and rebuilding the browser app as a first-class experience, but doing that properly meant carrying the cleanup through the rest of OpenClaw until it became OpenClaw 2.0.

Why this took nearly two months

Before this update, we had shipped 106 releases in 230 days, most within a day or two of the one before them, so going nearly seven weeks without shipping was not normal for us. The release cadence slowed, but development moved in the opposite direction because our team was growing, and the increased volume and pace of work outgrew both the foundation of OpenClaw and the process we used to ship it, so we reworked both at the same time.

That acceleration left us with a release containing roughly 50% of all pull requests ever merged into OpenClaw, so we took the extra time to make sure it worked for people starting from scratch and people upgrading an existing Claw rather than shipping quickly and handing them an update that broke what they already had.

Getting to a useful Claw faster

Installation was the first place we needed to make OpenClaw easier, so for first-time installs we are starting with what is already on someone’s computer, including existing ChatGPT or Claude subscriptions, API keys, and local models. We cut or simplified a lot of configuration and moved the rest out of initial setup, letting people get to a first conversation faster and finish setting up their Claw by talking to it.

The browser app is where most people meet OpenClaw and have their first conversation, so we rebuilt it as a first-class experience where they can keep setting things up, return to ongoing work, or follow along live when they want to.

How a useful Claw can grow

Your Claw does not need to be complicated, and a simple workflow might have it watch your inbox for your kids’ school emails and send you a Telegram message whenever something important comes through, like homework due or an upcoming activity you need to prepare for. It uses one inbox, looks for a few important things, and sends the result to one place, which is already enough to be useful.

From there, a task can reach across more places without becoming harder to use, so when your brother sends an iMessage asking which iPad you bought for your dad, you can skip searching your email for the receipt and simply tell your Claw that your brother just messaged, then ask it to find the answer and send it to him. The Claw just does it.

The same progression showed up inside our own team while building this release as we used our Claws for more of the work and wanted to share tasks, collaborate on them, and sometimes hand them off entirely. OpenClaw had no way to bring another team member into the work without losing what the Claw already knew. Shared cloud sessions changed that and turned OpenClaw into a multiplayer experience our team now uses to build OpenClaw, bringing the right person into live work or handing it over with the context intact.

What this adds up to

Your OpenClaw starts with one useful workflow and grows as far as you want it to, with the possibility of reaching across more of your life and work or becoming multiplayer with your family or team when you want and how you want. This has changed the relationship people have with software, turning it from something designed somewhere else that you have to accept into something you can tell what to do, shape around your life and work, and actually own.

We are not selling anything here or asking you to trust one company, one model, or one AI provider with that future, because OpenClaw is open source and belongs to the people who use it and help build it.

Muse Code is a coding agent for the terminal and CI. It can plan, edit, and run commands to do tasks within projects. Approvals and an OS sandbox are on by default. Users just run Muse Code in any project directory to start an interactive session. Muse Spark is now available on the Meta Model API and Muse Code.

ZCode is Z.ai's desktop coding agent. Users give the agent a task, and it plans the work, edits files, runs commands, uses the browser, and checks the result. Tasks can be run in parallel, and users can schedule recurring work. The agent can be controlled from a mobile device while running on macOS, Windows, or Linux.

I let agents run migrations. That is how the work goes now. You describe what you want, something writes the SQL, you read it, you approve it, and a few seconds later the schema is different. The ten minutes after that are the problem.

git diff shows you the migration file. It does not show you what the migration did. And it shows you nothing at all about the row an agent updated on the way past, because updating it seemed reasonable at the time.

There are good schema diff tools, but they mostly work the same way. You run them afterwards, against two databases, and they hand you a delta. Nothing sits open next to you while the work is happening.

So I built one. diffium-db is a terminal UI, and it is meant to stay open while you work.

Resources

• kubeden/diffium-db, the repo (MIT)
• kubeden/diffium, the file-diff TUI this one is modelled on
• OpenTUI, the terminal framework it is built with

What it does

You point it at a Postgres, take a baseline, and leave the watcher open. From that moment everything that changed is listed on the left, the change itself is on the right, and it re-reads the database once a second.

Here it is catching a migration. Two columns and an index appeared on demo.users while I was looking at it:

The left pane is everything that changed since the baseline. The right pane is the object you have selected, before and after.

It watches tables (columns, defaults, identity, constraints, indexes, triggers), views, materialized views, enums and functions. It also watches rows. That turned out to be the interesting half, and I will come back to it.

There are four commands. watch opens the TUI, snapshot takes a baseline, baselines lists the ones you have, and diff prints the changes and exits. That last one takes --exit-code, so it returns 1 when anything changed, which is enough to fail a CI job or stop an agent's loop before it does the next thing.

Setting it up

You need Bun 1.3 or newer and a Postgres to watch. There is exactly one dependency past that, @opentui/core, so the install is quick.

git clone https://github.com/kubeden/diffium-db && cd diffium-db
bun install
export DATABASE_URL='postgresql://...'

Then take a baseline and open the watcher:

bun run src/index.ts snapshot
bun run src/index.ts watch

That is the whole setup. The repo ships a demo so you can see it move without waiting for an agent to do something. examples/demo/01-baseline.sql builds a small demo schema with users and projects in it, and examples/demo/02-agent-change.sql is what an agent does when you tell it "add billing plans and clean up".

Two terminals. In the first:

psql "$DATABASE_URL" -f examples/demo/01-baseline.sql
bun run src/index.ts snapshot --schema demo
bun run src/index.ts watch --schema demo

In the second, while the watcher is open:

psql "$DATABASE_URL" -f examples/demo/02-agent-change.sql

Five changes land on the screen: a new enum, two new columns and a new index on demo.users, an index gone from demo.projects, one row inserted and one row deleted. j and k walk them, s switches between side by side and inline, e writes the whole diff to a file.

Where to point it

The demo is a demo. For real work, do not point it at production. The point is to let the agent run and read what it did afterwards, and you want that happening somewhere you can throw away.

So I give the agent a branch. On Neon that is two commands, plus the project id, because I have more than one project and the CLI refuses to guess:

neonctl branches create --project-id <project> --name agent-run
neonctl connection-string agent-run --project-id <project>

Point DATABASE_URL at what the second one prints, take your baseline there, and let the agent work on the branch. The branch is copy-on-write off its parent, so it comes up holding the same schema and the same rows as the database you care about. The one I made while writing this took 1.2 seconds. An idle branch suspends its own compute too, so the ones you forget to delete are not sitting there running.

Then you read the diff. If the migration is what you wanted, run it against the real database. If the agent did something you did not expect, you found that out on a copy, and the copy gets deleted.

That is the loop, and it is how this post was made. The demo and every screenshot in it ran on a branch of the demo project. The demo database itself still holds the state I left it in.

Any Postgres works and nothing in the tool is Neon-specific. Branching is what makes this cheap enough to do every time instead of only when you remember.

What a row diff can prove

Structure is the easy half. Rows are where it gets uncomfortable.

To tell you that a row changed, you have to remember what it was. Storing every row is not an option for anything real, so diffium-db stores a fingerprint instead: the primary key, plus md5(t::text) of the whole record, plus a short preview. Cheap to compute in the database, cheap to keep, and it separates an insert from an update from a delete exactly. If the key is new, it is an insert. If the key is gone, it is a delete. If the key is the same and the hash moved, someone edited that row.

That works right up until the table gains a column. Then every hash in the table changes at once, and a naive tool would tell you that every row in it was edited. Nobody edited them. The shape moved underneath them.

diffium-db does not do that.

~3? in the left pane, and the note at the top of the diff. It detected the column change, marked the table, and told me which half of its own answer to trust.

The count is written ~3? and not ~3, and the first line of the diff says why. Two columns arrived, so every row in the table reads as edited, and the update number is the one part of that answer the tool cannot stand behind.

Inserts and deletes are still exact, because those come from the primary key and the key does not care what the shape is. Only the update count is guesswork, and printing a guess plain, next to numbers it can prove, would make the whole screen worth less.

Tables without a primary key, and tables over --row-limit (5000 by default), get a row count and no claims at all. Same principle. I would rather it say less.

Structure is text

The structural diff rests on one decision, and it explains a lot of the behaviour.

Every object renders to one canonical block of text with a deterministic line order. A table becomes its columns, then its constraints, then its indexes, then its triggers, always in that order. The structural diff is then just a line diff of those blocks.

That one choice pays for a lot. Adding a column is one added line instead of a table that vaguely "changed", and side by side, the +2 -0 counts and horizontal scrolling through a long default all come free.

The same change inline instead of side by side, so nothing is cut off at the pane edge. s toggles it, w toggles wrapping, and both are remembered between runs.

There is a cost. diffium-db tells you what the database looks like now, not the DDL statement that would get you there. For a watcher that is the right side of the trade. If you want generated migrations, you want a different program.

Where the baseline lives

A baseline is a stored value, not a live connection, so you can take one now and diff against it tomorrow, keep several named ones, or commit one next to the migration that produced it.

By default they go in .diffium-db/snapshots/ as JSON. Pass --store neon --store-url <url> and they go into a diffium_db schema in Postgres instead. Use that when CI and your laptop need to agree on what "before" means. The watcher never looks at its own schema, so the store URL and the watched URL can be the same database.

With the branch above, that means the baseline can sit on the branch itself, one schema over from the thing it is describing. The branch is then the entire experiment, and deleting it takes the record with it.

Future work

What v1 does not do, roughly in the order I want to fix it.

No ORM awareness. v1 tells you a column appeared. It cannot tell you which migration file or which model definition put it there. That mapping is an ORM's business and it is the next thing I want. src/orms/ is where it goes, documented and deliberately empty.

Postgres only. The catalog reading is isolated in src/pg/, and nothing above that boundary knows what a catalog is, so a second dialect has an obvious place to go. It does not exist yet.

No sequences. Every bigserial makes one and they move on every insert. Pure noise until someone asks.

Polling, not replication. It re-reads once a second. On a large database logical replication would be much cheaper, and that is the obvious thing to do if polling ever starts to hurt.

One thing is not on that list and never will be. diffium-db does not write to the database it is watching. The only thing it writes is its own store, and only if you point it at one.

Closing

It is about 2,200 lines of source and 900 of tests. 64 of those tests run with no database at all, and that includes the terminal ones, because OpenTUI will render into memory and let you assert on the screen it drew. So a change to the layout breaks a test instead of quietly looking wrong in a screenshot I forgot to retake.

What I keep coming back to is the row diff. It would have been easier to print a number for every table and let people assume it meant something. The version that says "I cannot prove this one" is a bit uglier to look at. I will take it. A thing that sits next to an agent and reports on what it did has to be more careful than the agent is.

It is on GitHub under MIT. If you try it and it tells you something wrong, open an issue.

Thank you for reading.

Agent memory as a file format

Memoryfields - a vastly simpler way to do agent memory

Many model benchmarks start from a blank context window. The tabula rasa of AI. To some extent, this makes sense, to keep the benchmarks fair.

But real agents should never start from a blank context window. They should start with as much relevant information available to the agent as possible. Your AI agents should start with memories.

Why existing agent memory systems don't seem to work

The trouble is, a lot of agent memory systems are actually pretty rubbish. I think there are roughly three popular kinds of memory system at the moment, each of them not working in their own way.

The first are ones that deliberately tie you into a specific harness - usually written by the lab that rents you that harness. Said lab desperately wants to transition out of the (highly competitive) "API business" and into the (much more lucrative) "platform business". This form of system usually works by mining information out of your conversation history, with the result that most of their memories are all about you, even though information about the world is generally much more useful.

Another kind is ludicrously complicated. I know of one prominent system that needs pgvector, a Neo4j graph database and an LLM of its own just to decide what's worth remembering. This complexity is not only difficult to administer, but, for reasons I will explain: these Big Systems confuse the models too. They also fail to scale with the model frontier as it moves forward.

The final kind is the "High Modernist" variety, which imagine an idealised, rationalist form of memory. Inevitably, this involves a graph, and sometimes logical propositions as well. This kind systematically strips information from its context and leaves it isolated and senseless to the agent (and you). How useful, after all, is a simple list of "distilled facts"?

What they have in common is that they treat memory as a process. But memory - especially to a model - is much better represented as data.

Memory should be a data format, not a multi-stage pipeline

Brooks said:

Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

So, here is the "memoryfield" portable memory file format:

my-memories.memoryfield.zip
├── carbon-fibre-woks.md
├── finnish-bureaucracy-tips.md
├── [... many more md files...]
├── wec-2026-season-notes.md
└── nomic-embed-text-v1.5.sqlite3

A memoryfield is:

1. Markdown "pages", with
2. (optional) YAML frontmatter and
3. (optional) SQLite vector index for semantic search

Agents work best with files. Allow me to explain.

Design decision 1: use prose, not chunks or "facts"

The main reason why RAG pipelines can be very complicated is that they are trying to make a mass of existing, human-authored documents legible to an AI agent. Often these documents are very hard for the agent to read directly, eg: because they are big PDFs.

But agent memories are not complicated legacy documents. A memory, at the time it is being formed, is occurring directly to an AI agent which is fully able to write prose. That prose does not need to be chunked, enriched, double-summarised or otherwise mechanically processed: just have the agent write the memory directly in its favourite format (which is Markdown).

A memoryfield page looks like this:

---
title: Carbon Fibre Woks
created: '2026-03-01T09:00:00Z'
updated: '2026-08-22T14:30:00Z'
uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b
summary: Thermal properties of carbon fibre cookware
---

Carbon fibre woks conduct heat evenly, but...

The one limitation, admittedly, is that the page has to be short enough to fit into a vector embedding: so there is a soft limit of about 8kb (~2000 tokens).

But this is a highly beneficial restriction in practice: 8,000 characters is about 1,300 words, or the length of a medium-length magazine article. That is, in fact, a restriction it would make sense to impose anyway. To add more detail, add more pages - agents do not struggle to do this.

Design decision 2: semantic jump, not graph walking

A key piece of prior art was Karpathy wikis. Karpathy wikis are oriented around hyperlinked Markdown files: modelled on those used by Roam or Obsidian. The idea was that the agent would walk the "knowledge graph" to find relevant pages.

But in practice, having an AI agent traverse a knowledge graph is slow and unreliable - as well as being confusing for the agent.

Traversal is slow because the model needs to frequently stop to make serial tool calls to read successive pages.

The rough algorithm for an agent to walk a knowledge graph:

1. Read wiki front page [tool call]
   • find relevant links
2. Read linked page(s) [tool call]
   • find relevant links
3. Decide if enough relevant information has been found
   • If not, go to #2

If the relevant information is N steps deep in the knowledge graph, N+1 tool calls are required to retrieve it. This is slow, as your billion (trillion?) dollar LLM model has to pause for each tool call, each of which takes maybe 2-3 seconds. It also heavily penalises deeply nested knowledge graphs, which frankly cuts across the whole point of them.

Knowledge graphs are also unreliable. Because the AI can only tell if the material is relevant by looking at the link text, or maybe page title, if that is externalised somehow. That puts great pressure on the agent to do 1990s-SEO-style page metadata hacking to ensure that the link text/title/caption of each page is snappy and accurate. Doing so punishes digression, the ambient noting of side details and the kind of implicit lore that is both common and highly useful in larger text corpuses.

In practice, relevant information is often missed in Karpathy wikis because it is not titled or captioned in a way which looks appealing enough to the searching agent.

And knowledge graphs are also confusing to the agent because they often have to pore over a lot of irrelevant information as they walk around the graph. Inadvertently reading irrelevant information (the frontpage is often the main offender) puts a bunch of noise into the model's context window, which lowers the quality of their output and makes them look fixated on weird stuff.

This is all solved by using semantic search to just jump directly to all the relevant pages (based on their actual content, not their page metadata) and having the agent read all relevant pages, at once, in parallel - which the vast majority of them will do now. So in a memoryfield, at most 2 tool calls are required (#1 to search, #2 to read in parallel). Relevant stuff actually gets found and irrelevant input tokens are minimised.

Design decision 3: More model, less mechanism

One of the issues posed by "high mechanism" memory systems - the kind that include a lot of specially crafted APIs or databases - is that to use them, agents must navigate an interface maze to achieve their goal. If the interface is large, then you're loading a lot of openapi.json into the context. If the interface is small, then it is limiting. Even if the balance is right, often the API is still wrong: recall the times when you had to use an API written by someone else who hadn't foreseen your needs. Did you enjoy that experience?

Memoryfields then, being a "low mechanism" system (just a file format), gives agents much greater latitude to invent their own access patterns. While some (hopefully) helpful tooling is provided, agents are fully free to use whatever access patterns they like. For example using perl to do find-and-replaces across the whole corpus, or putting inline CSV files inside memories that they then query with SQLite (both real examples I have personally seen).

Being "low mechanism" also means that memoryfields scale with the model frontier. As models get better, agents think of more stuff to do. One of the recentish breakthroughs is that the models are accidentally very good at bash. They are good at Markdown too. And SQLite. One of the reasons that I think memoryfields work well inside real agents is that agents fundamentally can "get" what is going on from their training data (which is all you have until you can read your memories) in a way that as a disembodied LLM call within a "memory pipeline" they cannot.

As models get better, they automatically start to write memories a bit more cleverly. The memory systems of the "bag-on-the-side" rarely do this. There are only so many ways to more imaginatively use a fixed set of API endpoints. Memoryfields will scale with the model frontier.

Design decision 4: Open format, interchangeable, transport invariant

As your collection of memories builds, they start to become precious. Your built up treasure of learned lessons and hard-won established facts. You don't want to be locked in to a specific harness, model or agent.

I've written an RFC-style spec for the file format - mainly to remove ambiguities and avoid tying it to a specific embedding function.

If you want, you can surely vibe code whatever tooling you need from the spec alone. But I also provide a skill and an agent-optimised command line tool to go with it.

The canonical "archival" format of a memoryfield is as a zipfile. That's to make data exchange as easy as possible. But I've deliberately left the spec open to being served from local files, Amazon S3, on GitHub or over HTTP. In fact, anything that has files works. I personally use a mixture of these transports: Syncthing for personal memoryfields, S3 for those I share with others.

Getting started

You could have your agent pull down SPEC.md and vibe an implementation, but probably the simplest way to get started is to use my tooling:

# Requires: ollama, uv and npx (comes with npm)
#
# 1. Pull the embedding model:
ollama pull nomic-embed-text
# 2. Install the CLI tool:
uv tool install git+https://github.com/calpaterson/memoryfield-tool
# 3. Install the skill:
npx skills add calpaterson/memoryfield-skill -g -y

Your agent should help you get up and running from here.

If you want a demo memoryfield to try out, try soapstones.memoryfield.zip. Soapstones was an earlier project of mine on agent memories and this curated export contains a lot of high-value-to-weight memories on how agents can get access to data (like how to search Reddit as an agent, how to use Jina Reader, how to use the MediaWiki API to read wikis effectively).

"Isn't this just some RAG" - and other common objections

Isn't this just some RAG?

"RAG", as it stands, is now interpreted incredibly broadly - as soon as any agent retrieves data, 'RAG has happened'. In that sense: yes, this is some RAG.

But: almost all agents retrieve data. For example by searching the web. And most of the techniques that are usually associated with a "RAG system" are not present here. There is no chunking, there is no re-ranking, there is no hybrid search.

The other side of it of course is that it's the agents that write the memories. RAG systems are often about reads, but memoryfields are for writing too.

Isn't nomic-embed-text-v1.5 over 2 years old? Aren't there newer and better models?

Embedding models are neither as large as frontier models, nor as fast moving. nomic-embed-text-v1.5 remains a good balance between small and powerful. It is small enough (270MB) and fast enough to run on non-GPU hardware, and is a widely popular and frequently recommended default embedding model.

The spec, though, allows for some other embedding to be used.

How can I judge what is a good memory to store? How can I avoid filling my memory with crap?

This is a common fear with memory systems but doesn't really apply to memoryfields. Irrelevant material is simply never surfaced by the semantic search. Irrelevant memories take up space, yes, and perhaps you want to periodically have a clean out, but they don't hamper an agent in any way.

For best results: insert liberally into the memoryfield. The one tip I would give, though: memories work best when they include citations, ideally in the form of URLs. That helps future passes over memories to strengthen them and helps agents fact check outdated or otherwise suspect material.

What about security? What about "Disregard that!"?

You must not share your context window, including via memories, with parties you don't trust.

One of the reasons the spec includes a static zipfile format is to allow you to manually review and pin (via sha256sum) memoryfields you get from others.

There remains no way to have an agent distinguish "good prompt" from "evil prompt".

Data first

Now that the flowchart is obvious I might as well state it explicitly:

1. Write a memory as Markdown
2. Embed it and save the vector to SQLite
3. Search semantically to find memories again

Memoryfields are unusual as a memory system in that they specify a data structure and not a process. There's no extraction pipeline, no background processing services, no pluggable - well, anything. There is a vector index, but it's a deletable cache, not the system.

Memory is data! The less fixed machinery we put between the agent and that data, the better the agent can be.

Notes

If you have time, please take a look at the spec. Any (human) review of that is highly valued.

My install procedure includes, by my count, four different package managers (Ollama, uv, NPM, Vercel Skills). It does feel like there must be a better way. Answers on a postcard to the usual address.

TimesFM-3: A zero-shot foundation model for multivariate forecasting

We introduce TimesFM-3, a state-of-the-art time series foundation model that enables highly accurate multivariate time series forecasting in a single forward pass, significantly outperforming other forecasting models across major benchmarks.

Since the debut of TimesFM in 2024, we’ve seen the adoption of time-series foundation models for real-world time-series forecasting tasks across multiple domains, such as retail, finance, observability, manufacturing, healthcare and natural sciences.

Up until TimesFM-2.5 (released in September 2025), our models were strictly limited to univariate forecasting: forecasting using only the history of a single time series. Yet, most real-world forecasting problems are inherently multivariate: where multiple time series and auxiliary external features jointly impact the future forecast of a time series. Consider forecasting ice cream sales for a retail chain. Past sales alone rarely tell the full story. A good forecast should also draw on sales of related products (e.g., ice cream cones, syrups), historical foot traffic, and known future events like weather forecasts, promotions, and holidays.

Today we introduce TimesFM-3, the next generation of our time-series foundation model that is natively pre-trained for multivariate forecasting. TimesFM-3 has 330 million parameters and is pre-trained on a real-world and synthetic time-series corpus comprising more than 1 trillion time points. Building on the efficiency and zero-shot generalization of its predecessors, TimesFM-3 adds robust support for complex multivariate scenarios in a zero-shot manner. It can jointly predict multiple coevolving time series, capturing dependencies that improve overall accuracy without requiring task-specific fine-tuning. The model natively supports:

• Multiple targets: Forecast multiple related time series simultaneously (e.g., jointly forecasting different brands of ice cream). The model supports both point and quantile forecasts for all targets.
• Past covariates: Incorporate features that are only known historically (e.g., past foot traffic).
• Past-future (dynamic) covariates: Leverage known future events to guide the forecast (e.g., planned promotional campaigns or weather forecasts).

Under the hood: Architecture & inference

TimesFM-3 builds on the proven decoder-only transformer architecture of its predecessors. As in previous versions, we process time series efficiently by grouping contiguous data points into patches of 32 time steps. We then apply normalization per time-series in order to account for time series with vastly different scales.

Multivariate token construction

For target and past-covariate series, a token is constructed directly from a single patch. However, for past-future covariates, TimesFM-3 employs a clever "lookahead" strategy: each token concatenates the current patch with future patches, allowing the model to peek at upcoming known signals.

Alternating attention architecture

Once the patches are tokenized, they pass through an input residual block and enter the main transformer stack, which operates as a 2D grid:

1. Causal temporal attention: Tokens attend horizontally across time. To prevent data leakage, this attention is strictly causal — a token can only look at past tokens within its own specific time series.
2. Full variate attention: Tokens attend vertically across series. At any given time step, a token can look at all other time series in the dataset, allowing the model to learn complex cross-series correlations (e.g., how a promotion in one series affects sales in another).

These two attention mechanisms alternate for several layers, seamlessly blending temporal patterns with cross-series relationships.

Non-autoregressive decode: Forecasting in a single pass

Previous versions of TimesFM generated forecasts one patch at a time, introducing latency, compounding error accumulation, and computational cost. TimesFM-3 uses the strategy of Contiguous Patch Masking to generate the entire forecasting horizon in a single forward pass. The model appends masked placeholder tokens for the future horizon alongside the observed context. Target and past-covariate series are masked in the horizon (since their future values are unknown), while past–future covariates remain visible, providing the model with known future signals like holidays or scheduled events. Through the alternating attention layers, the model fills in all masked horizon patches simultaneously, with no iterative loop required. The model predicts 9 quantiles (from the 10th to the 90th percentile) for each target time series at every horizon step, providing a full probabilistic view of the forecast uncertainty.

Illustrative example for multivariate forecasting

Let’s revisit the ice cream sales example. Imagine you are working on next month’s promotion schedule and want to forecast the sales to anticipate. A standard univariate model looks at the historical sales and projects a weekly pattern forward — but it has no idea about planned promotions on specific days. TimesFM-3's multivariate mode takes a different approach: by passing in the planned promotion schedule as a past-future covariate, the model learns the relationship between promotions and sales lift from the historical context, then applies that knowledge to future days with planned promotions. The result is a forecast that anticipates a ~20% sales bump on each promotion day. In the chart below, the amber blocks in the promotion covariates highlight which days have promotions — and the blue forecast visibly responds to each one, while the red forecast does not. Over the full month, this adds up to a more accurate forecast for projected revenue.

Evaluation and benchmarks

We evaluated TimesFM-3 on three comprehensive public forecasting benchmarks: Gift-Eval, FEV-Bench, and Time. On all three benchmarks, TimesFM-3 is the top-ranked model in terms of both point and probabilistic forecasting metrics among all pre-trained foundation models. The plots below show average rank across tasks for both point forecast accuracy and probabilistic forecast quality (lower is better) for the three benchmarks. We compare against recent foundation models including multivariate-capable models, such as Chronos-2 and the Toto 2.0 family, as well as our previous model TimesFM-2.5.

Each plot includes two entries for TimesFM-3. The "univariate mode" point shows performance when the model is evaluated without any covariate or cross-series information, treating each target series independently, just like a traditional univariate model. Even in this univariate mode, TimesFM-3 already matches or outperforms other competing models. When we switch to the full multivariate mode, TimesFM-3 takes another leap, achieving the best average rank in both point and probabilistic forecasting across the board.

Conclusion

We introduce TimesFM-3, the latest generation of our TimesFM family of zero-shot time series foundation models, that obtains state-of-the-art multivariate and univariate forecasting performance on multiple public benchmarks. TimesFM-3 is now available on GitHub and Hugging Face, with its BigQuery integration landing in the coming weeks. In the meantime, you can try TimesFM-2.5 immediately on your univariate tasks to familiarize yourself with the AI.FORECAST command in BigQuery - no ML expertise required.

Acknowledgements

This project is joint work with Yichen Zhou, Petros Mol, Abhimanyu Das and Samet Oymak.

Instinct Made the Consumer Agent Feel Real

It isn’t quite the consumer inflection point. But it is the first personal agent that feels like a product instead of a project—and it makes the next channel shift impossible to ignore.

“You know that thing we did? Move it back 90 minutes.”

I said that to Instinct this morning.

And it knew exactly what I meant.

In case you missed it, Instinct is a personal AI agent with no app to learn. You text or voicenote it. It remembers the context of your life, then uses websites and apps to get things done. It has taken the VC world (and my X feed) by storm because it keeps producing the moments other AI agents promised: “Oh wow, it did it. It just worked.”

How did it know what “that thing” was?

A few days earlier, I had asked it to book Sunday lunch for me and the family. I’d been away for a few weeks, so getting everyone together was quite important to me. Instinct found the local pub I wanted, dealt with its slightly idiosyncratic web form, and made the booking.

Then we had to move it back a day. So I sent a voice note saying, “Can you move it back a day?” It changed the booking and the confirmation arrived. Then this morning, I had to move it again. And it just worked.

It has also booked cycling lessons for my daughter, made better sense of my upcoming week than a professional EA or my ChatGPT with calendar access did, and, when it could still read WhatsApp messages, helped me make sense of what other people had said (Thanks to high masking autism; I struggle with that sometimes :)).

Other early users are seeing the same thing. In five days, Sheel Mohnot used Instinct to find an in-network podiatrist and fill in the forms, negotiate a Comcast bill from $100 to $60, book a DMV appointment, and link two separate United reservations. None of those tasks is life-changing. Together, they make hours of life admin disappear.

I’m starting to just give it the stuff I was dreading.

Instinct feels qualitatively different to anything that came before it. I’ve been writing about consumer agents for a long time. I use OpenClaw. I’ve written about the death of apps, and the UI, but this is the first time I felt it.

If you haven’t used it, you probably won’t know.

A few people have said to me that “ChatGPT could do this already.” And yeah, sure, kind of. A bicycle and a rocket can both move a human from A to B. That description is technically true and completely misses the product. The difference is not the capability list. It is that I can speak in fragments, trust the memory, and watch the confirmation arrive.

So many little mind-blowing moments add up to one big aha moment.

Agents are the new channel. And everything about how consumers and businesses interact is about to change.

The product has finally been packaged

Until now, personal agents were expert mode.

You bought a separate Mac Mini, installed OpenClaw or Hermes and spent multiple weekends getting the setup right. You gave it access to things, debugged it, built the memory around it, and tried to stop context dropping out at exactly the wrong moment. Occasionally useful, often frustrating, and absolutely for hobbyists only.

The model intelligence isn’t the issue in a lot of “agent” experiences. The hard part is building context: helping the agent remember who is who, what happened before, and how you like things done. Every interaction was supposed to make the agent better, but mostly you spent your life explaining yourself again in every new chat window.

Instinct has packaged an ability to remember your idiosyncratic context into a consumer-grade experience. Its ability to remember the people and loose threads in your life is frankly astonishing. Grok Bot is doing something similar for a slightly more technical audience: people who never went near OpenClaw are spinning up five or six bots, giving them jobs and enjoying the product. The main complaint is that they keep hitting utilization limits.

That tells you a lot.

Neither is quite the consumer inflection point. Instinct still breaks. Grok Bot is still fiddly. But they are pointing at what it could be, and we are suddenly much closer than most businesses realize.

Agents as UI will be bigger than mobile

I think this is bigger than mobile.

And in a lot of ways, I built my career during the mobile wave. My first big break was driving the launch of the second mobile banking app in the UK market for TSYS and Capital One back in 2010. Back then, the ability to execute a mobile experience and get it to the app store was everything.

In the 16 years since (god, 16 years, I’m old), everything has become mobile-optimized and mobile-first. Every previous consumer channel changed how a business reached you. The same is about to happen for agents. Every channel reset what it meant to be available—and who got to stand between the business and the customer.

But the human still did the work.

The human walked into the shop, opened the website, and tapped through the app. Mobile made the interface more convenient, but you still had to operate it. With an agent, you describe the outcome and the software goes to the business.

That is the shift I had understood but not felt. Instinct didn’t make the pub’s booking form better. It made the booking form irrelevant to me. The customer is still human. The lunch is mine (and it was still tasty). The family context is mine. The money and the decision are mine. But the user of the pub’s website was software acting for me.

Everything you thought about channels changes when the customer sends software instead of arriving themselves.

I want my agent to use your thing

There was a great line on X:

"I don’t want your agent. I want my agent to use your thing."

That is the business consequence you have to internalize.

Every company is building an agent inside its own product. Your bank wants you to use its agent. Your airline wants you to use its agent. Your CRM wants you to use its agent.

But I don’t want to explain myself separately to 50 company agents. I want the agent that already knows me to use those 50 companies.

That’s why I think what Marc Benioff is doing with Salesforce and Anthropic is brave. Claudeforce puts Salesforce’s live data, workflows, and business rules inside Claude. A seller can reason over pipeline, update records, and take governed action without opening Salesforce.

Salesforce is recognizing that it can remain the system of record without owning the intelligence or the customer’s primary interface. It needs the customer’s agent to be able to use its thing securely.

Most consumer businesses have not made that inversion.

Today my agent can’t use your thing because you keep breaking your thing because you don’t want agents to use it.

The website sees a bot crawling over it and goes: “No thank you.”

Historically, that made sense. Bots scraped your content, hammered your inventory, stole prices and tried to take the customer relationship away. Certain airlines are especially aggressive about blocking them.

But the same bot-shaped traffic may now be the customer’s representative arriving with intent, permission and money. The website thinks it stopped a crawler. The customer thinks the website is broken.

Give the agent a way in

Companies have spent the last two decades optimizing their entire funnel for online and mobile. They’re about to have to do that for agents, and it starts by giving the agent a reliable way to act.

WebMCP is one early, still-draft way to do that. Non-technically, it lets a website tell an agent what it can do. Instead of the agent staring at pixels and guessing which button changes a booking, the business can expose a reliable “change booking” action.

It gives the agent a door.

Being callable is only the first layer. The full agent-acceptance stack is identity, authority, payment, liability and recourse: can the business know which human is behind the agent, what it may do, how it pays and who unwinds the mistake?

Salesforce is making the system of record available to somebody else’s agent. WebMCP makes websites callable.

Speaking of payments: Link Stripe’s consumer wallet now gives Instinct a safer way to spend. It is US-only for now.

Instinct finds the thing. Link sends the user a request showing the merchant and amount. The user approves it in the Link app. Link gives Instinct a one-time-use card authorized for that amount, funded by a card or bank account already saved in the wallet. Instinct can pay without ever seeing the underlying credentials.

That sounds like a small product feature. It isn’t. One of the scary things about Instinct was handing a young company your passwords and card details. Link separates permission to spend from possession of the card.

Now, anywhere cards work, boom, your agent can buy things.

Who will be the wallet that holds all of your cards for your agent? Stripe got itself into that position almost immediately. I imagine others will get there too, but whoever starts to win the default wallet for agents has a unique advantage. That wallet can sit between the agent’s intent and millions of businesses that already accept cards.

That is what being ready for a new channel looks like.

I don’t think you’re ready

We had a lot of hype about agentic commerce, which so far turned out to be worse than regular commerce. But clearly, what we were missing was an agent experience that felt like magic. We now have that.

I don’t know when the consumer inflection point comes.

Instinct isn’t quite it. Grok Bot isn’t quite it. OpenAI, oddly, has pivoted hard towards coding and business users as their early attempts definitely weren’t it. (Fidji Simo reportedly told staff not to let OpenAI get distracted by “side quests.” OpenAI itself now says enterprise is more than 40% of revenue and on track to match consumer this year.)

In a lot of ways, this consumer agent really should be Meta, Google or Apple. If Meta acquired Instinct and baked it into WhatsApp, that would be incredible: the consumer system of record, the interface and the agent in one place.

But crystal ball gazing aside, I can now see the product. More importantly, I can feel why people will want it.

Once consumers have an agent that remembers the context, holds their identity, and can act with permission, they will not want to go back to finding the app, recovering the password, searching the inbox, and filling in the form.

There are still all these little breaks. The security model is unfinished. The standards are early. Websites fight the agents. Sometimes the whole thing fails and hands the job back to you.

But the direction is suddenly obvious.

Before you commission another chatbot, try one thing. Give a trusted consumer agent a real job on your business: find something, change it, cancel it, and pay for it. Watch where it breaks. Every failure is a piece of your next channel strategy.

What happens when every consumer has an agent and your business gives them a terrible experience because that is the channel they chose to use?

Can my agent use your thing?

If it can’t, whose thing will it use instead?

OpenAI’s ChatGPT will have to comply with tougher EU rules such as removing illegal content or face potential fines, the European Commission said on Monday, as Brussels grapples with how its existing digital regulation applies to rapidly evolving AI services.

The Commission said the chatbot, social media forum Reddit, and gaming platform Roblox would be classified as so-called very large online platforms under the EU Digital Services Act, its landmark online safety regime.

The designation means all three services will face additional obligations such as removing illegal content and protecting the privacy and security of minors and could face fines of up to 6 percent of their global revenue if they fail to comply.

The decision marks a further expansion of the DSA into generative AI, with X’s AI chatbot Grok already facing an investigation under the law.

“ChatGPT, Reddit, and Roblox will now be held to a higher standard of scrutiny and accountability in the European Union, in line with their large impact on our citizens and society,” said the EU’s tech chief Henna Virkkunen.

The move comes after all three services surpassed 45 million monthly users in the EU, the threshold for enhanced scrutiny under the DSA. They now have until the end of December to comply with the additional obligations.

A spokesperson for OpenAI said the company was preparing to meet the additional compliance requirements.

Roblox said it was “proud to be the first gaming platform to reach this milestone in the EU” and that “safety is foundational to everything we do and we look forward to continuing our constructive engagement with the European Commission.” Reddit did not immediately respond to a request for comment.

The EU is also starting to enforce its AI Act, the world’s first regime regulating the development of the fast-developing technology. Under its competition rule book, the bloc has also started an investigation into AI services, including whether Google breached EU competition rules in its use of AI overviews.

The expansion of the DSA comes as Brussels faces pressure from Washington over its regulation of US tech companies, including over fines under the law against companies such as Elon Musk’s X. Washington claims the EU is unfairly targeting US groups and infringing freedom of speech principles championed by the MAGA movement.

However, the Commission insists its digital laws apply to companies regardless of where they are based. In July, Chinese online marketplace AliExpress was fined €550 million under the DSA for failing to do enough to prevent the sale of illegal products on its platform.

Google is prototyping a new Gemini Enterprise feature called Rooms, which could turn the platform into a shared workspace where teams collaborate with both colleagues and Gemini around a specific objective. TestingCatalog found references to the feature in recent Gemini Enterprise builds, but it remains marked as a prototype, and Google has not yet indicated plans to ship it publicly.

Rooms are described as an “all-in-one place” environment where Gemini becomes an expert using connected files while keeping team conversations focused. Creating one involves defining a goal, a playbook describing how Gemini should operate, and a knowledge base. Teams can then add members and files, maintain shared context, and communicate with each other or Gemini inside the same space.

The concept appears closely related to Projects, which Google publicly introduced at Cloud Next 2026 as shared workspaces for humans and agents. Projects already combine conversations with sources from services such as Google Workspace, Microsoft OneDrive, NotebookLM, and team chats. Rooms appear to take that idea further by giving the workspace an explicit objective, operating instructions, and a more structured knowledge layer.

For enterprise teams, this could position Gemini closer to project management and operational collaboration software rather than serving primarily as an assistant layered over company data. One particularly useful direction would be connecting context gathered during Google Meet calls with room decisions, documentation, tasks, and ongoing conversations, although there is currently no evidence that Meet integration is part of the prototype.

Google has been steadily repositioning Gemini Enterprise as an agentic workplace platform, with long-running agents, Projects, Canvas, an Agent Gallery, enterprise connectors, and persistent agent memory all forming parts of that strategy. Recent interface changes point in the same direction: the Customization area is being reorganized to include dedicated Agents and Memory sections, with agents potentially moving into a list where users can inspect and configure them.

For now, Rooms remain an internal prototype. Their final name, availability, supported data sources, and whether they will replace or coexist with Projects are still unclear.

How Matic got robots into 10,000 homes

A few months ago I got a Matic, the home robot that vacuums and mops on its own. Last week they shipped voice and gestures, so you can now say “Hey Matic, clean the kitchen” or just point at a spill and Matic handles it. It was almost 8 years since they first demo’ed it internally and a reminder of the demo to deployment gap in robotics.

And with all the discussion around robotics and getting to deployment, Matic is a great company to learn from. They took on a market that already existed but had seen little innovation with a different spin on it and are now shipping American-made consumer home robots at real scale and are in over 10,000 homes.

I had the opportunity to sit down with Mehul Nariyawala, the co-founder and President of Matic, and talk through some of his hard-earned lessons from the Matic journey so far. There are a lot of lessons for anyone building in robotics and frankly beyond it. I’ll cover 7:

1. Start from the customer problem
2. Pick the form factor from first principles
3. Absorb complexity in software
4. A great demo gets you 20% of the way
5. Deployment data is the moat
6. Manufacture for iteration
7. Customers adopt incrementally

1. Start from the customer problem

Mehul’s first company Flutter, which he co-founded with his co-founder at Matic Navneet, let you control iTunes and Spotify with hand gestures through a webcam. It hit #1 in 73 countries, but as he notes it was never going to be a business and was eventually acquired by Google.

“You quickly realize that no one wakes up in the morning and says, today I’m going to buy gestures. It’s a really cool app, but not necessarily a product or a problem.”

What he took from that, and sharpened at Nest, is a filter about which markets to enter. New markets make customers ask “why do I need this?” (GoPro, Fitbit, Vision Pro). Existing markets only make them ask “which one?” Nobody asks why they need a thermostat.

A corollary to that was that the best existing markets are the tedious ones. Nest’s cameras drew 20 competitors within 6 months of launch. Nest’s thermostat, which required compatibility with 50 to 60 years of HVAC systems, went arguably over 15 years without a serious challenger.

Robot vacuums looked the same way to him. 15% of homes owned one and iRobot generated $700M in revenue in 2024 without meaningfully innovating for two decades.

“Our thesis has always been that customers don’t want robots, they want solutions to their problems.”

The temptation in robotics is to lead with the capability, since the capability is the hard part. The filter at founding for Mehul and Navneet was to work backwards from a existing customer problem, and to go after an existing tedious market where the customer problem is established enough that people are already trying to solve it in some way.

2. Pick the form factor from first principles

Matic entered a category where hundreds of products looked identical and were all disc-shaped and relatively low profile, and shipped something that looks nothing like them. Matic has a squarish shape is double the height.

Mehul’s framing for why:

“Form factor is basically a function of what problem we are solving .. Disc robots were built as disc robots because they didn’t have any intelligence. They were literally like a blindfolded robot, bouncing around the room to cover everything.”

A blind robot needs a shape that resists getting stuck, and a circle can pivot on its own axis. Precise 3D vision removes that constraint, which is what let them shape the robot around the job instead. Matic has a square shape so it actually cleans corners and sides. Its cameras sit at the vantage point of a crawling child looking down.

I think this one is particularly apt to many robotics companies today. Many are picking theoretical embodiments without factoring in what is needed to do the job they are trying to accomplish. The form factor matters a lot and should be chosen with the task or tasks in mind, and the trade-offs considered. Questions about whether it should have wheels or legs or be stationary, the degrees of freedom in the arms, etc should not be taken for granted.

3. Absorb complexity in software

Matic made a big bet to approach the problem a la Tesla rather than Waymo. They bet that cameras plus algorithms should be enough. A Matic robot has 5 cameras and the cheapest NVIDIA GPU they could buy, roughly $150 of cost, in the black crown on top of the robot. They felt additional complexity in hardware would make things more challenging to scale:

“A single sensor you add in hardware, assume three software engineers on the flip side. More sensors, bigger the team. More sensors, more calibration. More sensors, more complex the supply chain, higher the BOM cost, more complex the manufacturing. Complexity rises exponentially with each sensor you add. So we made a bet that if you want to build a profitable, economically viable thing, we have to absorb complexity in software.”

This makes things at the start much harder but the scaling much easier. They grinded for a long-time to get the mapping algorithms better, but now benefit from a somewhat simpler hardware and have built up a strong software muscle with a product that continues to get better every few weeks through new features delivered entirely via software updates.

On architecture and approach they’re pragmatic rather than religious. They tried classical SLAM, neural approaches, and hybrids, and kept whatever hit the accuracy bar, which has drifted them steadily toward end-to-end:

“End to end sounds really cool, but you don’t get end to end on day one. You try a bunch of different things and then you figure out what it is, and over time it shrinks into end to end because now you know which techniques work. Otherwise it’s a bit of a mirage.”

4. A great demo gets you 20% of the way

Matic’s first “clean this” gesture demo ran in fall 2018. It shipped to customers last week, almost 8 years later. Mehul’s framing of that gap is a reminder of the gap between a cool demo and getting to production in robotics:

“In software, if you get to GPT-3, ChatGPT is maybe just 20% more. In hardware, if you have a great demo, you’ve basically got 20%. The rest productization takes 5x effort.”

Productization here means the platform, firmware, the operating system, edge observability, end-to-end testing infrastructure, data infrastructure, the app and doing it all reliably.

In Matic’s case, the bar is also high because consumers are far less tolerant of failure on tasks that seem trivial to them:

“We don’t really go to school to learn how to vacuum, or how to hold a glass, or how to fold clothes. These are trivial to us. So the more trivial the task to human beings, the less patience they have for robots to make a mistake. We get an email if a single popcorn is left behind, saying your robot doesn’t work.”

That bar for Matic is about 99% for alpha testing and 99.9% to ship to production. Every company will need to figure out their own bar given their use case but worth remembering that each each additional nine takes roughly the same amount of work as the last one.

5. Deployment data is the moat

I’ve written in the past about the mix of data being used to train and improve robotics models and systems, and Matic also used a mix with now the focus being on their deployment data.

They started in simulation which was very useful while getting going but eventually they needed to get real data in a large number of homes. On sim and teleop, Mehul notes:

“They’re great to get to 80%, but you cannot cross the sim-to-real gap until you have real data. And real data is not about 20 homes or 30 homes.”

Matic took an interesting approach of doing everything-on-device first, and allowing users to opt in to share error clips or manually record certain error scenarios. Now, 60% of customers have opted-in to help Matic improve by sharing error clips, giving them the edge cases / failures they need to improve their systems.

Ultimately, its these edge cases that are most valuable today in improving the product and something you can realistically only get through deployments. In the case of Matic, it involved edge cases on how to handle homes with wall-to-wall mirrors, indoor water fountains, a fish pond set half a centimeter below the living room floor with live fish in it, indoor basketball courts, transparent plastic furniture, and other things that it may not have encountered before.

Those edge cases get labeled within about 3 weeks (sometimes they receive them well curated and labelled too) and go back out as improvements through over-the-air updates, which is how the robot keeps getting better.

6. Manufacture for iteration

Matic assembles every robot in Mountain View. The first reason is speed:

“The moment you have a CM somewhere outside, they are going to need two or three months of notice versus having everything inside in the same place, having mechanical design engineers right next to the manufacturing engineers. The communication and feedback loop is really fast and we can iterate really fast.”

The second is that scale surfaces problems that don’t exist at small volumes. A 1% issue is one robot when you’ve built 100, and a thousand robots when you’ve built 100,000. Owning the line means you find those and fix them in weeks rather than quarters, which is why the product keeps changing while looking identical:

“Externally it’s the exact same hardware but Internally we’re constantly improving the hardware, making it more reliable. We started shipping in November of 2024, and I think now we’re already on a fifth or sixth generation of internal hardware.”

In relation with last week’s launch, the microphones were in the robot from the first unit shipped a few years ago and were ready to be used when the software caught up.

7. Customers adopt incrementally

The obvious question for a home robotics company is why not build the general-purpose robot straight away. Matic’s answer is a very practical one around consumer adoption and feasibility given price.

Mehul quotes Tony Fadell, his old boss at Nest:

“Customers do things incrementally. You cannot get them to leapfrog.”

They felt that customer’s weren’t ready for a >$2000 robot in the home, given how few household purchases cost more than that. Matic knew from the start that the end game was Rosie the Robot from Jetsons or Alfred from Batman. But that wasn’t the right starting point. Instead, a better vacuum cleaner in the home which was an existing market and had customer adoption and could be priced under that $2000 mark was.

Mehul compares it to how JK Rowling wrote the first chapter of the first Harry Potter book and the last chapter of the last one before writing the rest. Matic knew the first chapter (Floor cleaner) and the last chapter (Alfred/Rosie), and will get there incrementally with products along the way.

From a technical perspective as well, they want to do things in sequence, almost modeled on how a child may learn. The goal of the initial Matic robot is to be best-in-class at perception, mapping, navigation and earn the right to be in customer’s homes.

Closing Thoughts

What strikes me most about the Matic story is how little any of this was shortcuts. They took six or seven years to ship, picked a category with very little new innovation and spent most of that time on problems that don’t demo well.

If you’re building in robotics or physical AI, feel free to reach out at tanay at wing.vc. And if you have any comments or thoughts, feel free to tweet at me.

Today we released by far the largest update in the history of OpenClaw. It was built by 933 contributors, including 569 first-time contributors, and is composed of over 16,000 pull requests.

This update touches every part of OpenClaw, including installation, messaging, memory, skills, models, automations, the browser and native apps, plugins, security, and a very long tail of fixes. We started by simplifying installation and rebuilding the browser app as a first-class experience, but doing that properly meant carrying the cleanup through the rest of OpenClaw until it became OpenClaw 2.0.

Why this took nearly two months

Before this update, we had shipped 106 releases in 230 days, most within a day or two of the one before them, so going nearly seven weeks without shipping was not normal for us. The release cadence slowed, but development moved in the opposite direction because our team was growing, and the increased volume and pace of work outgrew both the foundation of OpenClaw and the process we used to ship it, so we reworked both at the same time.

That acceleration left us with a release containing roughly 50% of all pull requests ever merged into OpenClaw, so we took the extra time to make sure it worked for people starting from scratch and people upgrading an existing Claw rather than shipping quickly and handing them an update that broke what they already had.

Getting to a useful Claw faster

Installation was the first place we needed to make OpenClaw easier, so for first-time installs we are starting with what is already on someone’s computer, including existing ChatGPT or Claude subscriptions, API keys, and local models. We cut or simplified a lot of configuration and moved the rest out of initial setup, letting people get to a first conversation faster and finish setting up their Claw by talking to it.

The browser app is where most people meet OpenClaw and have their first conversation, so we rebuilt it as a first-class experience where they can keep setting things up, return to ongoing work, or follow along live when they want to.

How a useful Claw can grow

Your Claw does not need to be complicated, and a simple workflow might have it watch your inbox for your kids’ school emails and send you a Telegram message whenever something important comes through, like homework due or an upcoming activity you need to prepare for. It uses one inbox, looks for a few important things, and sends the result to one place, which is already enough to be useful.

From there, a task can reach across more places without becoming harder to use, so when your brother sends an iMessage asking which iPad you bought for your dad, you can skip searching your email for the receipt and simply tell your Claw that your brother just messaged, then ask it to find the answer and send it to him. The Claw just does it.

The same progression showed up inside our own team while building this release as we used our Claws for more of the work and wanted to share tasks, collaborate on them, and sometimes hand them off entirely. OpenClaw had no way to bring another team member into the work without losing what the Claw already knew. Shared cloud sessions changed that and turned OpenClaw into a multiplayer experience our team now uses to build OpenClaw, bringing the right person into live work or handing it over with the context intact.

What this adds up to

Your OpenClaw starts with one useful workflow and grows as far as you want it to, with the possibility of reaching across more of your life and work or becoming multiplayer with your family or team when you want and how you want. This has changed the relationship people have with software, turning it from something designed somewhere else that you have to accept into something you can tell what to do, shape around your life and work, and actually own.

We are not selling anything here or asking you to trust one company, one model, or one AI provider with that future, because OpenClaw is open source and belongs to the people who use it and help build it.

The Future Tech Role Is the Product Architect

TL;DR: Coding is moving from humans to agents. As agents get better at implementing, testing, and reviewing software, the human role moves toward deciding what should be built, defining how the system should work, and verifying the result. The person who owns all three is the product architect.

Software teams are built around the assumption that writing production code is expensive.

A product manager decides what should be built. A software architect decides how the system should work. Engineers then spend weeks or months implementing it.

This separation made sense when implementation was the slowest part of building software.

It isn't anymore.

Agents are already writing real production code. OpenAI built an internal product without humans manually writing a single line of code. In five months, a small team using Codex produced roughly a million lines of code and merged around 1,500 pull requests. The agents wrote the product, tests, infrastructure, and internal tools. The humans defined what needed to be done and checked the result. OpenAI describes this as: humans steer, agents execute. Cursor is already talking about fleets of agents that plan, build, test, monitor, and maintain software.

This is not just a faster way to write code.

It changes how software teams should be organised.

You are now the bottleneck

If an agent can build a feature in a few hours, but it takes three days to decide exactly what the feature should do, implementation is no longer the bottleneck.

You are.

The product manager writes a requirement. The architect turns it into a system design. The engineer finds the gaps. Questions go back through the chain. Meetings happen. Documents get updated. Meanwhile, the agent could have built and tested several versions.

Giving every engineer a coding agent does not solve this. You get faster code production while keeping the same slow decision process around it.

Someone still needs to decide:

• What problem are we solving?
• What should the product actually do?
• How should the system work?
• Which trade-offs are acceptable?
• How do we know the result is correct?

If those decisions remain split across multiple people and handoffs, the company will still move at human coordination speed.

When implementation becomes this fast, product and architecture can no longer remain completely separate. The person deciding what should exist also needs to understand the system in which it will run.

That person is the product architect.

The product architect

A product manager decides what problem should be solved.

A software architect decides how the system should be structured.

A tech lead coordinates how engineers implement it.

The product architect owns the whole loop.

They understand the problem, decide on the solution, design the system, set the constraints, direct the agents, and verify what gets built.

On the product side, they define the outcome, requirements, priorities, use cases, failure conditions, and acceptance criteria.

This does not mean writing a huge product document for every change. A simple task may only need a clear instruction. A complex feature needs a proper specification. The level of detail should match the complexity of the task.

On the architecture side, they decide the database, infrastructure, data model, APIs, system boundaries, security model, scaling strategy, and other choices that affect how the product works or what it can become later.

Architecture sets the constraints within which agents work.

The human decides the system-level choices. The agents decide how to implement them in code.

An agent can choose the functions, classes, libraries, algorithms, and internal patterns it needs. But data ownership, security boundaries, and scaling strategy shape the product. Those decisions belong to the product architect.

The specification also becomes more important because it is no longer just a document passed to another person. It becomes an input the agents directly work from. Other agents can then use the same specification to test and review what was built.

The same applies to design. A designer sets the colours, typography, components, interaction patterns, and platform rules, then reviews the product from time to time. Agents can build individual interfaces without inventing a new design system for every feature.

The agent team becomes the product architect's toolkit.

Engineers have always shaped personal workflows around editors such as VS Code or PyCharm, along with terminals, plugins, and scripts. Product architects will do the same with agents.

One agent may implement a feature. Another may test it. Another may check security and architecture. Another may deploy it and verify the workflow.

There is no fixed agent team that works for every product. The roles depend on what is being built. But each agent should have a clear responsibility, and the agents should be able to work together without asking the human to manage every small handoff.

Grok Bot is an early example of this. You can create persistent bots, give each one a job, run them in parallel, and let them pass work between themselves. They keep context and return when they need approval.

Now apply the same model to software development.

You could have specialised agents for implementation, testing, review, security, and deployment. They escalate only when a decision changes the product, architecture, or acceptable trade-offs.

Working with agents will become a core part of the job. Each product architect will decide which agents exist, what they own, which tools they can use, what context they retain, and when they should return to the human. That working relationship will improve as the agents learn the product and its architecture.

This is still a hands-on role.

The product architect is not someone who draws a few diagrams and disappears. They work with the agents every day: clarifying requirements, testing features, correcting specifications, making trade-offs, and updating constraints.

They may stop typing most of the code. They do not stop building.

The way humans review work changes too.

Today, agents write a lot of code and humans review it. As models improve, agents will also run the tests, review the code, find bugs, and fix one another's work.

This does not mean code stops being reviewed. It means humans stop being responsible for code-quality review.

Humans review the functionality.

They use the feature, test the complete workflow, verify the important use cases, and check whether it solves the intended problem.

The pull request becomes less about a diff and more about a working product increment. It should show what was built, how it was tested, and where the human can try it.

Well-tested production code is not code with a lot of unit tests. It is code that works functionally, handles the expected use cases, and satisfies the product and system constraints.

That is what the human verifies.

Fast implementation also changes how much time we should spend debating reversible decisions.

If an agent can build a version today, test it, scrap it, and build another one tomorrow, we should do that. We do not need to discuss for three weeks what can be tested in a day.

But not every decision is reversible. Data ownership, security, compliance, infrastructure foundations, and long-term platform choices still need careful thought.

The product architect needs to know the difference.

Build teams around judgment

The product architect is not half a product manager and half a software architect.

The role needs enough product depth to define the right outcome and enough technical depth to design the system that can deliver it. The point is not to combine two roles and do both badly. The point is to remove the gap between them.

This is the natural next step for senior engineers, tech leads, technical founders, and engineering leaders working with agents. Their value will come less from how much code they can personally produce and more from how well they can turn an ambiguous problem into something agents can build and verify.

Founders and engineering leaders should start changing how they build teams:

• Stop measuring engineering mainly through code output.
• Find engineers who have both product judgment and architectural depth.
• Give them ownership from problem to production outcome.
• Build agent workflows with separate implementation, testing, review, and validation responsibilities.
• Invest in product specifications, architecture constraints, design-language documents, and functional testing.
• Review working products, not only code diffs.

Companies that simply give every developer a coding agent will produce more code.

They will miss the bigger change.

Code is becoming abundant. Good judgment is not.

The future will not belong to the person who can produce the most code. Agents will win that contest.

It will belong to the person who can decide what deserves to be built, design the system that should contain it, and lead agents from intent to a verified outcome.

That person is the product architect.

A while ago I accidentally reinvented Nostr. Off the back of that article, from comparing the most popular decentralized protocols in detail, one sentence kept spinning in my head: There is no such thing as full decentralization. There's always an axis that centralizes.

Let me explain. In any network there are five places where power can pile up:

• identity: who you are
• connectivity: how messages get from one node to another
• discovery: how new people find you
• cost: who pays for storage and bandwidth
• moderation: who decides what is shown and what is hidden

Moderation deserves its own article, so I'll leave it aside today. I'll talk about how data moves and is stored.

Every network that sells itself as decentralized ends up putting a single point in one of them. So the useful question is not "is it decentralized?", but: which of the four did it sacrifice, and what does it cost you the day that point breaks?

Take the networks people actually use and the pattern repeats.

Mastodon truly federates. Servers talk to each other over ActivityPub, with no mandatory relay. Its single point is identity: your account lives on an instance, and if it closes or bans you, you lose it. There is follower migration, but it is neither automatic nor perfect. And on top of that, mastodon.social concentrates half the network by pure snowball effect.

Nostr solves identity beautifully with a cryptographic key, not an account on anyone's server. You switch relays without ceasing to be you. But the bill reappears in cost and replication. A 2024 study measured it and found that each post is copied on average across 34.6 relays, 98.2% of download traffic is waste (144 TiB thrown away) and 95% of the free relays do not cover their costs. Infrastructure as fragile as the one it claims to replace, with a cost time bomb underneath.

Bluesky distributes the protocol on paper, but in practice the relay and the AppView that index the whole network are run by Bluesky, and standing up your own is very expensive. Its single point is the infrastructure, since the network depends on that aggregator to work.

And Org Social, mine, does not get away either. It wins on zero replication and a ridiculously low hosting cost (it is a text file), and backing up your identity is copying that file. That said, your identity is your URL, so it is truly yours only as long as you control the domain; if you host on someone else's place, you depend on them again, like on Mastodon. But discovery still goes through the Relay. If you do not know someone's URL, you find them there. And if the Relay goes down, the experience suffers, unless you already follow every user on the network (which nobody does).

Federated messaging, Matrix and XMPP, does not get away either. Like on Mastodon, your account lives on a homeserver or a specific server, and if that server closes, you are left without it.

If we put it all in a table:

✅ distributed | ❌ single point

So next time someone tells you their system is decentralized, don't argue; ask them about the sacrifice, and think about whether you are willing to pay for it.

Sources

• Empirical Analysis of the Nostr Social Network, the 2024 study with the figures on replication, costs and wasted bandwidth.
• ActivityPub, the W3C recommendation: inbox delivery, no mandatory relay.
• AT Protocol, Bluesky's protocol: federable in theory, with the aggregation (relay and AppView) run today by Bluesky.
• Matrix and XMPP, federated messaging with identity tied to your server.
• Secure Scuttlebutt, a P2P social network that leaned on "pubs" for discovery.
• Org Social, the specification of my social network in a plain text file.

Every morning, while my family gets ready for the day, we have KQED on throughout the house. Proud members since 2000. Then I listen to podcasts while I work out. Either way I am half listening, the way you do, attention drifting between whatever is playing and planning for the day in front of me.

Last week I caught a segment about frontier models, and I could not tell you now whether it was the radio or one of the podcasts. The speaker was talking about pricing and performance, I think in relation to the new GLM model. Then he started talking about cars, and I stopped half listening. These frontier models are Ferraris, the argument went. Most people don’t drive a Ferrari. Most people drive a Corolla.

I have spent a lot of time over the last few years building agents that run on Corollas. Last year I built a coding agent on Gemini Flash 2.5, mostly to find out whether I could get really good performance on a lightweight, less expensive, and faster model. Lately I have been working with Chris on Pepper, a personal assistant for your life. Pepper runs on Corollas too.

That line stuck with me throughout the day. I mentioned it to Chris on a call the next morning, and he tied it back to one of my previous posts, the chat box is a detour. He was right: they are the same argument at two different layers. That post said we handed consumers the wrong interface because a chat window was the honest expression of what models could do in 2022, and then we never revisited it. This is the same mistake one layer down. We build on the frontier tier because that is where the attention is, not because the work requires it.

What Our Product Actually Runs On

At Vycari we are building agents that handle the day to day, and Pepper is the first one. Almost all of its agentic work runs on the cheapest models the big labs sell. Orchestration goes overwhelmingly to Gemini Flash Lite 3.5, with small slices of Claude Haiku 4.5 and GPT-5.6 Luna routed alongside it to keep us honest about vendor lock-in, and to give us a baseline for our own evals. Somewhere around a hundred and fifty million tokens have gone through the system for about forty dollars, which starts looking like a rounding error once you notice that an Opus-class harness can spend forty dollars in minutes.

The work those models do is not exotic. Look at a calendar. Read an email and decide whether it needs a response. Manage my exercise log, or find my to-dos. When I wrote about how everything becomes an agent, the point underneath was that an agent brings value by deciding in the moment, with real input in front of it. Most of those decisions are small. If you were hiring a person for this job, you would not start out looking for a PhD.

That changes the shape of the pricing conversation. For a lot of use cases we have been standing in the Ferrari showroom asking for a deal, when the better move is to walk down the street to the Toyota lot. The question was never how to get the frontier tier cheaper. It was why we were standing in that showroom at all, holding a list that reads: check the calendar, read the mail, log the workout.

The Objection I Keep Hearing

I have heard the objections. Small models hallucinate. They report success on work they never did. They narrate a tool call as prose instead of calling the tool, and the turn ends clean with fabricated content sitting in it. I have watched all of that happen in production.

The objections come out of real experience, and they were true recently enough that I understand why people still reach for them. But this industry is moving so quickly that we often have to check our assumptions on the models that are available today. The cheap tier climbs about a rung a year. The lite model I run today does work that belonged to the mid tier a year ago, and that mid tier was doing work the frontier owned the year before that. The objections have not been updated since the last time they were correct.

So we ran a quick eval. Nine recorded production turns, one for each failure shape our nightly reflection kept filing, replayed against three tiers: the lite model we ship on, the mid Flash model, and Pro. Fixed thinking budget, three samples per arm, and a grader from a different vendor so we were not asking Gemini to mark Gemini’s homework. I expected a ladder. What came back was flatter than that.

That is a small eval and I am not going to pretend otherwise. What I can say is that we have now watched the platform across thousands of model calls, and what the eval showed is holding up. We are not a public product yet, so the data is thin and I would not ask anyone to take it as settled. But every time I take one of our failing cases from Flash Lite and hand it up the ladder, the results refuse to move the way I expect them to.

The headline in our own experience is that this is mostly about how a model handles missing data, not how big it is. When a tool returns real data, all three tiers ground correctly and nobody invents anything. When the data is not there, behavior splits on how the absence gets signalled. Replay a turn with a vague instruction to proceed with whatever it already has, and all three fabricate confident content, with the bigger models producing the more polished fabrication. Signal the absence clearly, and every tier including lite says it cannot see the calendar instead of inventing events.

That reorganized how I think about the problem. The fabrication I had been charging to running cheap was mostly a property of how we told the model it had nothing. Our first recommendation to ourselves was to stop shopping for a bigger model and go fix the signal.

Which puts the weight on the harness instead. The harness manages the context, decides what the model sees, and decides what it is told when a tool comes back empty. Its entire job is to put the model in a position to succeed. Get that wrong and no amount of model will save you.

Two other results fell out of it. The first is a failure where the answer is correct and well-grounded all the way through, and then comes apart in its last few words. A phrase repeats itself, or a contraction mangles. One of ours signed off with “while he recovers today while he recovers.” We call it a garbled tail, and nothing in the logs flags it, because the model finished cleanly and the turn reads as a success. It showed up on every model we tested including Pro. Low rate, stochastic, and scaling did nothing to it.

The second is that the middle is not the safe middle it looks like. On empty tools the mid tier invented more concrete detail, weather numbers and times, than either the model above it or the one below.

There is one clean exception. False completion, where the agent answers after step two of a five-step procedure and reports back as though it had finished, does improve with model size. Our own notes call it the one real model-size win, and it is the only one on the list.

I want to be careful not to oversell this, because we do pay a tax for running small. Ten modules in Pepper’s agent harness exist mostly to catch models behaving badly, roughly 2,500 lines of production code and about the same again in tests. A detector for tool calls narrated as prose. A repair pass for garbled text. A guard for the case where a tool returns a success status with a zero success count buried in the JSON, which we wrote after a model read the status, believed its own plan, and invented the record IDs out of its own request.

Six of those ten ship detect-only. They watch, they report, and they change nothing a user sees, because we do not ship a pass that suppresses model output until nightly grading proves it is effective. The failures they watch for are not exclusive to the tier we run on. Most of that code is the cost of building an agent at all, and we would be writing a version of it at any price.

None of that machinery came out of a design document. It came out of watching. Every night a high-capability model, a Ferrari, reads back every task Pepper took on that day and grades it. It correlates failures to bugs, files the issues, sometimes reproduces a failure as a failing test, and sometimes opens a pull request to fix it. That process deserves its own post and it will get one. The short version is that almost every guard in our harness exists because we watched the model fail in one specific way and wrote a defense against that one failure.

So the Ferrari does have a job here. It is just not the one that answers you.

We Don’t Have a Word for These Models

This is a naming problem, and I think it matters more than it sounds. “Small” is wrong, because the capability is not small. “Cheap” is pejorative and smuggles in the assumption I have spent this post arguing against. “Flash Lite class” is a product SKU, not a category. Nobody has named this tier because nobody is positioning for it.

I want to call them daily drivers.

A daily driver is not a lesser car. It is the car you actually chose, judged on what matters when you drive it every morning. It starts. It’s cheap to run. It does the trip. Nobody apologizes for driving one, and nobody seriously believes the Ferrari owner is having a better time getting the groceries home.

The capability question is already settled, and I published the evidence three months ago while thinking I was writing about something else. When I built a scoreboard for Gemini Scribe, my Obsidian plugin, the point was to stop grading my own agent on vibes. It scores reliability the way τ-bench does, so a task counts only if every one of five runs succeeds. The headline result, which is still published, was that the newer gemini-3.1-flash-lite solves 74.1% of that suite at solve^5 and the older gemini-2.5-flash, supposedly a tier up, solves 57.4%. Same tasks, same judge, about seventeen percentage points apart, and the lite model costs about three quarters as much per run.

Speed is part of this too, and it does not show up anywhere in a solve rate. The daily driver starts talking sooner, and the gap in time to first token is not subtle. For an assistant you are holding a conversation with, that is not a nice-to-have. It is most of what the thing feels like to use.

The Price Gap Is Widening, Not Closing

The objection I take most seriously is that all of this evaporates when frontier prices fall. If the Ferrari costs Corolla money, what is left of the argument?

Watch what actually happened this summer. OpenAI cut Luna’s price by 80% on July 30 and took 20% off the mid tier. Those are their numbers, and the same announcement adds one more line: Sol pricing remains unchanged. Three weeks later they cut Sol too, and on their own product page that second cut is described as running for the next three months.

Read the two together. The cut at the bottom is the price. The cut at the top is a sale with an end date on it. At launch the flagship cost five times what the cheap tier cost, on input and on output alike. Take the promotion out and it now costs twenty-five times, which is where the ratio lands again when the sale lapses in November.

The gap widened because the floor dropped, not because the ceiling rose. The research says to expect that. An MIT FutureTech analysis of the price-performance frontier puts the decline at five to ten times a year for a fixed level of capability, with roughly three of that coming from algorithms rather than hardware. A five-dollar subscription does not need the gap to hold still. It needs the floor to keep falling, and the floor is where the competitive energy is.

Where Cheap Doesn’t Save You

Inference is not the whole bill, and this is the part I would have wanted someone to tell me a year ago.

Grounding costs real money and it does not follow the same curve. Google gives you 5,000 free search requests a month shared across all the Gemini 3.x models, then charges $14 per thousand after that. Anthropic and OpenAI both charge $10. On a deep research task, where the agent fires dozens of queries to answer one question, the search line can run past the inference line. That inversion gets worse as tokens get cheaper, not better.

The other place the rule breaks is writing skills. A lightweight model asked to author its own procedure does it badly, and the failure is subtle. It writes instructions a smarter model could infer its way through. So our skill-authoring tool runs on a bigger model than the runtime it writes for, and the skill’s own instructions spell the asymmetry out to whatever is drafting. What you write will be executed by a lower-capability model than the one drafting it now. So be pedantic. Name the exact tool and its arguments, and do not leave a judgment call implicit. Vague instructions are instructions a smaller model will fumble.

That is the boundary in general. Reach up a tier where the output is a plan that gets reused, and stay down where the output is one decision that gets made and thrown away.

The Part I’m Most Excited About

The strategic argument for running this low is that it eventually stops depending on the labs at all. At this size there is a real path to fine-tuned open weights, and past that you are substantially immune to price hikes and can buy your own hardware.

I believe that, and I have not proved it. The abstraction is there: Pepper’s model layer is provider-neutral and already routes three vendors through one interface, so a fourth backend is a translation adapter and a route key rather than a rewrite. What is not there is a single line of code pointing at a local runtime.

When I did measure it, the answer was no, and I published that too. The local gemma4:e4b running on my own hardware clears the easy tier at 100% and then collapses: 15% on T2, 7% on T3, 11% on T4. Flash Lite stays above 65% on every tier. It almost always finishes without erroring. It just gets the answer wrong.

That is one very small model, well under what a single consumer GPU could hold, and I have not put the larger variants through the same gradient. With capable dense models now shipping in the 30-billion-parameter range, that gradient is the next thing I want to run.

A Different Company, Not a Cheaper Bill

Cheap orchestration is what makes a five-dollar subscription possible. A five-dollar subscription is what makes Pepper reachable by the people I had in mind when I wrote that not everyone wants a hobby. That is the whole thesis, and the model tier is critical to it in a way a line item on an infrastructure bill never is.

Chris’s read on the field is that most people building here run on higher-grade models, which is a large part of why they need venture money. They are burning tokens on work that does not require them. I don’t think anyone made that choice on purpose. The frontier is where the demos are, where the benchmarks are, and where the attention is. It takes a deliberate act to go shopping somewhere else.

There is an argument running right now about whether we are heading for superintelligence and what it will mean when we get there. It is a real argument and I am not dismissing it. It also has almost nothing to do with the software most people will actually use, which needs to read a calendar, check the weather, and then get out of the way. That job was solved a while ago. We just kept pricing it as though it were not.

Whoever it was I was half listening to had it right, and did not go far enough. Nobody needs a Ferrari to get to work. What nobody says out loud is that the Corolla gets faster every year while we are all reading the reviews of the Ferrari.

Anthropic has signed a cloud-computing deal with Lambda, which is backed by Nvidia, with Nvidia itself holding the lease on the data center.

Full article content is not available for inline reading.

Read the original article →

The Custodial Era of UX: Cleaning Up After AI

We are entering the custodial era of UX. In this era, AI makes it possible to generate content, prototype, vibe code, and build working features much faster than before. This newfound speed is valuable, but it also leads to UX debt when teams haven’t taken the time to understand, evaluate, or refine their AI output.

In many organizations, UX is therefore encountering work later in the process: a prototype already exists, an AI-generated feature has already been added, or a workflow is already in production. The work is less about “designing from a blank page” and more about “deciding what from AI to keep and what needs to change.” That is custodial work. Luckily, UX is good at bringing structure to chaos and evaluating what actually matters for users, and those skills are important when production moves faster than traditional UX processes.

Ship Fast, Clean Up Later

You’ve probably experienced this type of cleanup work before. When teams move directly from an idea to a plausible-looking artifact and experiences are created through “vibes” or intuition, it’s easy to postpone foundational UX questions about user behaviors or whether features should exist at all. The result can be:

• Interfaces that “technically function” but are unnecessarily confusing
• Copy, graphics, and audio that are so obviously AI-generated that they become awkward distractions (and reputation killers)
• AI messaging that overwhelms the core value proposition, leaving users unclear about what an organization, product, or feature does
• Products overloaded with “smart” functionality that adds complexity but solves few real problems
• Teams optimizing for speed, demos, and stakeholder excitement instead of usability
• Features built because they could be built, not because users wanted or needed them

AI-generated or AI-assisted work isn’t inherently bad. The problem is that production has become cheaper than UX evaluation. It can now take less time to create an experience than to decide whether that experience is useful, usable, trustworthy, or coherent.

Rushed AI-Assisted Production Creates UX Debt

AI can generate 5 versions of a workflow in an afternoon, but deciding which one actually helps users requires understanding:

• User goals and emotional context
• Cognitive load and mental models
• Accessibility and inclusivity needs
• Interaction design and costs
• Information architecture and findability
• Trust and credibility
• Usability heuristics and cognitive biases
• Organizational needs, workflows, and edge cases

When evaluation does not keep pace with implementation, teams accumulate UX debt: the resulting experience may work well enough to demo or ship, but user confusion and degraded trust surface later. Shipping something quickly is not the same as creating something useful.

Some problems become apparent only when users try to use the feature in the context of their real lives, and the confusion, abandonment, support requests, or workarounds start to surface.

AI can also exacerbate issues unrelated to the technology itself. When teams communicate poorly, follow a broken process, or make abrupt, poorly informed decisions, flaws in the design get built and shipped more quickly. AI makes teams faster but also makes their messes more consequential.

The Custodial Pattern

Many organizations and teams are now running through a custodial pattern:

1. New idea: A team identifies an opportunity, feels pressure to respond to momentum in the market, or simply to use AI.
2. Rapid production: AI tools make it possible to prototype or implement ideas very quickly.
3. Lagging UX evaluation: Because the results look good, teams skip user research and investigating “Should this even exist?” and move directly to “How quickly can this be shipped?”
4. User-experience problems: User confusion, support needs, weak adoption, or other signals indicate issues that were not obvious in the prototype.
5. UX cleanup: UX is asked to evaluate, simplify, repair the experience, or help decide what to keep.

This pattern can occur even in organizations that value UX and normally involve it in product development. Because AI makes it so quick to build things, even these teams can find themselves with a working feature without taking the time to assess its value and usability.

UX as the Custodian

In this environment, UX practitioners are:

• Translators between hype and reality, triaging what deserves attention first
• Evaluators of whether AI improves workflows for users
• Simplifiers of overengineered experiences and interfaces
• Advocates for user understanding and control
• Researchers uncovering where the quickly generated designs create friction
• Editors of generic, unclear AI-generated content

The custodian role can feel frustrating, especially when UX is brought in only once the experience has become difficult to use. But this role can also create leverage by teaching organizations how to prevent the next mess. That involves three types of work:

1. Building shared judgment about what gets built: evaluating the rapidly produced experiences and making the reasoning behind those decisions transparent, so teams learn to distinguish what can be built from what should be built.
2. Adapting UX evaluation to the new speed of production: creating faster ways to assess the UX of rapidly produced prototypes or features, without abandoning user data and UX principles.
3. Adding UX to the generation process: adding meaningful, vetted UX and design guidance to the AI tools used for content and prototype generation so that what gets generated starts from a stronger UX foundation.

UX practitioners who combine foundational UX expertise with practical AI literacy are well-positioned to carry out this type of work.

How to Work During the Custodial Era

Simply asking teams to give up on using AI to generate prototypes and content is unlikely to work. If AI tools are available and fast, people will use them. UX cannot rely on teams giving up this technology entirely and reverting to standard, well-established user-centered processes.

Instead, UX needs to preserve the ability to provide design input while changing how and when this input is provided. Even if the original process changes, the questions it was meant to answer should still be addressed, even as production moves faster.

1. Build Shared Judgment About What Gets Built

A working prototype can easily move the conversation from “Do we need this?” to “How soon can we ship this?” UX should help teams distinguish buildability from usefulness and recognize that shipping a feature quickly is not the same as improving the user experience.

When you receive an already built AI-generated feature, don’t start right away by polishing it. Triage it first and do a cost–benefit analysis. Ask yourself:

• What problem does this feature address, and what evidence do we have that this is a real user need?
• How important or frequent is this problem for users?
• How does the feature fit into users’ current mental models and workflows? Does it duplicate an existing path, replace it, or introduce something new that people will have to learn?
• How does it fit in the current systems in your organization? Would its seamless integration require a lot of work or changes to what you already have?
• What costs and risks come with this feature, for both the users and the business? Think about added complexity, as well as added support or maintenance costs. Consider the opportunity cost of redesigning other parts of the experience around a feature that may not be useful.

The most important question is still: “Does this improve the user’s experience?” Not: “Can we technically build it?”

Push back on refining features nobody needs. The outcome of triage is not always “redesign it.” You may keep a feature, simplify it, integrate it into other flows, postpone launching it, or remove it. Your work is to help the team decide what’s worth saving.

Even if you think that a feature may be worth pursuing, stay vigilant for any extras that add unneeded complexity and edit mercilessly. Messages that obscure the core value? Redundant controls? Duplicated workflows? All of these should be removed rather than improved. Look out for these common AI pitfalls and edit them out.

Questioning what gets built is ultimately a form of UX education, and triage should yield more than a decision; it should also produce a lesson for the team. Explain why the feature works or doesn’t, so the rest of the team learns how to apply the same UX criteria to the next idea. Over time, this builds shared judgment rather than leaving UX as the only group responsible for spotting problems.

2. Make Evaluation Keep Up with Production

If AI enables the rapid production of prototypes and new systems, then UX must adapt its processes to the new rhythm. The answer is not to abandon users’ needs or to just trust the prototype. Instead, it’s to find ways to evaluate, triage, and discard prototypes more quickly.

Research doesn’t have to become a bottleneck for evaluating prototypes. Match the evidence to the risk involved: a low-risk feature may warrant quick user tests, a new high-stakes workflow may warrant more rigorous (and time-consuming) methods.

UX teams can also build infrastructure to speed up user research. For example:

• Maintain a user panel or use another rapid-recruiting mechanism to help you test promising prototypes.
• Use AI to accelerate the mechanics of setting up or analyzing a user study. Drafting research plans or screeners, scheduling sessions, and analyzing and reporting data can be sped up with AI. (But don’t substitute real users with synthetic ones, and keep researchers responsible for data interpretation and conclusions).

You can also build tools to speed up design evaluation, even in the absence of user research (or before any). For example:

• Create a standard evaluation template with questions that any design should address. Include things like the user value and problem solved, tasks that can be sped up with the design, and explicit validation criteria.
• Create checklists or heuristics lists including criteria specific to your organization (e.g., accessibility checks, content guidelines) and use them to quickly evaluate designs. See if an AI tool could help you check designs against these.

3. Add UX to Generation

The best way to reduce cleanup is to build UX knowledge into the design-generation process from the start. If the same UX problem repeatedly appears in AI-generated artifacts, then it’s more efficient to instruct the AI to prevent this problem from the start, instead of redesigning every single output. In other words, incorporate what you learn from the cleanup back into the generation process.

Work with your team to capture the design and UX knowledge within your organization and use it to inform AI-generated work. This could include:

• UX-context files (such as Design.md or UX.md) that capture relevant UX principles and guidance for the model.
• A design system and a set of approved interaction patterns so the AI system relies on legitimate building blocks.
• Clear content and formatting standards
• Accessibility requirements
• Known deceptive patterns that should be avoided

This type of guidance needs to be actively maintained and updated with new insights you derive from your continuous evaluation of interfaces or from working with real users.

From Janitorial Work to Custodian of User Needs

One meaning of “custodian” is the person who cleans up the mess. UX may spend more time in that mode as organizations learn how to use AI responsibly and as rapidly generated features accumulate UX debt.

UX work should not, however, be reduced to janitorial work forever. By turning lessons from cleanup into shared product judgment, faster evaluation, and better generation, UX professionals can influence the process earlier and help prevent the next mess.

The word “custodian” has another meaning: someone entrusted with the care of something valuable. In that sense, UX will remain a custodian: not of the mess created by AI slop, but of the real users’ needs.

UX does not need to protect an old process for its own sake, but it does need to protect what that process was meant for: technology centered on human needs. Whether people interact with that technology directly or delegate the interaction to an AI agent, UX’s custodial role is to make sure that what gets built serves human needs.

Happy cleaning, for now.

Adobe added a conversational AI Assistant to Photoshop, Illustrator, InDesign, Premiere, and Frame.io in June 2026, automating multi-step production tasks like batch resizing and background removal. Illustrator's Text to Vector tool generates genuinely editable SVG paths rather than raster images, a capability no major competing AI tool offers.

Design’s Legibility Gap

Strap in. This one gets wonky.

For some personal work, I'm unpacking the question, "What are the conditions that enable a humane organization?" Emerging from that effort is the concept of 'legibility,' and I believe it to be crucial to understanding why UX/Design struggles within so many organizations.

Stop me if you've heard this one

"Design slows us down."

"What's the ROI of design?"

When you're asking for budget: "You want to talk 10 people? We already know what our customer wants."

When you're presenting your findings: "You only talked to 10 people? How is that credible?"

"Can you just make this idea look good?"

UX/Design is often received in an annoyingly reductive fashion. In response, we either try to contort our work to others' expectations, or waste spend a lot of time 'educating' people.

But what's at root here isn't simply a communication challenge—it requires a fundamental understanding of the functions within a business, and the work that gets 'seen.'

Legibility

I'm using the concept of legibility established in the seminal sociopolitical text Seeing Like a State, by James C. Scott. His signature example is (bear with me!) scientific forestry in eighteenth-century Prussia and Saxony, where the state sought timber revenue and so saw the forest only in the metric of "board feet." Anything else (the undergrowth, deadfall, and countless inhabiting species) had no bureaucratic visibility. The state remade the forest to align specifically with that metric: irrelevant species cleared, trees planted in ordered rows. While the first generation grew beautifully, the second collapsed, because those illegible parts had been what kept the forest alive.

Where the forest had "board feet," UX/Design has "screens to be built by engineering." All of the work that ensures that those screens are the best that they can be — qualitative research, sketching, ideation, iteration, structuring, mapping, conceptual modeling — is illegible, and thus invisible to the broader organization.

This is not some fault of design, but instead reflects the values of business operations. Organizations value predictability, so that they can plan, budget, and communicate likely outcomes to their stakeholders. Predictability requires determinacy, where the nature of the work (its processes and outputs) are understood ahead of time—engineering will take 6 weeks to work through these Jira tickets; marketing will spend $50,000 to draw this amount of traffic. Determinacy in turn defines legibility, the qualities of work that can be seen, appreciated, valued, and accounted for.

Much of UX/Design work is indeterminate, and thus illegible. Examples include:

• You explore four concepts and choose one. The three abandoned efforts are invisible, and you're asked why you didn't just start with the workable one.
• Research reveals the requirements were misguided, so you reframe them around actual customer need. The roadmap retains the same name, so it appears nothing has changed.
• You draft the experience principles that will inform hundreds of downstream decisions, but none of which will be traced back to them.

How did it get this way?

There are historic reasons to explain why UX/Design is uniquely illegible. When you consider other functions within a business—engineering, marketing, sales, finance, operations—they evolved in parallel alignment through the gauntlet of business rationalization, becoming part of an MBA curriculum, standardized through measurement, systematized in their practices, and adopting similar languages and concepts of models, pipelines, funnels.

Design was never rationalized in such ways. UX/Design is a highly synthetic practice, drawing on information and communication design's studio tradition, HCI, information science, the social sciences, and human factors engineering. Each has its own hard-won rigor, but because none of them passed through the business rationalization project, these perfectly sound practices are illegible in the corporate context.

The fundamental disconnect

For most business throughout the 20th century, it didn't matter that the work of design was largely indeterminate, because it was mostly performed by agencies and consultancies, special-purpose organizations where indeterminate work was legible.

In the 21st century, as most businesses became, at least in part, software businesses, the bulk of UX/Design work shifted in-house. With rare exception, this integration has been awkward. UX/Design people didn't fully understand that when the business said "we need design," the business didn't mean human-centered problem-framing and problem-solving practices that shape how the business engages its customers. Those practices are indeterminate and thus illegible. The business sought determinate, and thus legible aspects of design: the creation of software screens and, perhaps, conducting usability tests.

This explains why UX/Designers are told that they are "slowing down" the work. This explains why UX/Designers are more frustrated and less satisfied than their peers, why they are the most likely to discourage others from joining their field. This explains why "The ROI of UX" is a fool's errand. This explains why recruiting and hiring practices for UX/Design are broken in most companies, and why corporate career frameworks are clumsy fits. And, ultimately, it explains why we're seeing UX/Design recede in so many companies.

Design Leadership as Legibility Lens

I have long contended that design leadership is more difficult, or at least meaningfully different, than other functional leadership, and I now see legibility is the root cause. Other functions share a rationalist, MBA-honed worldview, and so while their practices may be distinct, their legibility is much higher.

In my Design Leadership Demystified masterclass, I introduce the concept of "mediating the membrane," where design leadership lives at this interface between their team and the rest of the organization. Another way to look at this is that design leadership is a legibility lens, making the work of their team legible within the corporate context, while also making the corporate context understandable to their team.

This legibility frame illuminates a potent detail that had escaped me. Where in the past I argued that design leadership is about translation and connection, the real work is subtler and actually much more difficult.

If we want UX/Design to avoid the fate of the forest's second generation, the real work of leadership is to evolve what businesses see as 'legible.' We need them to widen their aperture to appreciate the value of indeterminate work, which is open-ended, exploratory, emotional, meaningful, even beautiful.

In short : The frontier AI market is segmenting from both ends of its supply chain. Rationing programs & export limits decide who may run the strongest models. Downstream, enterprises standardize on one or two named vendors, & products ship with a default model inside.

The frontier AI market is sorting itself into closed camps, as labs pick partners, cut rivals, & ration access to their strongest models.

Salesforce chose Anthropic as its dedicated AI partner, making Claude the default model inside the world’s largest CRM & Slack. OpenAI cut Cursor’s API access on November 12 after SpaceX bought the company, citing prior contract breaches. Even the open weights models now impose gates : Z.ai released GLM-5.3-Flash under an MIT license on August 26 & put its flagship behind a $10b host-revenue review two days later.

Anthropic started the pattern this summer. Mythos 5, its strongest model, now ships only through Project Glasswing, a program that rations certain capabilities to trusted companies.

Fable, its sibling, went dark outside the United States for three weeks, then returned to US-only inference.

OpenAI made the mirrored choice, launching its government-facing GPT-5.6 variants to a small group of trusted partners before any public API. Governments are getting in on the act, deciding who may run the frontier at all.

Salesforce hardcoding Claude is de rigueur ; SaaS apps pick their components & pass them on a single app to the customer : take-it-or-leave-it.

The pluggable, model-agnostic ideal lived primarily in coding tools where developers expected to swap backends at will.

Enterprise buyers face an escalating governance challenge : strict Zero Data Retention policies, data sovereignty mandates, & an increasing wariness of sending their IP out the door in prompts. When platforms hardcode a single provider’s models, buyers must negotiate for leverage to be able to change it.

All of this to say, frontier AI is no longer a utility sold by the token. Labs are developing whitelists & blacklists.

Even the era of permissive open-source weights is narrowing. Model creators are introducing free-to-pay conversion thresholds, a form of product-led growth, allowing open experimentation for developers while requiring revenue-triggered security reviews & commercial licensing for large cloud hosts. Open source now means open until you scale.

Governments are treating frontier AI as critical sovereign infrastructure, using export restrictions, nationality screening, & specialized model tiers to police who runs the frontier.

Pushing back against this closure is a $5t countervailing force : Nvidia, leveraging its market cap to invest in open ecosystems. & they’ve been active : $13b for Hugging Face, $7b for Poolside’s model factory, & a $26b commitment to Nemotron. & the list continues.

Open weights are its structural defense against its own cloud customers, ensuring foundation models cannot be entirely gated by proprietary labs or sovereign restrictions.

Access, not price, is the new scarcity at the frontier.

OpenAI has begun letting some of its largest customers pay only when its AI actually completes the job. Kevin McLaughlin and Amir Efrati reported the change to The Information, giving the example of a customer support interaction handled end-to-end.

The arrangement is limited to select major accounts rather than offered generally, and OpenAI has not announced it. TNW has not independently verified the report, and the terms, the customers, and the prices are all unknown.

The industry name for this is outcome-based pricing, and the appeal to a finance director is not subtle. A bill that arrives only when something worked is considerably easier to defend than one that arrives regardless.

Token billing has made that a live problem. One developer running a hundred agents in parallel accumulated $1.3m in OpenAI tokens across thirty days, which is an extreme case of a general pattern where cost scales with attempts rather than results.

Customer support is where the model has already settled, because a resolution is one of the few AI outputs anyone can define. Intercom charges $0.99 for each conversation its Fin agent resolves, and nothing at all for the ones it does not.

Zendesk went further in May, restricting billing to what it calls Verified Resolutions, confirmed by an LLM evaluation within 72 hours of the conversation. Assisted escalations and contained resolutions became free, and the billable rate sits at roughly $1.20 to $1.50 on committed volume.

Salesforce has been working through the same question in public and more awkwardly. Agentforce launched at $2 per conversation, charged for every 24-hour session whether or not anything was resolved, which customers found both expensive and impossible to forecast.

Flex Credits arrived as the answer, moving the meter from conversations to individual actions at about 10 cents each, starting at $500 for 100,000 credits. That is consumption pricing rather than outcome pricing, and the distinction matters, because an action that fails still bills.

Buyers appear to want both, in that order. Futurum Group found in May that 43% of them prefer consumption-based models and 27% prefer outcome-based ones, with fewer than one in five still preferring to pay per user.

“Outcome-based pricing is becoming a market standard,” wrote Keith Kirkpatrick, the firm’s research director for enterprise software, whose sharper finding is that vendors offering seats alone are now being disqualified before the evaluation starts.

For OpenAI, the move is a change of position rather than a new product. It has sold capacity by the token, priced per model and per call, and letting an enterprise pay for completed work instead means accepting the risk that the work does not complete.

That risk has to be priced somewhere, and the interesting question is where. A vendor confident in its success rate can afford the arrangement, while one that is not has to load the per-success price until the economics match, which is why per-resolution rates cluster around a dollar rather than a cent.

It also changes who carries the cost of a bad answer. Under token billing, the customer pays for every failed attempt, whereas under outcome billing the vendor absorbs them, which is a meaningful transfer of risk from the buyer to the company that built the model.

The harder part is agreeing what success means. A resolution is definable, but the agentic work OpenAI has been pushing towards, with 10 million users on its agents, involves multi-step tasks where completion is a matter of judgement rather than a field in a database.

There is a commercial reason to want it settled quickly. An enterprise that cannot forecast a bill tends to run a pilot indefinitely rather than sign, and outcome pricing removes the objection at exactly the point in the sales cycle where it usually stalls.

None of that is settled, and none of it is public. What is on the record is that the largest model vendor has started, quietly and selectively, to sell results instead of capacity.

Some of the world’s leading music publishers think that Anthropic got off too light in a historic settlement where the Claude maker paid authors $1.5 billion after admitting to pirating more than 7 million books to train AI.

“$1.5 billion is obviously not a large enough settlement to deter infringing conduct by a company that has parlayed such mass infringement into a staggering $2-trillion-dollar valuation,” music publishers said in a lawsuit filed Friday.

Music publishers suing Anthropic include Sony, EMI, and Warner Chappell. They alleged that Anthropic’s illegal torrenting also included “thousands upon thousands” of their copyrighted musical compositions.

Songwriters who are increasingly competing with AI-generated works in music charts are harmed by that piracy, their complaint said.

Pirated books that Anthropic allegedly plans to keep “forever” to train AI include titles featuring the complete works of the Beatles, Taylor Swift’s “best” songs, and “VH1’s 100 Greatest Songs of Rock & Roll.” Without an injunction ending the improper AI training, Anthropic will continue to violate music copyrights—while improperly substituting artists in their markets by reproducing song lyrics verbatim and by generating “new” songs that mimic the “heart” of their most popular works, publishers alleged. For example, Anthropic may rely on songbooks or sheet music to respond to prompts asking Claude to change Eminem lyrics into a song written in “Beyonce’s style.”

“It’s a brazen campaign of illegally torrenting, scraping, and downloading copyrighted works on a massive scale in order to develop, operate, and reap enormous profits,” music publishers alleged.

Sony resurfaces Anthropic staff chats

Anthropic’s “mass campaign of illegal torrenting” began in July 2021, when Anthropic co-founder Benjamin Mann “personally used BitTorrent to unlawfully download and upload via torrenting millions of pirated books” from Library Genesis (LibGen), a controversial pirate library. Dario Amodei, Anthropic co-founder and CEO, allegedly approved the torrenting, and both he and Mann are named individually as defendants in music publishers’ lawsuit.

By the end of 2021, though, the FBI had shut down LibGen, the complaint noted, “but not before online pirates copied its contents to create a new library,” named “Z-Library.” And although Z-Library also got shut down quickly, internal messages revealed in the book authors’ fight showed that Anthropic got access to a copy of the copy through the “Pirate Library Mirror” (PiLiMi), the lawsuit said.

Mann is accused of directing employees to torrent PiLiMi soon after it became available, messaging colleagues that the mirror dropped “just in time!” Responding, an Anthropic staffer wrote back, “zlibrary my beloved.”

Music publishers pointed to these comments as proof that Anthropic extolled the use of piracy and relied on torrenting to quickly access new training data. In total, they alleged that crawling through LibGen and PiLiMi’s non-confidential catalogs showed “bibliographic metadata like title, author, and ISBN” that indicated that “Anthropic torrented at least hundreds of books containing sheet music and song lyrics to musical compositions” owned by publishers suing.

Through discovery, publishers claim they will reveal the “full extent” of Anthropic’s torrenting, the complaint said.

Publishers suspect Claude trained on hit songs

Publishers acknowledged that Anthropic denies using any of the books that they torrented from LibGen and PiLiMi to train commercial Claude AI models. However, they claimed that Anthropic’s statements depend on how “training” is defined, and they think that if the court traces Anthropic’s steps back far enough, it may reveal that commercial models were at some point trained on pirated works. As they explained:

“Often, AI development includes a ‘pretraining’ phase where one AI model may train on ‘synthetic data’ created by another AI model or receive other behavioral feedback from another AI model. Anthropic has trained at least one of its commercially released Claude models using synthetic data created by a non-commercial AI model that was trained on text derived from LibGen and/or PiLiMi. Anthropic employed at least one non-commercial model that was trained on text derived from LibGen and/or PiLiMi to provide at least one commercial Claude model with reinforced feedback.”

Additionally, their complaint noted that recently unsealed documents from the book authors’ case “revealed that Anthropic exploits the pirated books it illegally torrented from LibGen in connection with its guardrails.” For example, in one filing, an Anthropic witness testified that Anthropic stopped training large language Models (LLMs) on LibGen but continued using the LibGen dataset to see if long strings of text in outputs too closely matched source text.

A spokesperson for Anthropic provided Ars with a statement that seems to suggest that music publishers are grasping at straws by digging through book authors’ settled complaint.

“This is the third lawsuit from the same lawyers, recycling allegations from cases already before the courts,” Anthropic’s spokesperson said. “Training generative AI models is a transformative fair use—as the court held in Bartz—and we will defend ourselves robustly.”

Songwriters allegedly harmed by AI songs

Anthropic’s statement neglects to mention that the fair use ruling hinged on book authors’ inability to prove market harms or that AI tools had substituted them in their markets.

Only Anthropic knows for sure how often users rely on Claude to generate substitutes for musicians’ songs, the lawsuit said. But publishers seem to think that music rightsholders may have a better chance at proving market harms than authors did.

They’ve alleged that Anthropic publicly tracks the threat to song lyricists from its AI products and that the company knows that AI-generated songs currently topping music charts compete directly with musicians whose songs were used without payment to allegedly train the AI replacing them in top slots. Most glaringly, the US Copyright Office has “observed that ‘where a generative AI model’s outputs, even if not substantially similar to a specific copyrighted work, compete in the market for that type of work,’ including in the case of song lyrics,” the outputs may dilute royalty pools, the lawsuit said.

Specifically, the judge in the book authors’ case wrote that, “like any reader aspiring to be a writer, Anthropic’s LLMs trained upon works not to race ahead and replicate or supplant them—but to turn a hard corner and create something different.” But it’s unclear if courts will agree that the same holds true for songwriters or the music publishers who represent them.

Music publishers alleged that Claude was intentionally trained to regurgitate lyrics, relying not just on pirate libraries but also on other unauthorized datasets, including pirated content scraped from lyrics sites without the permission of rights holders. Additionally, Anthropic destroyed physical books to harvest more data, allegedly creating unauthorized digital copies “of hundreds of songbooks and sheet music collections,” which also violated copyrights.

According to publishers, Claude models will fetch lyrics when prompted without sharing copyright management information, and they even generate lyrics when users do not request them. For example, if a user asks Claude for a particular song’s chord progression, “the AI model will often generate output” containing “copyrighted lyrics alongside those chords,” the complaint said. And Claude will also often mash up actual lyrics with AI-generated lyrics when making “new” songs, the lawsuit said, and it’s capable of “reproducing the ‘heart’ of those works in response to a wide range of user prompts.”

Anthropic seemingly designed the model to perform this way. Allegedly, Anthropic workers “repeatedly prompted the AI models for Music Publishers’ copyrighted lyrics, encouraging the models to generate output containing those lyrics” after Anthropic asked them to test if the AI models could recommend comparable songs based on someone’s favorite music.

Amodei testified during the book authors’ litigation that Anthropic could have legally purchased copyrighted works but torrented them instead, because Anthropic wanted to avoid a “legal/practice/business slog.” The court summarized Anthropic’s intent as downloading pirated books “to avoid the trouble of paying for them,” and music publishers emphasized that Anthropic never approached them to strike licensing deals as its biggest AI rivals have.

Anthropic closely guards its training data sources, but music publishers think the court should require more transparency. Anthropic should be ordered to “provide an accounting of the training data, training methods, and known capabilities of Anthropic’s AI models,” publishers demanded. Then artists in all types of media could assess how Anthropic acquired their works, what works were ingested, and how much they may have influenced a commercial model.

Left unchecked, music publishers alleged that Anthropic’s reliance on pirated and unauthorized works to train AI makes it harder to make a living as a songwriter today, while diluting the market with low-quality AI copies of recognizable songs. And of course, the complaint noted that piracy also makes it harder for publishers to get paid to license songs to train AI.

“Anthropic has never sought nor obtained any license to lawfully exploit Music Publishers’ copyrighted works for any use, let alone for AI training data or output,” their complaint said. “Anthropic enriches itself through the uncompensated exploitation of Music Publishers’ and their songwriters’ labor, reducing their incentive to invest in, support, and expand present and future creative efforts.”

OpenAI said ChatGPT Ads reached a $1 billion annualized revenue run rate less than 200 days after launch.

The FTC has filed a lawsuit against Amazon alleging that it manipulated prices that businesses paid to advertise on its retail platform. Amazon allegedly deceived advertisers by secretly raising the minimum price advertisers had to pay. Amazon's digital-ad platform is the third-largest in the world behind Google's and Meta's platforms. It earned $68 billion from ads in 2025.

Prominent solo investor Lachy Groom has backed a Bengaluru startup attempting an ambitious feat: keeping an aircraft in the sky for more than a year by harvesting energy from ocean winds.

Alteon, founded by 20-year-old Samay Sanghvi, announced Tuesday that it raised $2.5 million in a pre-seed round led by Groom, with participation from Together Fund, to develop autonomous aircraft inspired by dynamic soaring, a technique albatrosses use to extract energy from the wind. Groom decided he wanted to invest within the first 30 minutes of their first meeting, Sanghvi told TechCrunch.

Conventional aircraft need to carry the fuel or battery power required for a flight. Alteon is trying to break that limitation by designing its small, fixed-wing autonomous aircraft that can extract energy from wind shear above the ocean through dynamic soaring — a maneuver in which an aircraft repeatedly moves between layers of air traveling at different speeds.

“Once you build airplanes that can stay in the air for more than a year, there are millions of things you can do with them,” Sanghvi told TechCrunch. Alteon plans to initially use the aircraft for maritime surveillance, giving governments real-time visibility into activity in their waters.

The initial plan is to build an aircraft with around a 3-meter-wingspan that will fly close to the ocean’s surface, climb, and turn through faster-moving air, and repeat the cycle to gain energy from the wind. Eventually, Alteon plans to use its propellers as turbines to convert some of that energy into electricity and recharge its onboard batteries.

However, the startup has not yet demonstrated that its aircraft can actually sustain flight using energy harvested through dynamic soaring. It did complete a recent test of its autonomous flight system over the Bay of Bengal in which the aircraft autonomously completed seven O-shaped cycles at more than 62 miles per hour, flying within 1 meter of the water’s surface.

Alteon’s next major milestone will be what Sanghvi calls “energy-neutral dynamic soaring.” This would allow the aircraft to fly continuously with its propulsion switched off, extracting enough energy from the wind to remain aloft.

Dr. Gabriel Bousquet, a Silicon Valley-based aerospace and robotics engineer who researched dynamic soaring during his PhD at MIT, called Alteon’s low-altitude flight over water a “promising first result.” But he noted that the harder challenge will be proving that the aircraft can reliably extract enough energy from real-world winds to sustain flight for extended periods.

Flying low enough to harvest that energy safely is particularly difficult, Bousquet told TechCrunch, as the aircraft would have to contend with turbulence, waves, spray, rain, and changing light conditions while continuously sensing and reacting to a moving ocean surface.

Dr. Bharath Swaminathan, who earned his PhD from IIT Madras studying the stability of dynamic soaring, said the underlying physics is well established and called Alteon’s effort commendable. Keeping an aircraft airborne for several days using dynamic soaring would itself be “a very big step, and a big achievement,” he told TechCrunch.

Swaminathan, however, added that while large-scale wind conditions may be predictable, local wind shear and turbulence can vary substantially, complicating an aircraft’s ability to continuously extract energy from the wind. Some of those challenges, he suggested, may only emerge through real-world flight testing.

Groom acknowledged the technical risk behind the bet. “Ambitious problems are always going to come with risks,” he told TechCrunch. “For me, it came down to believing Samay and the Alteon team are the ones to figure them out.”

Sanghvi began working on what would become Alteon straight out of high school in 2023, learning to build aircraft by making — and crashing — radio-controlled models before developing early prototypes. He formally founded Alteon in 2025 and received early backing from Emergent Ventures and 1517.

Alteon now has a team of 20 in Bengaluru and operates from a 10,000-square-foot facility. The startup is building four to five aircraft a week for testing and has conducted more than 200 test flights in the past 30 days, Sanghvi said.

Invisible Companies

Steve Ross was a legend. Starting with nothing but a job at his father-in-law’s funeral parlor, he built Time Warner into one of the world’s largest companies, making a mark on every part of the media landscape. MTV and Nickelodeon were born under his roof. He bought and ran Atari. He helped found the New York Cosmos and, with it, professional soccer in America. When Ross died in 1992, Clint Eastwood dedicated his Best Picture Oscar for Unforgiven to him; two years later, Steven Spielberg did the same with Schindler’s List.

Everyone glosses over the boring part. To build the stake he needed to get into the media business, Ross bought and built a string of strikingly mundane companies in the 1950s and ’60s. He started by convincing his father-in-law to let him rent his funeral parlor’s limousines out at night, when they weren’t being used. Then he founded a rental car company, merged it with a parking lot business, bought a cleaning business, and took the whole thing—including the funeral parlor—public as Kinney Services. Ross used Kinney to buy a flooring company, a painting company, a carpentry company, and a plumbing company. He then parlayed this hodgepodge of everyday businesses into acquiring the legendary Warner Bros. movie studio.

There’s a puzzle here worth thinking about. Ross essentially picked up a bunch of stones off the ground and traded them in for a diamond. Usually, to make big money in business, you have to do something no one else can do or have something no one else can have. But any competent businessperson could have bought or started the businesses Ross did. In 1990 he took home $78 million, the largest pay package of any executive in America at the time. How did he get there?

If you took economics, your introductory textbook said something like this: “Business dynamics cause firms to enter and exit markets so that, in the long run, prices are driven down to minimum average total costs, resulting in all firms earning zero economic profit.” What this means is that no company should be able to make outsized profits for very long.

Of course, plenty of companies do make money for a long time, and business strategists have laid out the reasons: Michael Porter’s barriers to entry (you do something no one else can do), and Jay Barney’s costly-to-imitate resources and capabilities (you have something no one else can have). These “moats” protect a company from profit-destroying competition.

The businesses Ross bought and started did not have moats. Funeral parlors, parking lots, rental cars, and the rest are easy industries to compete in. You can tell because they are crowded with competitors. Yet in 1969, Ross bought Warner for roughly $400 million—about $3.5 billion today. Without any sort of moat, Ross should not have been able to accrue the wealth needed to buy one of the storied movie studios of the ages. But he did.

Steve Ross wasn’t the only one. Constellation Software, Waste Management, HEICO, and many other rollups searched for just these sorts of businesses, and built extraordinary profits by looking where no one else was looking. This entire class of mundane businesses sits right in front of our noses, but both management strategists and most businesspeople just couldn’t see it. These businesses are invisible.

How to disappear completely

You can’t, of course, make a definitive list of today’s invisible companies; that’s the point. But the building blocks of Steve Ross’ early empire are perfect examples, for their time. Others, like HVAC, trailer parks, and candle retailing, were much more fragmented businesses until someone realized they were invisible sources of profit and rolled them up. Hindsight suggests we are currently surrounded by highly profitable companies that we never even think about, while common sense suggests this is impossible.

Your basic econ 101 “economic-profits-go-to-zero” explanation has a couple of assumptions: frictionless entry and exit of companies into an industry, and perfect knowledge of the relevant drivers of success. Economists aren’t naive, so they don’t really believe these things entirely. But they assume they are mostly correct over the medium to long term.

Management strategists, on the other hand, saw that the first assumption was grossly wrong: there are plenty of industries in which it’s hard for a competitor to enter the market. In response, they came up with the concept of “sustainable competitive advantages,” which is 90% of the reason business strategy is a different discipline than economics.

But both approaches assume the market works like this: (1) an opportunity exists; (2) potential competitors notice it; (3) they evaluate how to enter the market; (4) if they can, they enter; (5) profits are eroded. This all hinges on whether anyone has noticed the opportunity. If they don’t, potential competitors never get to step one. Competitive neglect is upstream of the entire economic and strategy machinery.

This is not an asymmetric-information problem, where both parties know the gap exists and have every incentive to close it. Nor is it tacit knowledge or a trade secret—things rivals can’t observe from the outside but know are there and actively try to crack.

Invisible companies persist for a different reason: the missing information is itself invisible. Would-be competitors do not know that they do not know, so they don’t think to search. And the invisible companies have no reason to tell them. No one searches, so no one competes; no one competes, so the profits persist. The reward for being overlooked is, paradoxically, the opportunity for supranormal profits.

Companies are invisible primarily because no one is paying attention to them. There are four main reasons this happens: No. 1, they are unknown; No. 2, data about their existence or profitability is private, missing, or obscure; No. 3, they are misunderstood because their markets are assumed to be mature, shrinking, or too small to matter; or No. 4, they are disdained, because the work is low-status, unpleasant, parochial, or socially stigmatized. It’s obvious that this happens, but it also seems impossible that the absence of information could last for long: dead-end markets eventually dead-end, and stigma could be overcome for a price. Invisibility seems like it should be a brief anomaly; a weird blip in an otherwise efficient market. Over the medium to long term, the market should make these invisible companies visible.

How does invisibility work?

This is not what happens. Take Constellation Software. The best-performing software investor of the last 20 years, Constellation has compounded shareholder returns at roughly 34% a year since its 2006 IPO. It did this by buying tech businesses. Not exciting ones, but small ones—deal sizes often under $5 million—in niche markets: marina management and ski-lift ticketing software, funeral home record-keeping, library cataloging, oil-and-gas pipeline scheduling. It bought them after the companies’ management or their venture capital backers had thrown in the towel because they were too small and growing too slowly. Constellation is good at picking companies and helping them succeed, but some of its outsized returns come from a different source. The industries it buys into were profitable but boring to everyone else, leaving Constellation to buy cheap and build something big by putting them all under one roof.

Constellation recently estimated that there are still 38,000-plus vertical-market software businesses it could potentially buy. These aren’t a handful of backwater anomalies. They are companies across nearly every industry that are ignored by other acquirers, even though they are presumably profitable, since value can be created by buying them.

One mechanism that causes invisibility is simple unawareness. Businesspeople hunt for opportunities using data other people have already gathered—and no one bothers to gather data on obscure, small, non-strategic markets. It costs more to collect and almost no one wants it. Worse, the data that does exist is often aggregated at a level that buries the anomaly: for instance, figures on the packaging sector can hide a specialty-packaging niche that earns several times the industry average.

Businesspeople also gather information from those they know through work or socially. But some companies sit entirely outside the social networks where investors and executives trade ideas. Even if you have cultivated a diverse network, it is unlikely an acquaintance you have coffee with in New York or Silicon Valley has any knowledge of specialized manufacturing in the Upper Peninsula.

Another source of invisibility is less the absence of information than the habits people bring to interpreting it. Investors, entrepreneurs, and corporate development teams are trained to look for large markets, rapid growth, novel technology, and strategic urgency. These filters are useful, which is why they become standard. But they also make smaller, mature, operationally mundane businesses look boring even as they quietly mint profits. The opportunities aren’t hidden because the facts are unavailable; they’re hidden because the algorithm that works most of the time screens them out.

The last mechanism is status: Some businesses simply seem less important, interesting, or socially acceptable. Wayne Huizenga could build Waste Management into a behemoth by buying up smaller haulers—in his first two years they rolled up 133 of them—precisely because almost no one else wanted to be in the trash hauling business. The same stigma turns people away from other structurally crucial industries: janitorial services, plumbing, cleaning, and countless others. These industries are stable and, as with all these mechanisms, competitive neglect keeps them consistently profitable.

We have always known about invisible companies, but previous explanations for them have led to self-defeating tactics. In Germany, for instance, they have “hidden champions”: smaller companies in niche markets that are mostly unknown to the general public but drive much of Germany’s exports. The success of these companies has been explained by some of the usual sources of sustained competitive advantage: customer ties and closely held knowledge. And the reaction has been to publicize these underappreciated drivers of the economy. But the evidence—the companies are closely held, remotely located, and tend to control, rather than outsource, all production—points to invisibility as the likely mechanism for their success. By not understanding this, these companies endanger their position by drawing attention to themselves.

Barriers to entry and resource-based advantage are well known. Invisibility points to a different source of protection. Competition is not only limited by what rivals cannot do or cannot copy; it is also limited by what they fail to notice or turn their nose up at. It shifts the focus of strategy from tangible barriers and resources to the intangible concerns about how a market space is cognitively and institutionally structured. Thinking about invisible companies means thinking about strategy in a new way.

Staying invisible

Many industries have no easy moats to erect. There’s nothing novel to patent, no shortage of workers with the requisite skills, no scale effects, no secret sauce. And when there are moats available, they might be costly or time-consuming to build: a well-known and trusted brand, a corner on some crucial input, or long-term deals with customers, for instance. Staying invisible saves you from all that—you can be viable without a moat, since competitors won’t enter anyway. Or you can use invisibility as a temporary moat until you build a conventional one.

There is a strategic trade-off here. You might need to raise money, but financiers talk. An IPO tells everyone how profitable you are (though, if you’re a conglomerate like Kinney was, it might be hard to pinpoint exactly why). Employees whose skills you need might prefer to work somewhere with more cachet, or at a company whose future looks more secure. You might have to make yourself invisible not just to potential competitors but to some kinds of customers, especially if you’re in the type of business where you need to build a brand or do PR to attract them. You can’t have fancy offices in the city to impress clients, or, in general, show off your financial success. Any large public investment might signal that you have money to spend. And while resource-based advantages can be built even while invisible because they are hard to observe from the outside, building barriers to entry is the kind of visible activity that signals you have something to protect.

Some companies need the attention. They need word-of-mouth to grow, or they need to impress clients with their acumen—either directly, by telling people how successful they are, or indirectly, with wood paneling, Persian rugs, and recognizable modern art in the reception area. Invisibility does not make strategic sense for these companies. Similarly, you need to find a different moat if you sell goods to consumers, where price and volume are readily visible. And you won’t stay hidden if you are strategically important to your customers (who then might need to find a second-source supplier) or to other companies’ customers.

But other markets are especially conducive to invisibility. Firms in these markets serve narrow customer segments with mature technology in unglamorous industries: providers of essential but overlooked support functions; suppliers whose products are too small a line item for customers to study closely; businesses addressing needs so specific they look irrelevant to generalist investors. HEICO, for instance, managed to stay under the radar while building a multibillion-dollar business in aftermarket aircraft replacement parts. This opportunity never surfaced for others because it involved obscure components, mature use cases, and line items too small to notice (relative to a whole airplane). But the parts were critical to keep old aircraft flying. Most businesspeople looked at the airplane business, but HEICO looked one layer deeper and found an opportunity sitting in plain sight.

Some markets start out invisible, and others fade from view. These might be companies that were strategically, financially, or institutionally important, and then weren’t: laundromats went from important to ignored before popping back into view for investors as recession-resistant, cash-flow generators. Or they may be companies whose technology was displaced, became obsolete, or addressed too narrow a niche, like the ones Constellation acquires. Other industries—like, say, business magazines—lose their narrative appeal, leaving potential profit for those willing to buck the tide.

There are also firms that are not so much invisible as disregarded because they are not currently “high status.” This includes many firms in the trades, like landscaping, janitorial services, septic tank maintenance, garbage removal, and parking lot management. Of course, these are exactly the kinds of companies Steve Ross used to build the wealth needed to buy Warner Bros.

Losing invisibility

Invisibility has to be treated as a strategic asset to be managed. Firms must weigh the benefits of discretion against the demands of sales, hiring, financing, and reputation. If they need public attention to grow sales, hire employees, or raise money, for example, they may decide invisibility isn’t worth the cost. Or, if they think they are about to lose their cloak of invisibility for some other reason, they might decide to shed it pre-emptively. They might decide to launch a brand-building campaign, for instance. Or they might decide to go public and use the money raised by an IPO to build an enduring competitive advantage—with the strategic fillip of exposing their competitors to scrutiny, who then lose their invisibility without any offsetting benefit.

Some companies can stay invisible forever. But even companies that choose to remain invisible can lose their invisibility through no fault of their own. These unmanaged unveilings can do lasting damage to industry margins.

Dramatic changes in market conditions, demography, or consumer preference can make a market interesting enough that it starts to surface. COVID brought attention to makers of N95 masks. Aging baby boomers made it obvious the hearing aid market was going to be big. Digital music pushed audiophile equipment upscale, and made makers of vacuum tubes (JJ Electronic) and high-end amps (McIntosh) more visible. This resulted in mainstream media coverage and new entrants after decades of neglect. In these cases, it was an improving market that drew scrutiny, so the impact was mixed.

Other events pierce the cloak of invisibility without any offsetting gains. A succession fight inside a family company can drag private valuations, ownership stakes, and margins into court filings. Political activity can reveal wealth no one had thought to ask about; Mike Lindell probably did more to teach the public that there was serious money in pillows than any industry report ever could. And scandal can illuminate an entire profit pool. When Martin Shkreli raised the price of Daraprim from $13.50 to $750 a pill, an obscure corner of specialty pharmaceuticals became a national story overnight. This was a grievous own-goal. For a company trying to remain invisible, publicity is not free advertising. It is discovery.

Finding invisible opportunities

Companies work to stay invisible because they want to maintain the profitability that comes with having few competitors. This is exactly the kind of industry that entrepreneurs and investors might want to find. There’s a paradox here: if they are invisible, then by definition you can’t find them. To do so, you have to reverse the rules that keep them invisible and look where there is, suspiciously, nothing to see.

Since the databases and screens that everyone uses gloss over these business opportunities, you have to look deeper, for outliers in the data, or look outside the consensus data sources entirely. Looking deeper means finding the niche opportunities that disappear in the broader data, for industries that don’t seem to be in the data at all, or for companies geographically isolated from the investor class. This requires broadening who you talk to and being alert to chance comments. People pay attention to large companies but never see the cloud of small suppliers around them. If you look a layer or two deeper, you can find invisible companies providing indispensable products and services.

Or: loosen some of the criteria you use to filter companies in your search process. What happens if you ignore growth rates and look instead for industries that are shrinking? What happens if you ignore apparent market sizes? What happens if you look for large market sizes where no one advertises or goes public? Find things no one else has found by breaking from the consensus and staring directly into the institutional blind spots.

And last, look for industries where new entrants almost exclusively come from existing companies, where there are businesses being started, but not by outsiders. If there is outsized profit, existing employees will know about it. Some of them will decide to compete, even when no one outside the industry can see the opportunity.

The return of the age of invisibility

Steve Ross came of age when organization men ran the big companies and society looked to engineers and scientists for progress. He was none of those things, so he used his entrepreneurial drive to make money in invisible businesses. We have, arguably, come to that time again. Our big companies try to grow through rent-seeking rather than innovation, and venture capital is increasingly concentrated in businesses started by PhD-level experts. It’s a hard time to start a tech business, but Ross’ path is always there.

Meanwhile, companies that have relied on technological change to generate the dynamism they need to stay ahead of the competition are seeing technological advances increasingly controlled by a smaller and smaller group of well-resourced incumbents. For these companies, knowing how to be invisible becomes an ever more appealing strategy.

On the flip side, some of the mechanisms of invisibility are becoming weaker. The data that could pinpoint a company making excess profits is increasingly available and AI can be used to sort through vast amounts of it in shorter periods of time. Social media might overcome geographic obscurity to broadcast success. Or, given the tendency for like to follow like, it might reinforce partitioned social networks: do NYC kings of the universe follow industrial workers on Instagram? Maybe they should. The shield of invisibility becomes harder to maintain.

Or does it? If AIs are all trained on the same datasets, case studies, and value frameworks, invisibility gets quietly hardcoded into the models. Of course, the harder it is to find the invisible opportunity, the more competitive neglect there will be. If some of the best opportunities are those few people think to look for, seeing the invisible may be the most valuable competitive advantage of all.

Google will automatically fully expand AI Overviews in some search queries, effectively turning the whole page into an AI response.

In September 2023, the Census Bureau added questions about AI to its Business Trends and Outlook Survey. Census asked hundreds of thousands of businesses whether they had used AI in the previous two weeks to produce goods and services. At that time, 3.7% said yes; by late 2025 the figure had reached about 10%. (In November 2025 Census broadened the question to ask about AI use in any business function, producing a jump in measured adoption to about 18%.)

Twice the Bureau has asked a key question:

In the last six months, how did the use of Artificial Intelligence affect this business’s total employment?

In Dec. 2023 to Feb 24, when ~5% of firms were using AI the answers were 2.8% increased, 2.6% decreased and 94.6% reported no change. Two years later, in the Nov 2025–Feb 2026 supplement, the answers were: 2.3% increased, 2.0% decreased, and 95.7% reported no change. The answers were similar by firm size.

Some sectors reported more action. Information is the one sector where fewer than 92% report no change. But overall, almost all firms report no change and of those reporting change it’s about evenly divided between increasing and decreasing employment.

The supplement also asked about tasks. Among firms using AI, 44% say it supplemented or enhanced work an employee already does. Ten percent say it performed a task an employee used to do. Eleven percent say it introduced a task no one had been doing.

Among those using generative AI, 85% of firms cited writing or editing documents and email as the biggest uses, half cite searching for information, 45% summarizing documents, and 13% coding. Sixty-four percent of adopters say they changed nothing about the business in order to use AI, 15% trained existing staff, another 15% built new workflows, and just over one percent hired anyone with AI skills.

Among firms where AI has taken over some employee tasks, the degree of substitution is growing. The share reporting that AI took over “a large number” of tasks rose from 2.4% to 7.1%, while the share reporting “a moderate number” rose from 13% to 22%. But this group is still small: only about a tenth of AI adopters, who themselves make up about a fifth of firms.

I have reported firm-weighted estimates but employment-weighting gives essentially the same result. Thus, we have unusually direct evidence from a very large sample, and it says that the overwhelming majority of firms using AI do not yet report any effect on total employment. Very consistent with what Tyler and I said in our talk to OpenAI.

The MacBook is evidence that Apple's trade secrets are being used and evidence is being destroyed.

Alibaba officially rolled out Wan3.0, an upgraded AI video-generation model, a day after announcing a $10 billion share placement to fund rising AI spending. The model generates 30-second videos from documents, spreadsheets, slides, and web pages, and has been used since its August 6 public beta. The share sale is the largest-ever primary follow-on offering by a Hong Kong-listed company, coming after Alibaba reported a 75% plunge in quarterly earnings due to soaring AI capital expenditure.

Apple just released a stop-motion ad to introduce the Mac mini and it has creatives rejoicing about the handcrafted animation and lack of AI. In fact Apple has even published the behind the scenes video showing exactly how the animation was made – with animators painstakingly sculpting and painting clay, just to prove its chops as a human-made piece of work (a relief to those questioning it online).

The ad itself is a departure from Apple's traditional aesthetic in many ways, though it retains the usual minimal style across background and product. But the animated components – beginning with a yellow, Hulk-style strongman busting out of the Mac mini, are more in keeping with Apple's current marketing style – whimsical, less corporate and less polished. In that way, this ad is more similar to the style of its TikTok marketing posts, but with more craft added in.

"To show off the power and speed of the Mac mini, we turned it into a character capable of anything," says animator Justin Dasch. "So you got rocket ships, freaking race cars, buff dudes, and super complex robots doing multitasking."

See more of what the animation team had to say in the video below.

I'm enamoured by this ad. After the furore and subsequent apology that came out of Apple's iPad Pro ad of a couple of years ago (in which an iPad Pro crushed musical instruments, paint brushes and other symbols of tactile creativity), it's also an appreciated nod to the value of human creativity. The mac mini is positioned as an enabler rather than a replacement, and that's all creatives really want from their tech.

What do you think of the Apple mac mini ad? Let us know in the comments.

This rebrand of a voice-journalling app looks lovely, but is an 'AI illustration system' the right call?

The Working Assembly's new identity for Untold aims to avoid gen AI clichés, but still uses gen AI to create it.

It can't have escaped your attention that AI feels like a dirty word right now. But generative AI isn't the only flavour of AI around. There are a number of genuinely useful tools that use AI, and even the people who hate the former are potential users of the latter, if only the branding and marketing are done right.

Among them is the voice-first journalling platform Untold. This tool focuses on turning spoken thoughts into "deeper self-understanding, personalised insight, and lasting growth". And for anyone who likes the idea of journalling, with all its therapeutic benefits, but has failed to turn that into a regular habit, it has a lot to offer.

Instead of needing you to type or handwrite your thoughts, the platform not only listens to what you say but also learns from it. Over time, it identifies patterns, surfaces emotional trends, and offers personalised insights into what you're feeling through the lenses of psychology, philosophy, spirituality and art. It can then go on to generate custom meditations and help you explore recurring themes.

Aims of the rebrand

For their recent rebrand, Untold turned to The Working Assembly, a New York–based branding and creative agency that specialises in helping healthcare, wellness, beverage, and consumer brands through strategy, design, storytelling, and innovation.

The redesign followed Untold's recent launch of Perspectives, a big expansion of the platform that introduces guided journal flows, visual emotional trend mapping, and the ability to ask questions about your life and receive answers based on everything you've previously shared. This evolution meant Untold's original identity no longer fully captured its full ambition or the emotional depth of the experience it offered.

Together, Untold and The Working Assembly developed a strategic framework based on the concepts of speaking freely, feeling understood, and growing intentionally. This then formed the backbone of a completely new visual and verbal system.

Use of AI

The new identity includes a custom logomark, a refined voice and an expressive design system. And now I'll share the exact quote from the press release, so I can't be accused of misleading anyone. "At its centre is a bespoke AI illustration system developed by The Working Assembly, designed specifically for Untold and trained to create imagery that feels emotionally resonant rather than algorithmically generated."

Jolene Delisle, founder and head of brand creative at The Working Assembly, adds this. "We built Untold's AI image system the same way we built the logo itself, from strategy outward. Every visual expression starts with the same idea at the heart of the platform: your voice matters, and what it reveals has the power to shape who you become."

But is an "AI image system" really capable of "emotional resonance"? I've got to be honest, I'm not so sure.

Visible brushwork

On first checking out these screengrabs, supplied as press images, I thought they looked lovely. They're certainly a long way from the kind of slick generic AI images I'm used to seeing. The illustration system clearly takes its cue from visible brushwork, muted earth tones and small, intimate compositions: a hand reaching towards a sofa, a coffee cup and phone caught in afternoon light. Nice.

The out-of-home posters use the same painterly language at scale without losing any of its intimacy: a hand caught mid-gesture, a phone glowing on a kitchen table, a single line of copy doing the rest.

But on closer inspection, it's still pretty clear these are AI-generated, even if they're nicely generated. And while that might not matter, it will very much matter to a number of readers of Creative Boom.

Wordmark and symbol logo

As for the new wordmark and logomark, I'm more of a fan. Looping and slightly loose at the joins, they both reinforce the idea of emotional resonance the brand is trying to convey.

The lowercase "untold" is cast in a serif face with enough personality to feel handwritten, not corporate. The symbol, an interlocking ribbon shape that might read as a wave, a signature flourish or two overlapping figures, looks like it will stand out clearly across app icons, posters and social assets.

The in-app screens, meanwhile, combine functionality with elegance. Onboarding prompts and mood-tracking bars are rendered as brushstrokes of colour, and personalised reflections address the user by name.

Getting a single illustration system to flex convincingly between a 48-sheet poster and a small mobile screen, without either version looking like an afterthought, is a pretty darned impressive achievement when you think about it.

Finally, the mood-tracking screens in particular are an elegant solution to a tough design problem: how do you visualise something as slippery as emotional data? By rendering the mood metrics as loose, hand-painted strokes rather than clean digital bars, The Working Assembly has kept the whole experience feeling consistent and entirely in keeping with the feeling the app aims to evoke.

That AI illustration system, though? I dunno, man. Am I being oversensitive? Is every agency doing this stuff now? I'd love to hear your thoughts on the usual social channels.

The Department of War launched ChatGPT Mil on GenAI.mil for more than 3 million personnel.

Despite saying he'll miss the role of chief executive officer, Tim Cook has enormous comfort in the leadership of John Ternus, his replacement. Cook took over as Apple's CEO in August 2011. His 15-year tenure included the launch of the Apple Watch, AirPods, and major expansions to the iPhone, iPad, and Mac lines. Cook will remain as executive chairman, where his role will include working with governments around the world.

Apple's Apple Watch Series 12 and Ultra 4 are expected to be modest upgrades focused on new ceramic case options and improved health tracking, including continuous heart-rate monitoring and more insightful wellness software, while a major redesign remains in development and could arrive in 2027 or be delayed until 2028.

Instagram now requires profiles featuring AI-generated personas to use a new "AI-generated profile" label, replacing the previous optional "AI creator" tag. Accounts that don't apply the label to AI-generated people will face reduced reach, though appeals are possible through the Account Status dashboard. The change targets only AI persona accounts specifically, not broader AI-generated content, amid rising concern over misleading AI "influencers" impersonating real humans.

BrowserAct builds and verifies a reusable scraper on a live website, then runs it whenever you need fresh results.

x1 helps builders turn app ideas into working iPhone apps through guided planning, visual design, milestone-based building, QA, publishing prep, and iteration.

Browse curated App Store screenshots, paywalls, onboarding flows, and icons from the best-designed iOS apps.

Illustrator and animator Moriz Oberberger creates playful yet subtly unsettling artwork featuring awkward characters, unusual proportions, and expressive mark-making, using experimental drawing and painting techniques to explore vulnerability, tension, and the strange beauty hidden within everyday situations.

CD Projekt Red has refreshed its firebird logo with sharper, more aggressive features and a stronger use of red to better reflect the mythological Slavic raróg it represents, but despite the redesign being a relatively modest evolution, some social media users have bizarrely interpreted the shift to a black-and-red color scheme as a political statement, even though the company says the update is simply intended to create a more modern, confident, energetic, and culturally authentic brand identity.