Gabriele Farei

Runtime agents🦞 want to inhabit your app's state machine, not talk to your interfaces, because models excel at code, not tool schemas. They want what they were trained on: app environments with typed modules, branchable state, verifiers to run against. 👇 Convenience and reliability is what you sell to attract them. Continuous improvement is how you keep them, and fight off the constant pull to self-build. Soon 👀

1/ open a plan from cc in nvim with <ctrl>+g if the default editor 2/ <space>rr to start the read (it will preload if you have the docker running) 3/ jump to the cursor with <g> (indicator per line shows loading) 4/ exit with <q> 👋

A small quality-of-life hack for my workflow: a Neovim plugin for long-form markdown reading. A local Kokoro 82M model reads aloud while the buffer tracks progress as you follow along. Built to fight context switching. 🔈 on

Half-formed theory: in coding, you can predict parts of the future by looking back. Pre-LLM code shaped post-LLM code. What comes next will be shaped less by handwritten software, and more by AI-generated code plus self-improving loops. So we are reinforcing what works. Which is why I suspect the Unix philosophy wins again, not as a fallback but as the full solution. I am still surprised by how much more reliable an agent is with just the filesystem + Unix commands than with new standards, domain-specific verbs, or heavily optimized JSON tool calling. I wonder whether the current CLI-everything wave eventually collapses back into the basics: VFS + code + shell, especially for long-running, high-agency agents where reliability rates matter.

👇

Defining what 'correct' means when there are multiple good answers, partial progress, or policy constraints is fundamentally a research problem, not a tooling problem.

Tasks without executable verifiers are just prompts.

👇

Barriers to entry may reappear in the race to scale horizontally. If access to compute becomes the main predictor of outcome quality, the market consolidates again. If entropy remains the better predictor, there’s still a shot.

speed is a such an easy thing to sell to repeated users where you have a lot of usage data for

@nikitabier found a lot of bugs this morning 🤔 Posts on my feed that disappear when I click on them, or phantom threads when i try to drop a comment

There is something to this idea, and prob the greatest demo of dynamic workers I have seen in my feed 👑 I wonder if this way of externalise execution might be a good pattern for claws. Keep it in the harness when the value is still figuring out what to do. Promote it into an API when the value is reliable execution of a known path. For Claws long term, we can't assume everything runs on a VPS, we need to start to think of ways of scaling. Also if you have more than one agent that makes use of the same pathway, this could be helpful too. Let us know where you take this next & any code you can share to play with it 🙏

Make instant apis. Tell your agent in English, it figures out the code and puts it on a dynamic worker. Get a shareable link to your new live API endpoint. The possibilities with this infra make me giddy!

The big engineering challenge of 2026 is how to horizontally scale intelligence. Gone are the debates on if, we firmly moved to how. Outcome/Eval driven engineering, recursive self-improvement (RSI), agent-to-agent commerce of [intelligence, data, execution]

outcome engineering is the turn of phrase I like the most to capture this. there is still real engineering, it just moves up the stack: defining what correct means, choosing the right verifiers, and giving agents an execution surface where they can search for the solution instead of being told the path

Eric Schmidt says the 10x advantage is no longer execution. It is defining what counts as success. A programmer writes a spec and an evaluation function, runs it at 7pm, and wakes up to what was invented overnight. The advantage now belongs to whoever can specify the problem precisely. The rest will be automated.

@QianZhengNexus @ivanburazin At runtime I think the problem of state gets even harder, I think there an agent should read the interface like a codebase, have the ability to test safely by branching state, get structured feedback on every action, roll back failures, and codify its learnings for the next time.

@ivanburazin Headless execution solves the surface area problem. The deeper problem is state — knowing which tool to call, when, and with what accumulated history. An agent with headless access to everything but no memory of what it tried before is starting fresh every session.

Agents need headless tools to work efficiently. Which is basically APIs + programmatic access built for autonomous systems. - Headless IDEs - Headless Terminals - Headless everything That's part of the tooling axis we build around the primitive.

@remiaxyz @gakonst Filesystem and unix commands was the solution all along

@gakonst grep and local context works best

RE: memory layer conversations. I still unfortunately don't buy RAG as a solution. Agent `rg`'ing across all folders w/ some -A / -B to gather surroundings of the keywords, and progressively exploring the grep seems right 80/20 to me still.

@cjpedregal @kleinerperkins @meetgranola Congrats guys!

Today we're announcing our Series C alongside some big updates that make @meetgranola better for your team and your tools. Excited to partner with Danny at Index and Mamoon at KP. Big things to come. Back to work!

As more background agents (cron & heartbeat) compete for the same subscription capacity, I started using a spare-capacity estimator based on the last 30 days of usage. Downstream agents only get allocated excess capacity during the week, and go to sleep when there is none.

lots of folks running expensive sandboxes but really all you need is a filesystem but really you don't even need a filesystem, you just need a filesystem API that frontends something like a database (often you care a lot about ACID compliance or indexability etc; @jeffreyhuber talks about this) you can do this with FUSE and lots of people are building really cool things this way but really you don't even need a filesystem API, because agents don't see the POSIX APIs they just see tokens in and tokens so really all you need is something that looks like a file system but frontends whatever you want - S3, Postgres, Chroma, durable streams, whatever coding agents are great "everything agents" but the problem is that you use an off-the-shelf harness it marries you to the filesystem so you get stuck with FUSE or NFS hacks OR you have to inject a bunch of extra MCP tools that are parallel to the 'real' fs tools but if you own the harness, you can own the control flow this lets you separate the tool INTERFACE from the tool EXECUTION. your tool can look like a normal FS read tool to the agent, but you can use whatever backend you want for the execution logic this unlocks lots of exciting things but it requires you build your own harness or use something more customizable

This is a very cool primitive to play with alongside runtime code agents

New site 👀

We are not going to replace all apps. We are going to unbundle them. Most apps will become execution environments: the deterministic layer around critical data, where intelligence and custom interfaces can run safely. That last layer is your company USP.