How Fast Is AI Actually Moving, and What Should You Do About Your Stack?

How fast is AI actually moving inside the labs that build it?

Faster than most tool decisions assume. Anthropic published three measurements of its own development process, and one of them is hard to ignore. As of August 2026, Claude leads 26 percent of Anthropic's AI research and engineering work, up from under 1 percent in February 2026. That slope is the thing you are buying into.

I build automations for a living, so I read numbers like that as a planning problem rather than a headline. If the tool under your workflow improves this quickly, the risk in your stack is not that you picked a weak model. The risk is that you wired your business to a specific one.

This post is about what those measurements say, and what a founder or a marketing lead should actually do with them on a Monday morning.

What did Anthropic actually measure?

Three things about how models get built rather than how they perform. Anthropic reported how much of its own AI research and development is performed by AI, how well the actions of its AI agents are overseen, and how its compute is allocated. It also argued that any frontier developer could publish the same measurements, with third-party verification.

That framing matters. Almost every AI number you read is an output number, a benchmark score on some evaluation with a version tag. These are input numbers. They describe the factory, not the product.

Input numbers are more useful for planning because they move earlier. A benchmark tells you what a model can do today. The share of research being done by AI tells you something about how quickly the next model arrives.

Why should a 26 percent number change how you buy software?

Because the same report shows how recent that number is. Anthropic states that Claude led under 1 percent of this work in February 2026, and that the share of work at or above the level it calls AI collaborates is above 90 percent. A capability that was marginal in February was mainstream by August.

Now think about your own buying cycle. Most teams I work with evaluate a tool over a few weeks, sign an annual contract, and then build processes around it for a year. That cadence made sense when software changed slowly. It does not match a curve like this one.

I am not arguing that you should stop signing annual contracts. I am arguing that the cost of switching should now be a line item in your evaluation, weighted as heavily as features. When I scope automation work, I ask a blunt question early: if this tool changed its behaviour in six months, how many days of work would it take to move? If the honest answer is more than a week, I design around it.

What does running 30,000 agents tell you about oversight?

It tells you that supervision has to be statistical, not manual. Anthropic reports approximately 30,000 agents doing research and engineering work inside the company, with online monitors blocking 0.002 percent of their actions, about 1 in 47,000. Offline monitors flag roughly one to two transcripts in every thousand.

Read those two numbers together and you get a useful lesson. The real-time block rate is tiny. The after-the-fact review rate is about a hundred times higher. Different kinds of problems surface at different speeds, which is exactly what I have seen in far smaller systems.

The automations I run for Ajust move case data between Airtable and Webflow through WhaleSync, built and maintained with Claude Code on my side, and that pipeline has delivered more than 25,000 cases. Nothing in it breaks loudly. Things go wrong quietly, in ways a live guard rail would never catch, and only a weekly look at the output reveals them. If a lab with 30,000 agents needs both live monitors and after-the-fact review, your five-step Zapier workflow needs both too. I wrote separately about what to do when an AI agent's output quality drifts, because drift is the failure mode that live checks almost always miss.

Why does compute allocation belong in a marketing conversation?

Because it is a budget, and budgets reveal priorities better than statements do. Anthropic reports that in the week of July 13 to 20, about 6 percent of the compute that went to AI research and development was allocated toward safety, and about 12 percent of the compute that went to AI-driven AI research and development was allocated toward safety.

You can argue about whether those shares are high or low. What I find more interesting is that the number exists at all, and that Anthropic describes compute as among the most verifiable inputs it can report.

The lesson transfers directly. In your own business, the honest measure of what you care about is where the spend goes, not what the strategy deck says. If you tell clients that content quality matters more than volume, but 95 percent of your content budget goes to production and 5 percent to review, your allocation has already made the decision for you. I run my own publishing that way now, with a fixed share of every article's budget reserved for verification, because that is the only version of the claim that survives contact with a deadline.

Should you switch models every time a better one ships?

No, and this is where I disagree with a lot of the advice floating around. Chasing the newest model is a tax on your attention, and the gains in a marketing workflow are usually smaller than the disruption. Most marketing jobs are not frontier problems. They are summarising, drafting, classifying, and extracting.

What you should do is test on a schedule rather than on a news cycle. If your workflow runs on ChatGPT today, the alternative in the test might be Claude or Gemini, and the point is the comparison, not the brand. Once a quarter, run the same twenty real inputs through your current model and through one alternative, and compare the outputs against what you actually shipped. That is a two hour job, not a migration, and it gives you evidence instead of vibes.

The only reason to move quickly is a cost change or a capability you genuinely lacked. I have a longer piece on which AI model to use for which marketing job, and the short version has not changed: match the model to the job, then leave it alone until the job changes.

How do you build an automation that survives a model change?

By keeping the model at the edge of the system rather than in the middle of it. The parts that should be stable are your data, your prompts, and your acceptance criteria. The model is the part you should be able to swap in an afternoon.

Three habits do most of the work. Keep prompts in version control, in Git or anything that gives you a history, rather than pasted into a tool's interface, so you can diff them when output changes. Keep a small evaluation set of real inputs with known good outputs, twenty is plenty, so you can tell a model regression from a bad day. And log the model name and version alongside every output, so that when quality shifts you can answer the first question anyone asks, which is what changed.

The HubSpot automation I run for Kismet Health through Zapier follows the same principle for a different reason. The value sits in the routing logic and the field mapping, not in any one connector. When a connector changes, I rebuild one step, not the workflow.

What does this mean for the AI tools you already pay for?

It means renewal is a real decision, not an administrative one. When capability improves this quickly and cost structures move with it, a tool you chose eighteen months ago may now be doing a job that your existing subscription already covers.

I would run a simple audit before your next renewal. List every AI tool you pay for, from the writing assistants to the workflow layers like Make, n8n, or Notion, write one sentence on the job each one does, and then ask whether the general purpose assistant you already have could do that job acceptably. Some will survive the test easily, because they own data or a workflow rather than a model call. Others are a prompt with a logo, and those are the ones to cut.

There is a governance side to this too. As you hand more work to agents, the question of who is answerable for their output stops being theoretical, which is why I wrote about who is accountable when an agent acts on your site. Speed of capability does not distribute responsibility. It concentrates it on whoever signed off.

What should you do next?

Pick one automation you depend on and make it portable this week. Move its prompts into version control, write down twenty real inputs with the outputs you would accept, and add the model name to your logs. That is a single afternoon, and it converts a dependency into a choice.

Then put a quarterly date in the calendar to re-run those twenty inputs. Not to chase the newest release, but to notice when the ground has moved under a decision you made months ago. Measurements like the ones Anthropic published are only useful if they change something in your own operation, and this is the smallest change that actually does.

I have been building these pipelines for six years, and the ones that aged well were never the clever ones. They were the boring, swappable ones. If you are trying to work out whether your stack is built to survive the next model, or you want a second pair of eyes on an automation you inherited, reach out. Let's chat about what you are running and where it is likely to bend.