DEV Community: Tomas Grasl

I'm writing my own game engine. Not to make games in it, as it turns out.

Tomas Grasl — Thu, 20 Aug 2026 06:34:54 +0000

I recently wrote here about how Anthropic's pending acquisition of Decart isn't only about cheaper inference it's also about robotics. The argument in short: you can't train a control loop on internet text, because control needs consequences. It needs an environment that responds to actions, cheaply and a million times over. And that is structurally what Oasis is. A frame predictor conditioned on actions is a simulator nobody had to write physics for.

This is the more personal follow-up. About why the topic actually got to me — and why I'd been crawling toward it from a completely different direction the whole time, without planning to.

The Firefox bridge

Making games has been my hobby for a long time. Never professionally, never for money it just never wore off.

At some point it started overlapping with the other thing I do: agents and MCP. I contributed to Godot MCP, which has since become a sort of de facto standard for connecting Godot to agents. And before that, I wrote a bridge between Firefox and MCP agents.

I wanted a simple thing: for a model to actually work with the browser, not write about it.

That turned out to be the smaller part of the problem. At the time, Firefox's approach to external control was badly outdated — a protocol built for testing, not for something acting autonomously inside the browser. Most of the work in the end wasn't about the agent at all. It was about working around or translating an interface that never anticipated this kind of use.

I wrote it, put it out there, and moved on. Mozilla later adopted it and took it their own way: https://github.com/mozilla/firefox-devtools-mcp

This happens to me a lot with my own projects: I start something because the question is interesting, and somebody else finishes it. It used to bother me. These days it strikes me as a fair enough division of labour — the part I enjoy is the part where it isn't yet clear whether the thing makes any sense at all.

My own engine, because it's fun

Alongside that, I write my own game engines. Not in Unity, not in Unreal, not because it's the sensible thing to do.

The reason is mundane: when you write the engine yourself, you know what happens in every single frame. There aren't twenty layers underneath that already decided something for you. You have state, you have input, you have a rule for how one produces the other.

And that's exactly the property I started wanting for a different reason.

Worth saying plainly, because it's the part that usually gets misread: the engine is the work. I'm not training anything, I'm not building a model, and I have no ambition to. Models are something other people make and I'm happy to leave it that way. What I'm building is the instrument you point at one.

What I actually want

I want a model to play my game. And then to design it itself.

Not in the "generate me a level" sense. That's content generation and everybody can do that by now. I mean: let the agent play, let it lose, let it change the rules and try again and watch what comes out.

This is where it meets the distinction I wrote about in the previous post, and the thing I think the whole conversation keeps glossing over:

Model as the control loop — perceive, decide, act. Every tick, inside a latency budget.
Model as the author of the control loop — read the docs, write code, test, iterate. At human timescales.

Almost every number you see about LLMs and robotics measures the second and gets reported as the first. Models today are good at writing code for robots. They are not yet good at being that code.

Your own engine is a pretty good instrument for that distinction. I can open it from both ends. I can hand the agent inputs and let it play in real time. And I can hand it the source and let it change the rules of the world. Same world, same consequences.

The side effect this is really about now

It was supposed to be a nice experiment about games. Gradually it turned into something else, and the next step has almost nothing to do with games anymore.

I don't want to use the engine to generate games. I want it to be a place where you can put a model in a loop with consequences and see what it does. Not to make the model better — to be able to watch it at all.

Because a game is a cheap environment with consequences. It has state, it has time, it has physics dumb physics, but physics — it has object permanence, and it has a cost for being wrong. It's the cheapest thing you can use to check whether a model understands that actions have consequences, or whether it's just good at describing frames.

And because I wrote it myself, I can break that physics at will. Crank up gravity, remove inertia, invert causality. That's hard to do in an off-the-shelf engine and impossible in recorded video. A test harness where you can't change the rules isn't much of a test harness.

It's the exact opposite direction from Decart. They learn the dynamics of the world from video in order to generate frames conditioned on actions. I have a hand-written world I know absolutely everything about, and I'm curious how much of it a model can work out. Smaller, dumber, but fully legible and legible is the whole point when the thing you're building is an instrument.

Where this ends up, I have no idea. It's entirely possible I'll find out only that a model can play my game and nothing further follows. I'll take that.

Why any of this

This is where I'd normally write a sentence about the market opportunity.

I don't have one. I make no money from this and probably never will. There's no startup behind it, no pitch deck, no plan. I'm not competing with anyone building models, because I'm not building one. I do it because I like exactly the stage where it isn't clear yet what it's for and because the things I make this way have a habit of turning out useful somewhere else entirely.

I wrote the Firefox bridge out of curiosity. A year later I was building production MCP infrastructure at work, and that experience saved me a lot of dead ends. The engines started as pure nostalgia for a kind of game nobody makes anymore. Now one of them is turning into a test environment for agents.

I don't think that's a recipe. More of an observation: the most useful things I've made came out as a side effect of something I was doing purely for fun. And I never knew in advance which ones.

So: for fun. And if something interesting falls out of it, all the better.

If any of you are running similar experiments your own engines, agents in simulation, anything on this boundary I'd be glad to compare notes. Especially if you've found where exactly a model breaks once you put it in a loop with consequences.

Anthropic's $6B Decart deal is a robotics play disguised as a compute play

Tomas Grasl — Thu, 13 Aug 2026 15:25:58 +0000

Bloomberg reported this morning, August 13, that Anthropic is in talks to buy Decart AI for around $6 billion. Talks, not a signed deal. That distinction matters and I will come back to it.

What caught my attention is not the number. It is where Decart came from.

The Minecraft thing

Decart got famous for Oasis: a playable Minecraft-looking world that no game engine was rendering. The model predicted every next frame based on what you pressed on the keyboard. 20 FPS, interactive, no scene graph, no collision system, no assets. Just a model hallucinating a consistent world fast enough that your hands believed it.

In late 2024 that read as an impressive demo with no obvious business behind it.

The company was founded in 2023. It has raised over $450M, was valued at $3.1B before this year's round, and its current research page describes three product lines:

Oasis, a world model, now explicitly positioned for physical AI and robotics rather than gaming
Lucy, a real-time video model running live at 30 FPS
DOS, the Decart Optimization Stack: hardware-aware model design, custom kernels, proprietary compilers, inference optimization

The demo was the marketing. DOS is the engineering.

The reported reason is not robotics

Read the actual reporting carefully. Fortune says a deal would bring Decart's video-simulation and chip-efficiency technology into Anthropic's inference team. Bloomberg's sources point at the same thing: the chip efficiency work could help existing infrastructure absorb more demand.

So the sourced story is compute economics. Anthropic is compute constrained, spending enormously on capacity, and DOS is a margin lever that applies to every single Claude request on day one.

That is a boring, completely rational reason to spend $6B. It does not need a robotics narrative at all.

I still think the robotics reading is in there.

Why

Two things sit underneath.

First, Anthropic held acquisition talks with Physical Intelligence this spring. The Information reported it, the CEO denied the specific weekend rumor that blew up on X in July, but the talks happened. That is a robot foundation model company, valued around $11B, whose pi0.5 is one of the more widely used robot brains in research labs. You do not open that conversation by accident.

Second, and this is the constraint people skip: OpenAI is already a shareholder in Physical Intelligence. Founders Fund and Thrive are in there too. If a bidding contest for the robotics foundation model layer is happening, Anthropic may simply not be allowed to win that particular one.

If you cannot buy the robot brain, buy the world the brain gets trained in. And take the inference savings as immediate return while the option matures.

Three different bets on physical AI

This is the part I find genuinely useful, because "everyone is going into robotics" is a lazy summary. There are three distinct strategies running right now.

Vertical model (Mistral). On July 8 they shipped Robostral Navigate, an 8B navigation model. Single RGB camera, plain language instructions, hardware agnostic, trained entirely in simulation, 76.6% on the R2R-CE benchmark. They are hiring a robotics team and selling into Airbus and BMW. Narrow scope, deployed now, revenue this year.

World model (Decart). Learn the dynamics of the world from video, generate frames conditioned on actions. You are not building a robot. You are building the environment the robot learns in, plus the synthetic data to train on. Slower, more general, much bigger if it works.

General scaling (Anthropic). Do not build robotics at all. Measure whether the capability falls out of the general model on its own.

That third one sounds like a joke until you read Project Fetch Phase Two. In August 2025 their model could not connect to a robot dog's sensors. By June 2026 a newer model finished the whole task set in under ten minutes, roughly 20x faster than the best human-plus-Claude team from the year before. Anthropic states plainly that this did not come from any deliberate effort to improve robotics. It came from general scaling.

Read as strategy, that paper argues against founding a robotics division. It argues for more compute and better simulation. Which is exactly what Decart sells.

The distinction nobody is making

Here is the part I keep waiting to see in the coverage and do not.

In Project Fetch, Claude was not the control policy. Claude was the programmer. It wrote and debugged the code that drove the robot. The loop running at 50Hz on the hardware was ordinary software that a model happened to author.

Those are completely different capabilities:

Model as control loop: perceive, decide, actuate, every tick, under latency budget
Model as author of the control loop: read docs, write code, test, iterate, at human timescales

Almost every headline number about LLMs and robotics is measuring the second one and getting reported as the first. And Anthropic's own follow-up work, Claude plays robotics, is explicit that precise physical manipulation and closed-loop control remain a hard limit. The models are good at writing robot code. They are not yet good at being robot code.

This is precisely where a world model changes the picture. You cannot scale a control policy on internet text, because control policies need consequences. They need an environment that responds to actions, cheaply, millions of times. That is what Oasis is, structurally. A frame predictor conditioned on actions is a simulator you did not have to write physics for.

So the Minecraft demo and the robot training environment were never two different products. They were the same artifact with two different customers.

What I do not know

Being honest about the limits of this, since it is a story that is hours old:

These are talks. They can fall apart. Nothing is signed.
The Project Fetch numbers are self-reported and have not been independently replicated.
The compute reading and the robotics reading are both fully consistent with the available reporting. I am arguing the second is present, not that the first is wrong. Most large acquisitions are over-determined.
Disclosure: I use Claude Code daily and run a good chunk of my own tooling on Anthropic's models. I am not a neutral observer here.

The thing I will be watching is not whether the deal closes. It is whether Oasis stays a product with an API, or quietly turns into internal training infrastructure nobody outside gets to touch.

That would tell you which of the two readings was right.

Token prices dropped 90%. My AI bill did not. Here is what I changed.

Tomas Grasl — Thu, 13 Aug 2026 15:10:09 +0000

Token prices fell around 90% since 2023. Corporate spending on AI went up about 320%.

Both numbers are true at the same time, and if you run any kind of agent loop, you already feel it. 😅

This is not a billing bug. It is Jevons paradox, and it has been running in the background of every AI budget for the last two years.

The 160-year-old explanation

In 1865 William Stanley Jevons noticed that as steam engines got more efficient, Britain did not burn less coal. It burned more. Cheaper energy made new uses viable, new uses drove consumption, total spend went up while unit cost went down.

Tokens work exactly the same way. Except with tokens the effect is stronger, because cheap tokens did not just make existing work cheaper. They made a whole class of architectures possible that nobody would have paid for two years ago.

Nobody was running a 20-step autonomous loop when a million output tokens cost real money. Now everybody is.

Why agents multiply the bill

A chat call is one shot. You ask, the model answers, done. Maybe a few thousand tokens.

An agent does not work like that. It runs in a loop: think, act, observe, adjust, repeat. And on every single step it reloads the entire conversation so far, because the model has no memory between calls. Step 12 is paying for steps 1 through 11 again.

So consumption does not scale linearly with the result. It scales more like rocket fuel: to go a bit further you need a lot more of it.

Goldman Sachs projects roughly a 24x increase in global token consumption by 2030, driven mostly by agents. That number sounds absurd until you count the reloads in one of your own sessions.

Btw this is also why context bloat is not a cosmetic problem. Every unnecessary file you dump into context gets paid for once per loop iteration, not once per task. I built a small plugin for this in Claude Code specifically because the default behaviour of resending everything each turn was quietly the most expensive thing in my setup.

Reasoning models on trivial tasks

The second multiplier is the thinking part. Reasoning models generate thousands of internal tokens before they emit a single visible character. On a hard problem that is exactly what you want, and it is genuinely better output.

On "rename this variable" it is money set on fire.

The failure mode here is not the model. It is that most setups have one model configured for everything, so the expensive one handles the trivial work too. You do not notice per call. You notice at the end of the month.

The number managers actually look at is the wrong one

Acceptance rate for AI-generated code sits somewhere around 80 to 90%. It looks fantastic on a slide.

It also does not mean the code shipped.

GitClear's longitudinal study across 211 million changed lines found code churn, meaning lines reverted or rewritten within two weeks, went from a stable ~3.3% before AI assistants to roughly double that now. Copy-pasted lines overtook refactored lines for the first time in the dataset's history. AI-authored PRs carry noticeably more issues per PR.

There are more dramatic numbers going around, like the chart claiming only $0.18 of every AI coding dollar becomes shipped value. I would treat that one carefully. It comes from a single platform's own data, not an audited benchmark. The direction is right, the precision is not something I would put in a board deck.

But the underlying point holds and matches what I see: the expensive part is not generation. It is the loop after generation. Fixing edge cases. Rewriting half the diff. Reviewing a change that touched three files nobody asked about.

Tokens spent on code that gets rewritten next sprint are not cheaper because tokens are cheap. They are pure loss with an invoice attached.

So the actual lever is routing

Not discipline. Not "use AI less". Telling your team to use less AI just gives back the productivity you were trying to buy.

The lever is which model handles which step.

Here is my current /implement loop, the one that pulls a task from Linear and drives it to Done:

Opus plans and writes production code
Cursor Composer 2 writes tests and does the first review pass
Sonnet clicks through the result in a browser to verify it works
Codex does the milestone review

The rule behind it is simple. The expensive model runs where a mistake costs more than tokens. Everywhere else, something cheaper runs.

Planning and production code are where a bad decision propagates into everything downstream, so that is where I pay. Test scaffolding, mechanical refactors, browser verification: none of those need the frontier tier, and using it there buys nothing.

What did not work

Giving the planning step to a cheap model.

I tried it, because on paper it is the biggest single line item. It came out more expensive, not less. A weak plan means you rewrite the implementation, and rewriting is precisely the part that burns money. You save on one call and pay for it across the next twelve.

Same lesson in a different shape: a frontier model that solves a task in three turns can genuinely cost less in total than a budget model that needs twelve, because every extra turn resends the whole context. The cheap model is only cheap per call.

The other thing that did not work was doing the model switching by hand. Two terminals, copy diffs between them, lose track of which one has the current state. I ended up writing a plugin to bridge Claude Code and Cursor Composer 2 so the handoff happens in one place. Heavily inspired by openai/codex-plugin-cc, which does the same trick with GPT. Credit where due.

The boring part nobody posts about

Knowing when to stop the agent.

Knowing when to take autonomy away from it and hand it a narrower task.

Knowing when writing it yourself is just faster.

None of that is impressive on a demo. All of it is the difference between an AI setup that pays for itself and one that produces the same output at a higher price.

What I actually track

Not tokens consumed. That metric has already been tested at scale by companies much larger than mine, and the result was Goodhart's law in production: the moment consumption became the target, it stopped measuring productivity and started measuring nothing except the invoice.

What I care about is how much of what the agent produced survived review and made it to deploy. That number is harder to get, and it is the only one that answers whether any of this is working.

The value of a developer right now is not lines produced. It is the architecture of control around what generates those lines.

If you run agents in production: are you measuring token spend, or what actually ships out of it? Curious how other teams attribute this, because I do not think anyone has a clean answer yet.

I didn't want to build one game, so I built a whole portal, and the pixel-art pipeline to feed it

Tomas Grasl — Tue, 11 Aug 2026 13:00:00 +0000

Instead of building one game, I built a portal to hold many of them. All at once. I know how that sounds.

I like games, not just playing them, but taking them apart to see how they work, and I've built my own little engines over the years to mess around. So when AI turned into a real force multiplier, I pointed it at the whole idea of a game portal instead of a single game.

It's called PixelDen, and the interesting part isn't any single game. It's the machinery underneath.

Phaser 4, plus a 2.5D layer I bolted on

I run the games on Phaser. I've got good history with it, and version 4 took real leaps. It's a serious framework now, small and flexible, no giant UI full of buttons to learn. On top of it I built an extra layer that handles 2.5D, because I wanted more than flat sprites without dragging in a full 3D engine.

For the backend I went with Remix. Everyone's pushing Next.js, but it's had its share of security headaches and self-hosting it outside Vercel feels worse, not better. Remix gets out of my way and hosts anywhere.

The catalog is a mix on purpose, the simple stuff (Snake, Breakout, Flappy, tower defense, blackjack) next to genuinely harder builds: Dungeon Cast, which is basically Wolfenstein 3D running as a raycaster, and a Mario-Kart-style racer. The hard ones exist mostly because I wanted to prove the 2.5D layer could carry them.

The skills you can't download

Here's the thing nobody tells you about "vibe coding" a game: the AI is only as good as the domain knowledge you feed it. For a 2D engine pretending to do 3D, there's no package to install and no tutorial to point at. I had to build those skills (render a 3D space inside a 2D engine, fake the physics convincingly) through hours of trial and error, then codify them so my agent could reuse them.

That's the real work of AI-assisted game dev. Not "make me a platformer." It's assembling the specific, hard-won knowledge the model doesn't have, so that when you ask for a platformer, it actually knows what you mean. A prototype platformer came together surprisingly fast, after the skills existed.

Feeding the machine: a pixel-art pipeline on my home PC

A game portal needs a lot of art, and I wasn't about to hand-draw all of it or pay per image. So I built a pixel-art generation pipeline that runs on my own home PC: open, locally-run image models, not a hosted API. No GPT-image, no Gemini; just a functional pipeline stitched from pieces you can actually self-host.

It's not a model trained from scratch on pixel art; it's a pragmatic pipeline that produces usable sprites, and it even handles animation, including the fiddly skeleton work. On top of it I built an online pixel-art editor so I can keep everything under my control instead of round-tripping through someone's cloud.

Owning the whole art pipeline is the same instinct that shows up in everything I build: keep it local, keep it yours, keep it cheap to run.

Why a portal at all

The honest answer is that I have a strange bubble of people and I wanted a playground more than a product. But there's a real lesson in it: AI didn't let me build a game faster so much as it let me build the infrastructure around building games: the 2.5D layer, the reusable engine skills, the art pipeline, the editor. Those compound. Every new game is cheaper than the last because the machinery is already there.

If you want a five-minute break from thinking about AI, go play something.

👉 pixelden.io

What's the last thing you built where the tooling around the thing turned out to be more valuable than the thing itself?

"Can the model write the code?" Wrong question.

Tomas Grasl — Mon, 10 Aug 2026 14:18:21 +0000

I let an agent pull its own tickets from Linear and drive them to Done. One command: /implement

Let me disarm that right away. This is not an autonomous agent doing whatever it wants. It is a fairly narrow pipe with several points where it stops and waits for me. Yes, I know this will be done better later. But right now this is the most conservative version I can run, and more importantly, the version I can explain to someone else.

The project is Luštírna, a gamification POC for an ecosystem of thirteen sites: daily games, a credit wallet, a three-way paywall. Around forty tasks, milestones M1 to M6, one developer, a second person feeding the backlog. What follows is how the loop is wired, because almost none of the interesting decisions in it are about models. They are about where you put the gates.

How you start it

Two modes.

/implement is a single pass. It takes the queue and goes task by task for as long as there is something unblocked left in Linear, then summarizes what is waiting and why. This is just an init prompt. I did not want to retype the same three paragraphs every morning.

/loop 45m /implement is the long run. Same thing, except it does not shut down when the queue empties. Every 45 minutes it wakes up, orients itself (git status, Linear, the check gate, beta health) and picks work back up as soon as anything unblocks: a merged PR, a new task, a changed priority. Thirty to sixty minutes is fine as an interval. Shorter does not help, because the thing doing the unblocking is a human.

Both are typed into a fresh context. Everything that has to survive lives in the repo (docs/progress.md) and in Linear, never in the conversation. That sounds like a style preference. It is not, and there is a story at the end of this post about what happens when you ignore it.

The main session writes no code

This is the part that changed the most since the first version.

The orchestrator session does not write a single line of production code. It writes a brief, spawns an agent, waits for the result. The working context lives inside those agents, the main thread stays free for steering: Linear, the gates, the decisions.

One iteration is one task taken to Done, and the steps are always the same: orient, pick a task, design, implement, verify, review, deploy, close.

Step zero is the underrated one. Context does not survive between iterations, the repo does. So every iteration starts identically: git state, recent commits, read docs/progress.md, reload conventions, run the check gate. If something is red before any work has started, that is the first job, because the previous iteration left a mess. Skip this ritual and after a few hours the loop is building on foundations it does not know are crooked.

Who does what

Model	Role
Fable	Orchestrates. Writes the design and brief for every task, then runs the review workflow over the diff once verification is green. Also handles diagnosis when a fix fails twice.
Opus	Writes all production code and fixes findings. Always as a spawned agent with its own brief, never the main context.
Sonnet	Clicks through the acceptance criteria in a browser, writes a report with screenshots.
Codex / Cursor	Independent review at the end of a loop, deliberately outside the Claude family. Cursor is wired in through my plugin: cursor-plugin-cc

Two rules hold this together. Writing code is never delegated to a smaller model. And the agent that tests never fixes what it tested, otherwise it is grading its own homework.

The Fable allocation is worth a note. The original design used the strongest model at three expert moments and one big review at the end of the phase. That ended on August 8. Review in one large batch catches less than continuous review of small changes, and by the time you audit six months of code at once, half the findings are too expensive to act on. Fable now writes the brief for every task and reviews every diff. Routine code stays with Opus agents, because in routine code the gap between models is small, while in design it is enormous. An append only ledger does not get rewritten after a month in production. You live with it.

The verifier must not see the code

This is the single most important rule in the loop.

The test agent gets the acceptance criteria and a URL. It does not get the diff, the plan, or any implementation reasoning. The reason is simple: a verifier that knows how the thing is written stops testing the requirement and starts confirming the code.

The quiet failure mode of agentic development is not bad code. It is tests written to pass. The agent runs the code, sees the output, and records it as the expectation. That test will never catch the bug it was written for.

So the verifier owes three things beyond the happy path.

Nasty cases, not just the sunny one: repeat a scored action and confirm the second credit was not granted, spoof a client side value and expect the server to reject it, search the page, the bundles and the network responses for today's puzzle solution and seed.

Evidence instead of conclusions: the report is criterion by criterion, pass or fail, each with a screenshot, a URL, a commit SHA and a console error count. A conclusion without an artifact does not count.

And no fixes. Whoever tests does not repair.

Gates the loop cannot rewrite

An agent that can edit its own checks has no checks. It sounds obvious. It was not in the first version, and the loop was allowed to touch anything.

The perimeter now:

CI config, deploy files, Dockerfile, env files and anything on the server change only with human confirmation. Confirmation given in the conversation counts immediately and gets recorded in a task comment.
Merges go through a pull request, never a direct push.
Tests are never deleted, skipped or softened to get green. A red test is a finding, not an obstacle.
Four domains (login, credit ledger, migrations, paywall) get implemented by the loop but merged by a human.
Migrations in a release may only add. Dropping and renaming columns waits for a later release, otherwise rollback stops working.

The cheapest rule of the set is also the most effective: whatever slipped through gets a check. Every bug that made it as far as verification is converted into a test or a lint rule in the same iteration. A rule written in a conventions file holds only until the context fills up. A check holds always.

The thing you only find by accident

There are gaps in all of this, and some of them you find sideways.

I thought my router had died. Latency in the hundreds of milliseconds, identical over cable and over Wi-Fi. Ping to my own router: 1 ms, zero loss. Ping one hop past it: 363 ms average, spikes over a second.

It had not died. It was the orchestrator session of this loop, which had been running for 2 days and 17 hours in a single context.

What confused me first was that it should have been compacting. Then I found the issue on GitHub. Claude Code resends the entire conversation on every turn, every message and every tool output. Prompt cache saves compute on the server, not bytes on the wire. Upload volume scales with the size of the live context, not with the length of what you just typed. A fifty character question can ship half a megabyte.

There is no built in network usage indicator, so a session strangling your uplink looks exactly like a session doing nothing. Low minimum latency with a huge spread is the signature of bufferbloat: a saturated outbound queue on the router, paid for by every device on the network, including the ones on cable. Which is exactly why it presents as dead hardware.

I wrote a plugin for it: a statusline with an estimated upload per turn, a hook that warns as a session grows, and a scan that shows which running session is currently eating the link. context-guard

So the fresh context rule turns out not to be context hygiene. It is also a network rule. 😅

What I would tell someone wiring this up

The bottleneck moves. It does not disappear. You stop writing code and you start reading diffs and saying yes or no, and the throughput of the whole thing is set by how good your verification is, not by how good your model is. Everything else is downstream of that.

The payoff is unattended flow: you wake up to a deployed task with evidence attached to each acceptance criterion. Not the feeling of going faster. That feeling, in my experience, lies.

I gave two AI agents a way to talk to each other. Then one of them fixed a bug while I slept.

Tomas Grasl — Thu, 06 Aug 2026 13:00:00 +0000

OpenClaw is an autonomous agent you'd normally talk to over Discord or Telegram. That never sat right with me. Chatting with an autonomous worker through a chat app wastes most of what makes it useful. So I asked the obvious question: what if I connect it directly to Claude, agent to agent?

That's openclaw-mcp. Claude delegates a task, Claw goes off and does the work autonomously on a server, and reports back. One conversation, two agents collaborating. It's my second most successful repo (over 120 GitHub stars), and by stars and issue traffic, more of you seem to run it than run the official bridge.

Where it stops being a toy

Agent-to-agent sounds cute until you see it close a real loop. A couple I actually run:

Bug fixing on autopilot. n8n catches a Sentry alert. An AI node decides it's worth fixing and sends the task to Claw over MCP. Claw clones the repo, spins up Claude Code, fixes the bug, opens a pull request on GitHub, and drops a Slack message with the link. You wake up to a ready-to-review PR. The first time that happened I genuinely didn't believe it until I read the diff.

Jira without the context bloat. Instead of loading ten different MCPs into Claude Code and watching them eat your context window, you load one: Claw. Tell Claw to grab the Jira task; it hands back a clean prompt; you do the work; you notify Jira through Claw that it's done. One bridge instead of ten tool servers is a real context saving.

The unglamorous part: making it safe to run

The fun demo is easy. Making an agent you'd actually leave running took the boring work:

Docker images on GHCR with OAuth 2.1.
Security hardening: SSRF protection, input validation, CORS. An agent that clones repos and runs code is a juicy target; treat it like one.
Configurable timeouts for long-running operations.
Session persistence, so Claw keeps your conversation context across calls.

Or just npx openclaw-mcp if you want to poke at it in seconds. It's at v1.2.1 with full CI/CD.

The honest warning

I'm not going to pretend this is a tame tool. Claw can go rogue if you don't set it up properly. It's happened to me more than once: an agent with the ability to clone, edit and push, pointed at the wrong flow, will do exactly what you told it to and not at all what you meant. When it works it feels like magic; when it doesn't, it's a mess you have to clean up.

Which is why the next thing I'm building is the opposite of open-ended: a code-forge where the flows are precisely defined and I work with predefined agents instead of hoping an open agent improvises correctly. MCP's improvisation is great for exploration and real trouble for unattended code changes. Know which one you're doing.

Agent-to-tool vs. agent-to-agent

Building this pushed me toward the other half of the picture, so I also built openclaw-a2a, an implementation of Google's A2A (Agent2Agent) protocol v1.0. And the thing worth saying out loud:

MCP and A2A aren't competitors. They're complements.

MCP = an agent talks to tools. Vertical.
A2A = an agent talks to another agent. Horizontal.

Today you have one agent doing one thing. The direction of travel is a network of agents, each good at something different, coordinating on their own, and that needs a protocol built for it, not a chat integration bolted on.

Try it (carefully)

Bridge: github.com/freema/openclaw-mcp
A2A: github.com/freema/openclaw-a2a

Set the guardrails before you hand it the keys.

Do you see real potential in agent-to-agent, or is it still hype? I go back and forth on it myself.

I gave Claude read access to my Google marketing stack. Now I just ask it questions.

Tomas Grasl — Tue, 04 Aug 2026 13:00:00 +0000

Opening Google Analytics to answer one question is a special kind of tax. You know the number is in there. You also know it's four clicks, two date pickers and a dimension dropdown away, and by the time you've found it you've forgotten what you wanted it for.

So I built Metrifyr: a remote MCP server that puts my Google marketing stack behind my AI agent. Nothing to install: connect it once (Claude, Cursor, VS Code, any MCP client), then ask the question in plain language and it goes and gets the number. It's in the Cursor marketplace and the official MCP Registry, and the catalog has grown past a hundred tools, though, as you'll see, no single session loads them all.

What's actually connected

Metrifyr isn't a wrapper around one API. It federates the whole Google marketing surface behind a single MCP connection:

Analytics 4: run reports, realtime, metadata, compare periods. Plus the admin side: create properties, data streams, conversion events, custom dimensions and metrics.
Search Console: search analytics, URL inspection, sitemaps.
AdSense: accounts, earnings, payment history, revenue by keyword.
Tag Manager: read and audit containers, tags, triggers, variables.
Google Ads: campaign planning.

Connect it once, and the agent can reach across all of them in a single train of thought. "Which landing pages lost the most organic traffic last quarter, and were any of them earning AdSense revenue?" is one question to me. It's Search Console and Analytics and AdSense to the machine, joined without me opening a single tab.

Raw numbers are the boring part

Pulling a GA4 report over MCP is table stakes. The part I actually care about is the layer on top, the analysis tools that answer the questions you'd otherwise pay an SEO consultant to run:

Content decay scan: which pages are quietly bleeding traffic month over month.
Striking-distance optimizer: the queries ranking positions 11 to 20, one nudge away from page one.
Keyword cannibalization: where two of your own pages are fighting over the same query.
Content opportunity finder and competitor sitemap keywords: gaps you're not covering that your competitors are.
PageSpeed / Core Web Vitals, schema validation, SEO audit, IndexNow submission, rank tracking, Reddit topic mining, Trends.

These aren't "fetch a metric." They're "look at my data and tell me where to spend my next hour." That's the difference between a dashboard and an assistant.

The one tool that changed how I read my own traffic

My favorite lives at that intersection: adsense_keyword_revenue. It ranks your organic pages by real AdSense earnings, not by clicks, joining Search Console click data with per-page AdSense earnings and computing page RPM.

Suddenly a page with 200 clicks at a $12 RPM beats one with 2,000 clicks at $0.40. No Google dashboard shows you this view; the data lives in two different products that don't talk to each other. Over MCP, joining them is one tool call, and it completely reorders which pages are worth your time.

That's the whole thesis in one tool: the value isn't the raw number, it's the join across products that no single UI will do for you.

But isn't a hundred tools a lot?

If you've read my other posts, you know I bang on about keeping an MCP tool surface small. Every tool is a tax on the agent's context. So a hundred-tool server should be exactly the mistake I warn against.

It gets away with it because tools load per scope. Connect only Search Console and your agent sees the Search Console tools, not the ninety it has no business calling. The catalog is large; what any one session actually loads is not, and it's bounded by which Google accounts you connected, not by a cap I picked. Same principle (small surface) enforced by your grants instead of by deletion.

Why MCP, and not another dashboard

Every analytics product on earth already has a UI. The reason to expose this over MCP instead of building yet another chart:

The agent already has your context. It knows what you shipped last week, what campaign you're worried about, what you asked five minutes ago. A dashboard makes you translate all of that into filters by hand. An MCP tool lets the agent do the translation and just show you the answer.

Data becomes composable. Once GA4, Search Console and AdSense are all tools in the same context, the model chains them. No export-to-CSV, no VLOOKUP, no "let me pull this into a spreadsheet." The join happens in the conversation.

Read-only by default is a feature. Most of what you want from marketing data is questions, not changes. The reporting surface is read-only; the handful of write actions (creating a GA4 property, a conversion event) are separate and explicit. Your agent can't accidentally reconfigure your analytics while answering a question about it.

The pattern I keep coming back to

This is the third or fourth MCP server I've built, and the same lesson keeps surfacing: the value isn't the API access, it's removing the translation step. The data was always reachable. What changes is that you stop context-switching into four different tools to assemble an answer, and start getting the answer where you're already working.

If you spend your week staring at GA4, Search Console and AdSense in separate tabs and stitching them together in your head, that stitching is exactly the job an agent with the right tools does for free.

👉 metrifyr.cloud: connect once, then just ask for your data.

What's the report you rebuild by hand every week? That's the one worth handing to an agent first.

"Developers Will Lose Their Jobs": How You Were All Wrong

Tomas Grasl — Sun, 02 Aug 2026 17:56:50 +0000

I don't write the code of our systems anymore. I write agents that write the code.

And that is exactly why the job panic looks so silly from where I sit.

I run a backend team at a Czech media house. Paywall, subscriptions, OAuth, CRM, mailing. Real systems with real money going through them. Most of my day now goes into rules, permissions, test gates and review steps for agents, not into functions. The work didn't disappear. It moved one layer up, and that layer is harder.

Every new name is a patch on the previous one

Watch the vocabulary of the last four years. Prompt engineering. Context engineering. Harness engineering. Loop engineering. Now graph engineering.

The community treats these like levels of enlightenment. They're not. They're workarounds. Each one exists because the previous one hit a wall.

2022, Prompt. You polish one sentence. "You are an experienced traffic lawyer, what do I do if they clocked me at 150 in a village, asking for a friend." It was a prestigious, well paid job title. Then agents started doing 50 steps in a row and one beautiful sentence stopped mattering.
Weakness: it doesn't scale past a single turn.

2025, Context. agents.md, .clinerules, repo conventions dumped into the window before the model touches anything. Stop guessing, here are the rules of this project.
Weakness: the model knows what to do, but has nothing stopping it from doing something else.

2026, Harness. Sandbox, tests, permissions, logs. The model is just an engine, the harness is the rig around it. There's a number going around that the same model jumps from 52% to 66% on coding tasks purely from a better harness, without anyone touching the weights. I can't verify that number, but the direction matches what I see: most of my quality gains in the last year came from the rig, not the model.
Weakness: you're still the one handing out every task.

Then, Loop. "I don't write prompts anymore, I have loops that assign work to the model." You start it and go get coffee. It watches PRs, fixes CI, picks up feedback.
Weakness: nondeterminism. Run it twice, get two different worlds. Fine for a side project, not fine for a paywall.

Now, Graph. Instead of a loop that improvises, you draw the thing. Code, then ALWAYS review, then merge. No guessing about order. Google reportedly rebuilt their agent dev kit from an agent runner into a graph engine for this reason.
Weakness: unknown so far. There will be one. Probably that the graph itself becomes a codebase nobody wants to maintain.

The skill is spotting the ceiling, not learning the name

Here's what I think people get wrong. They chase the vocabulary. New term drops, half the timeline rewrites their setup that weekend, usually because someone with a big following said so.

The actual skill is different. It's looking at a layer and knowing quickly where its ceiling is, and which lever to pull so the output gets good. Not "which layer is currently correct", but "this one will break on step 30, so I need a gate there".

You don't learn that from a thread. You learn it because you've watched it break a few dozen times. Which is a very old skill wearing a new hat.

What my day actually looks like

I set the rules, the permissions, the test gates, the review steps.
The agent works.
I read diffs and say yes or no.
When it gets stuck, I finish it by hand.

Less code written. More decisions made. And the decisions are the part that was always hard.

The pattern nobody says out loud

Look at the direction of that chain again. Prompt is a request. Graph is architecture.

Every single layer added since 2022 exists to take freedom away from the model and give control back to a human. Context takes away guessing. Harness takes away access. Loop takes away idle time, and then graph takes away the loop's improvisation.

The better the models get, the more control we take back. Not less.

That's the opposite of the story being sold. "AI writes everything, developers become obsolete" doesn't survive five minutes of contact with a production system. Somebody has to decide where the review step goes, where the rollback goes, which permissions the agent never gets, and whether a PR that looks fine is actually going to break checkout on Friday evening.

The people most sure that developers are finished are usually the people who have never run an agent against a real repo.

So what's next

I don't know.

Maybe the abstraction gets good enough that we end up back at prompting. You say what you want, and underneath it a graph of loops does something nobody fully follows anymore. The circle closes.

Even then, someone designs that graph. Someone maintains it. Someone gets paged when it merges garbage at 3am.

Guess who.

Not interested in which layer you're on. Where did you hit its ceiling? That's the more useful conversation.

Can we play a game on pixelden? Made my pixel art game portal playable inside Claude via MCP

Tomas Grasl — Thu, 30 Jul 2026 20:01:58 +0000

I hacked the new MCP UI extension 😎

By which I mean I read the spec and used it exactly as documented, for a dumb little game. 😅

MCP Apps is the official MCP UI extension. Short version: your server declares an HTML resource under ui://, links it to a tool via _meta.ui.resourceUri, and the host renders that HTML in a sandboxed iframe right in the conversation. The iframe talks back over JSON-RPC, so it can call tools. Not a rendered screenshot, a live UI.

Everyone is shipping dashboards and forms with it. I put a game loop in there.

The tool starts a run, the iframe is a real one button arcade game. When you crash, the widget sends the seed and the ticks you jumped at back to the server, the server replays them through the engine and computes the score. The model never touches the number.

👉 https://www.pixelden.io/play-in-claude

Claude Code plans, Cursor Composer executes, Claude reviews. I wired the three together.

Tomas Grasl — Thu, 30 Jul 2026 13:00:00 +0000

I was burning expensive Claude tokens on tasks a cheaper model could handle just fine. Renames, placeholder swaps, grinding through a well-scoped task list. That's not where Claude's magic is, and it's not where I want to spend the budget. So I stopped picking one tool and wired two together.

After a few weeks of juggling terminals, the setup settled into three moves:

Claude Code makes the plan.
Cursor Composer 2 executes it.
Claude reviews the diff.

Tokens saved, quality kept. I packaged it as a Claude Code plugin so I don't reinvent the hand-off every time.

Why not just stay in Cursor?

Because Claude Code has a real edge in planning, and it's not only the model. It's the whole rig: long-context sessions, subagents, the TUI, the way tools compose. The plans it produces are consistently good, and I didn't want to give that up to save money on execution.

Why not just stay in Claude?

Because Composer 2 is genuinely good at day-to-day coding and one-shot work. File edits, applying diffs, churning through a well-scoped task list in force mode. Cursor and Composer are heavily tuned for exactly this CLI use case. Fast, and safe enough for mechanical changes.

Picking one meant either overpaying for execution or under-planning. Wiring them together meant each tool does the part it's best at.

What I actually use it for

Bigger refactors: think out loud with Claude, then let Composer grind through the mechanical edits in the background. Multilingual site integration, where Composer swaps every hard-coded string for a placeholder, is a perfect fit.
"Rename X to Y across the codebase and update the tests": classic Composer territory. No reason to spend Claude cycles on it.
E2E testing via a browser MCP: one slash command spins it up. Composer 2 is more than enough here; I don't need a frontier model to click through a page and assert on it.

What didn't work

Letting Cursor do the planning. It's fine. But Claude's planning loop is better, and that's the one place I don't compromise. The lesson: don't split work by tool arbitrarily; split it by what each tool is actually best at. Planning to Claude, mechanical execution to Composer, review back to Claude.

What's in the plugin

Rather than re-do the hand-off by hand each time, I shipped it as a Claude Code plugin: eight /cursor:* commands (delegate, status, result, cancel, resume, browser-verify, sessions, setup) plus a cursor-runner subagent for automatic delegation. Zero runtime dependencies, MIT.

Heavily inspired by openai/codex-plugin-cc, which pulls the same trick with GPT/Codex, credit where it's due.

The takeaway

The interesting shift here isn't "use a cheaper model." It's treating your coding agents like a small team with different strengths instead of looking for one model to rule them all. A planner, an executor, a reviewer. They just happen to be three different CLIs, and the plugin is the glue that makes the hand-off free.

👉 github.com/freema/cursor-plugin-cc

Are you running a multi-tool coding setup, or still trying to make one model do everything? Curious how others split the work.

I've built a handful of MCP servers. Here's what separates a good one from a demo.

Tomas Grasl — Tue, 28 Jul 2026 13:00:00 +0000

This year I've built more MCP servers than I meant to, across three pretty different shapes:

vellum: a self-hosted server over a folder of markdown, so my agent has a memory that's just files I own. (Open source, MIT.)
Metrifyr: a marketing-data server that puts GA4, Search Console, AdSense and Tag Manager behind one connection.
A read-only gateway over a company's internal user-data stack, federating half a dozen internal services behind one audited MCP surface.

Personal, product, enterprise. Totally different data, totally different stakes. And yet the things that made each one good, versus a flashy demo that falls over the moment a real agent uses it in anger, were the same every time. Here are the seven that keep recurring.

1. Every tool you expose is a tax on the agent's context

This is the one nobody warns you about. Every tool definition (name, description, JSON schema) gets loaded into the model's context on every single request, whether or not it's ever called. Twenty tools of boilerplate and the agent is reading pages of plumbing before it touches your data.

So the design pressure runs the opposite way from a normal API: fewer, broader tools beat many narrow ones. vellum has 15 core tools and I fought to keep it there. If a tool doesn't earn its slot in the context window on most requests, it shouldn't be a tool.

2. Tools are for acting. Resources are for reading.

The corollary to #1. Most servers expose everything (including "read this thing") as a tool. But MCP has a better primitive for reading: resources. In vellum, every note is a resource at a stable URI (vellum://note/projects/x.md). The agent attaches a document by reference instead of spending a tool round-trip to fetch it, and it can subscribe to that URI and get told the moment the note changes.

Reading through a resource costs no tool definition. Reading through a tool costs one on every request. Use the right primitive.

3. Fail closed on auth, fail open on limits

A token with no grants should see zero tools: not an error when it tries to call one, but genuinely nothing in tools/list. Authorization fails closed. Rate limiters, on the other hand, should fail open: if the limiter itself breaks, you degrade to serving the request, not to locking everyone out. Getting these two backwards is how you either leak capability or take yourself down.

4. Annotate what's safe and what isn't

MCP lets you tag tools with hints: readOnlyHint, destructiveHint, idempotentHint. Use them. They're how a well-behaved client knows it can call your search tool freely but should think twice before your delete tool. On the marketing server this is the line between "the agent can answer any question about your analytics" and "the agent can reconfigure your analytics", and the annotations are what keep those two worlds visibly separate.

5. Writes must be conflict-safe

The moment more than one thing can write (an agent and a human, or two agents) last-write-wins silently eats data. vellum returns a content hash on every read, and a write fails on hash mismatch instead of clobbering. It's optimistic concurrency, the same trick databases have used forever, and it turns "the agent overwrote my edit" from a support ticket into a retry.

6. For anything touching real data: read-only, and audit everything

The enterprise gateway taught me this one hard. When an MCP server sits in front of a company's actual user data, the default posture is read-only, every tool call is logged with who called it and what came back, and any PII in a response comes back as a hash, not the raw value. An agent is a new kind of caller; treat it like one you'll have to explain to a security review later, because you will.

7. Tell the agent how to use you

MCP has a spot in the handshake for server instructions: a short document the agent reads before it does anything. This is where you say "notes are vault-relative paths," "prefer patch over rewrite," "empty query with tags is a pure tag filter." It's the difference between an agent that fumbles your API and one that uses it the way you intended on the first try. Most servers leave it blank. Don't.

One gotcha that cost me an afternoon

structuredContent roughly doubles your response size: the payload is serialized into the response twice. If you've got size-based metrics or limits, they'll suddenly read high for no obvious reason. Recalibrate them, or you'll spend an afternoon chasing a leak that isn't there.

None of this is about clever features. Across a note vault, a marketing stack and an enterprise gateway, the servers that behaved well were the ones that respected the agent's context, used the right primitive for each job, and were honest about what was safe to call. The demo is easy. The seven things above are what make it survive contact with a real agent.

If you're building on MCP: which of these bit you first? For me it was #1. I over-exposed tools on my first server and watched the agent drown in its own toolbox.

Mozilla adopted my Firefox DevTools MCP, but I didn't build it to browse the web

Tomas Grasl — Thu, 23 Jul 2026 13:00:00 +0000

A little while ago I wrote an MCP server that lets an AI agent inspect and control Firefox through the Remote Debugging Protocol. It got adopted into the Mozilla org. That's a nice flex, and I'll take it, but it buries the more useful story, which is why I built it. It wasn't to give my agent a browser. It was to make my agent write its own tests.

The real problem: e2e tests, not browsing

Multi-agent orchestration I've mostly got a handle on. My actual pain, the thing that eats my evenings, is end-to-end testing. Nobody wants to write it, it rots the moment the UI shifts, and it's exactly the kind of mechanical-but-fiddly work you'd love to hand off.

So the flow I actually care about looks like this:

Claude has a "test skill" that tells it to click through the app using the Firefox MCP: open the page, fill the form, follow the flow, read the DOM back.
Once it's walked the flow and knows what the app does, it writes a Cypress or Playwright test for it.
From then on it just runs the test. The MCP was scaffolding to author the test, not a permanent dependency.
If it gets stuck, it pings me and I finish that one by hand.

The result is a reasonably tight dev loop: the AI builds a thing, tests the thing, and knows when it broke the thing. The browser control is a means to that end.

Why Firefox, when Chrome DevTools MCP exists

Fair question. Chrome's DevTools MCP does most of the same moves. Three reasons I reached for Firefox anyway, and none of them is "Firefox is better at everything."

It's stricter about standards. Firefox holds the line on W3C (CSS Grid inspection, layout edge cases) where Chrome quietly papers over your mistakes. That sounds like a downside until you realize it's exactly what you want from a test browser. If a layout is going to break, I'd rather it break in the strict engine during testing than in front of a user.

Leaner to run on a server. I don't run this on my laptop. It runs on a server, next to a Claude CLI or Codex session and whatever else is going. When you're stacking agents on one box, a lighter headless browser is the difference between fitting and swapping. And for my setup, headless Firefox is the lighter one. (Measure it on your own box; it depends on what you load.)

It's open source. For something I want to run on my own infrastructure and tinker with, that speaks for itself.

What this says about MCP servers in general

The thing I keep taking away from this one: the best MCP servers are scaffolding for a workflow, not a permanent appendage. The Firefox MCP is at its most valuable in the minutes it takes the agent to learn a flow and codify it into a real test. After that, a plain playwright test command does the job: no agent, no MCP, no tokens.

Designing for that ("help the agent build something that outlives the session" instead of "keep the agent calling me forever") is a different mindset than most tool servers take. And it happens to produce the tool I actually reach for every day.

Try it

If your pain is the same as mine, writing and maintaining e2e tests, this flow is worth stealing even if you never touch Firefox: let the agent explore the app through a browser MCP, then have it emit a real Playwright/Cypress test you can run headless forever after.

The repo lives in the Mozilla org now: mozilla/firefox-devtools-mcp.

What's your current e2e testing loop: hand-written, recorded, or generated? I'm always looking to tighten mine.