Durable agents, security boundaries, and rebuilding core tools
Intro
This week's links were a compact but useful cross-section of systems work. The agent stories were less about a smarter model and more about what has to surround it: durable task state, tool composition, sandbox boundaries, and the ability to inspect and steer a running system. Alongside that, a few projects are revisiting foundational infrastructure and developer tools rather than accepting old tradeoffs as permanent.
Agent harnesses are growing up into runtimes
1) Pi splits a hardened coding agent from a durable application substrate
https://earendil.com/posts/pi-1-0/ https://earendil.com/posts/pi-durable/ Reading note: Pi Durable extends a coding harness into long-running agent applications
Pi 1.0 adds features that fit its minimal coding-agent harness, including native MCP through codemode, deferred tool loading, virtual model extensions, and transcript-aware system messages. Pi Durable is a separate, experimental package for applications that need conversations and tasks to outlive one process, run against different execution environments, and be steered by multiple people. The design makes storage and task execution explicit pieces of the harness.
Why it matters: durable agent work needs more than keeping a chat transcript around. It needs task state, execution environments, restart behavior, and clear points where a human can resume or redirect the work. Pi’s choice to explore that in a separate package also keeps the stable coding agent from absorbing every experimental feature.
2) MCP support can be reconsidered without abandoning design principles
https://earendil.com/posts/you-said-no-mcp/ Reading note: Pi Durable extends a coding harness into long-running agent applications
Pi’s earlier argument against MCP has changed as the protocol and the team’s needs changed. The article’s more interesting point is about tool shape: MCP becomes more useful when it offers structured results and documentation-led discovery, and when tools can be composed inside a sandbox rather than dumped wholesale into model context. The authors still call out composition and uneven server design as problems.
Why it matters: a protocol decision is not a permanent identity. The useful question is whether the current version fits the system’s architecture, and what additional runtime machinery is needed to make it work well.
Sandboxes need precise, tested boundaries
3) Sandlock 0.8.9 works through process-sandbox edge cases
https://github.com/multikernel/sandlock/releases/tag/v0.8.9 Reading note: Sandlock 0.8.9 tightens Linux process sandbox boundaries
Sandlock is a Linux process sandbox built around Landlock and seccomp, without root, cgroups, or namespaces. The release fixes a filesystem confinement path involving absolute symlinks, exposes sandbox-owned sockets through virtualized /proc network tables, improves descendant-process cleanup, and adds composable allow/deny network rules. These are implementation details, but they are exactly where a sandbox boundary either holds or leaks.
Why it matters: “sandboxed” is not a single property. Filesystem resolution, process descendants, network visibility, and policy precedence all need concrete semantics. The release notes are useful evidence of the work involved, not a substitute for an independent security review.
A follow-up clarified that this was not merely an unverified rumor: Vercel CEO Guillermo Rauch confirmed a KVM zero-day through the Sandbox bounty program, and researcher Paulos Yibelo publicly described a guest-to-host root escape. The exploit chain, affected versions, prerequisites, and remediation details have not been published in those primary posts. Cyber Security News reports a $50,000 bounty. The supplied Tech Insider article adds plausible-sounding but unverified speculation about mechanisms and exposure across providers, so do not infer that all KVM, Firecracker, or cloud deployments are affected. Reading note: Vercel confirms a KVM zero-day, but the escape details remain unknown
Core infrastructure is still open to redesign
4) Blob-stream changes the operating model of high-volume streaming
https://blog.bitdrift.io/post/blob-stream-kafka-alternative Reading note: Blob-stream rethinks Kafka around object storage and stateless brokers
Blob-stream keeps recognizable streaming concepts such as topics, partitions, consumer groups, and durable acknowledgements, but writes data to S3 rather than broker disks. Its goals include stateless brokers, simpler Kubernetes-based coordination, and less cross-availability-zone traffic. That shifts the operational model instead of trying to make Kafka’s stateful broker model incrementally cheaper.
Why it matters: storage, network locality, and cluster operations can dominate the cost of streaming at scale. The design is worth watching, while its claimed advantages remain goals to validate in real deployments.
5) Deser revisits the shape of Rust serialization
https://lucumr.pocoo.org/2026/9/29/deser/ Reading note: Deser explores a different architecture for Rust serialization
Armin Ronacher’s Deser write-up starts from concrete Serde corner cases: arbitrary-precision numbers interacting with tagged enums, integer keys losing type information through flatten, and adapters that do not compose naturally through wrappers. The point is not that Serde is poorly made; some constraints follow from a stable design and ecosystem. Deser is an attempt to change the architecture while preserving a familiar Rust experience.
Why it matters: foundational libraries accumulate compatibility constraints. A good replacement case explains how those constraints interact and what a different design makes possible, rather than promising a drop-in fix for every user.
Product quality is part of ecosystem infrastructure
6) F-Droid 2.0 puts discovery and maintenance back in focus
https://f-droid.org/en/2026/09/24/f-droid-2.0-a-new-chapter-for-android-freedom.html Reading note: F-Droid 2.0 rebuilds app discovery around a new Android client
F-Droid’s ten-year client refresh moves to Kotlin Compose and reorganizes the app around Discover, Search, and My Apps. The release expands categories and filters, searches descriptions and translated content, and improves CJK search. The stated goal is to help users find and manage free software without tracking them or optimizing for engagement.
Why it matters: an open distribution ecosystem is only useful if people can navigate it and maintain what they install. Discovery and update flows are infrastructure for adoption, not just interface polish.
Also worth saving
Sujith Jay’s guide to inventing work for platform teams is a practical reminder that engineering-led teams need their own discovery loop. Look at signals from systems, users, the organization, and the industry, while remembering that incidents skew toward recent failures and internal toil is not necessarily user toil. Reading note: A staff engineer’s guide to finding platform work
The week also included a brief argument over whether model distillation is competition or theft. Jensen Huang’s reported position, as summarized by CNBC, was that learning from a competitor’s product is competition. That framing captures a live policy dispute, but the shared post was a reaction rather than a detailed account of the technical or legal boundaries.
Closing note
The common thread is explicitness. Durable agents need explicit storage and task machinery. Sandboxes need explicit boundaries and verified behavior. Streaming systems need explicit tradeoffs around storage and network topology. Even open app distribution depends on explicit attention to discovery and maintenance. The systems that feel simple to use are often the ones that have made these surrounding choices concrete.