Links

Okay, but what can I actually do with that token?

Even after building OIDC into orbs, it wasn’t immediately obvious to me how far we could push an OIDC-based dev env. So here are a few ideas to get the juices flowing, drawn from both internal usage and feedback from our early partners.

1. Configure workload identity federation in GCP and grant access to your production logs and metrics from all orbs in your workspace.

I’ve been banging my head around how to give the agent the credentials necessary for whichever task it needs to do in the sandboxI had decided without much conviction to inject encrypted secrets and have them be decrypted on sandbox boot with the caveats that I would spend more time researching a better solution later. .

To optimize for scale, we decided that everything taking O(sandboxes) or O(nodes) load must be horizontally scalable by default, the sandbox creation path should be as simple as possible, and everything else should be secondary. The solution we came to is notably different than existing systems. We completely dispensed with any sort of central coordination, and traded global consistency for scalability and performance everywhere on the critical path for running and creating sandboxes.

I have nowhere near the same requirements for my personal sandbox setup but it still super interesting to see how what is needed to reach massive scale.

I think that’s a great summary of the things we’ve done to make agents more productive in our codebase: don’t make them guess.

I’ve been trying to articulate to friends and colleagues why I never seem to have my agent screw up that much and it boils down to this: not letting them guess. Whether it’s via skills or instructions, but also toolinge.g. plugins for your favorite linter that explain why something is prohibited. and scripts, having everything in front of your agent decreases its chances of doing things wrong.

Of course it’s hard work to keep all of this up to date, but I find it way more rewarding than running a random npx skills addNo shade! and crossing finger that it will solve all my problems.

My initial instinct was to go full near-airgap: remove the default route, run an SNI-based TLS proxy on the host, and only allow traffic to api.telegram.org and openrouter.ai.

I built this with unbound returning fake DNS records pointing at the host bridge IP, nginx stream with ssl_preread doing SNI-based forwarding, nftables dropping everything in the FORWARD chain.

It worked, technically. But it was brittle. The proxy needed careful handling of dynamic IPs, and Openclaw’s error messages when DNS returned unexpected results were… unhelpful.

For this demo, I just said screw it and allowed everything (with a log). The VM has full internet access, but every DNS query and every new connection is visible from the host.

Continuing on my research around microvm, I discovered microvm.nix and yet another way of monitoring and/or locking down networking for vms that will be used by agents.

Agents naturally gravitate toward the smallest stable abstraction. So, in an agent-first world, the most important question facing product teams is not what features and why, but instead how do I design the right primitive ?

Building great developer tools (e.g. primitives) has always been an exercise in exquisite taste and deep domain expertise because it requires balancing a set of competing, and often contradictory, forces: namely the tension between expressivity and simplicity. — The primitive is the product

Will be super interesting to see how companies adopt this and it will truly be a differentiator in adoption.

A VM that can reach the host’s local network is a VM that can reach things it has no business reaching. So QEMU doesn’t run in the host’s network namespace at all. We unshare into fresh user, net and mount namespaces first. Inside that namespace a small wrapper bind-mounts a resolv.conf pointing at 127.0.0.1 so that QEMU’s built-in slirp DNS isn’t used, then installs blackhole routes for every special-use IP range (RFC 6890, so private networks, link-local, loopback, etc.) before it execs QEMU. slirp4netns then provides the namespace’s outbound internet connection, with --disable-host-loopback, sandbox and seccomp all on. QEMU runs inside that namespace, and the guest’s network card is attached to QEMU’s own built-in user-mode networking. So every packet from the guest takes two hops: guest → QEMU’s slirp → the namespace’s slirp4netns → the internet. The guest never sees the host’s network and the host’s network never sees the guest. All of this is done without needing any privileges!

I’ve been reading a lot about microVMs and Firecracker lately as I work on async agent side projectMore on that soon hopefully. and I find it super interesting how people tackel the same UX problems (in this case: locking down the network).

this is a huge reason why i use pi.

i absolutely do not want my harness regularly changing behavior out from under me, including system prompt changes, on top of an already stochastic llm

Imagine I have /skill-1 and /skill-2, both with disable-model-invocation: true I tell Claude Code: “/skill-1, /skill-2 do XYZ”

Which of the skills will be invoked?

I’ll give you a clue - the behaviour was one thing 3 weeks ago, another thing 1 week ago, and back to the original today.

Matt Pocock (@mattpocockuk) on Twitter

I’ve been playing around making my own harnessPi remains my main harness, but trying to think about how I work in this agent-looping world. recently, and also noticed how the behaviour of many Claude features seemingly seem to change every time I spin it up to test something. For my harness, I just decided on a simple principle: trying to keep the primitives (i.e. skills and mid-turn messages affect the agentMost of the time i want immediate steering, but I realized I do use follow-up quite a lot when leaving agents do their thing, especially when running in sandboxes and/or building prototypes where the result itself doesn’t matter much for me. ) consistent with how I expect agent to react.

introducing tau τ — an educational agent harness that teaches you how to build agent harnesses

This is so cool. I truly think we’re moving towards a world where writing/making a great agent harness ends up becoming accessible to most people because the knowledge is just readily available.

Application scope and user experience: Sun Microsystems co-founder Bill Joy famously said: “No matter who you are, most of the smartest people work for someone else.” That applies with particular force to AI. The range of what agents can do — and the variety of industries, workflows, and real-world contexts they touch — is so vast that no single company can build the best solution for all of them. We see a near-infinite opportunity to rewrite the world using agentic AI as foundational infrastructure, and it will require many companies with focused effort.

Thinking a lot about this lately, especially around my own use. I want from using Anthropic models and tools exclusively a year ago to barely using them and instead using different models in different harnesses depending on the task at hand.

It’s very likely that I’m part of the minority of AI users in this case currently but I wonder how long this will become more common ground amongst the majority of users.

Durable Objects now supports a new us jurisdiction. Create namespaces restricted to the US to keep compute and storage local.

i feel like i have a aluminium hatit’s called a tinfoil hat dummass , but it seems like everyone is preparing for us/non-us tiered system around llm access.

This article will sound like a schizo ramble, so prepare. To start off I want to state my true beliefs on the matter:

1. LLMs are not conscious and won’t ever be.
2. LLMs are inaccurate statistical machines.
3. Open Source AI is good but must get better.
4. I have no hatred, or malice for any closed source lab
5. I respect what I see as my peers at OpenAI, Anthropic, xAI etc.

You might think, well if that’s the case what’s the problem? These models aren’t intelligent, they can’t really replace people, can they?

Yeah that’s my shit.

been playing with exe.dev this weekend and was curious how they made ssh [vm-name].exe.dev just work, and it’s pretty cool: https://blog.exe.dev/ssh-host-header

we landed on a pretty good workflow for doing parallel work in OpenCode

this demo is with git worktrees but i also preview an alternative we’re working on at the end

this will be in 1.6.0

— @thdxr

Rift looks interesting.

Take a look, I really like how this is explained.

Closing my open tabs and finally read Mikker’s post. Borrowed his review workflow but wanted to have it in a Ghostty split (thanks to AppleScript).

I then had Kimi and GLM figure it out and make me an extension.

Current status.

Was about to make a Pi extension to communicate between sessions, but actually only needed Amp’s read thread tool.

Can’t help but re-read this every time I write “just” somewhere.

Banger.