← The stand
The Collection, Volume 1, Number 53. The Plumbing. Sunday 18 October 2026, Melbourne.

The Collection


Vol. 1, No. 53  ·  Sunday 18 October 2026  ·  Melbourne

The Plumbing


Editor’s Letter

They sped up the agent. The pipes were still sized for people.

Most of the year’s argument has been about the model and the harness around it. Which model, which prompt, which loop. Saturday’s paper asked what the agent should be allowed to remember. The weekend mail looks lower down, at the parts nobody puts in a keynote: version control, sandboxes, gateways, review queues, the share of a platform’s traffic that no longer has a person behind it.

The Generative Programmer argues that agents are having their Kubernetes moment, with lifecycle and networking moving out of the harness and into shared infrastructure. The DevOps Bulletin reports that Anthropic replaced Git after passing 30,000 merges a day. Dear Architects points to the Claude Code team moving review into the middle of the work. The Stack hears from Vercel that coding agents now drive 60 percent of its activity. And The Architect’s Notebook, writing about nothing to do with agents, supplies the warning the rest of the bag needs.

The agent got faster. The building around it did not.

The common thread is capacity. Tools that were sized for a person at a keyboard, a few merges, a few reviews, a few deploys a day, are meeting a workload that arrives at machine pace. Some of the answers are new pipes. Some are moving old pipes to where the model cannot talk its way past them. One is knowing which pipes not to lay. Sunday takes the kiosk window, and The Reset moves to the Saturday slot on this week’s rack.

The agent got faster. The building around it did not.

The Collection · The PlumbingLetter

04  ·  The Mains

The harness is handing its chores to the building

Lifecycle and networking are leaving the agent’s code, the way they left microservices a decade ago.

The letter starts with a precedent. Nearly ten years ago, infrastructure work moved out of microservices and into Kubernetes, service meshes and proxies. Configuration, secrets, rollouts, certificate rotation and traffic observability became things you set outside the application. The code kept the business logic. The author sees the same split forming around agents, whose logic increasingly lives in a reusable harness that runs code in a sandbox, loads skills from files and connects to tool servers through configuration.

The first chore to leave is lifecycle. An agent spends much of its time waiting on a model, a tool or a person, and an environment kept running through that wait holds memory and compute while doing nothing. The letter notes that LangChain’s Deep Agents documentation leaves sandbox scope, reuse and cleanup to the application. Agent Substrate takes them on: when the harness decides a pause is safe, it snapshots memory and filesystem, releases the resources, and restores the agent onto any available worker. NVIDIA OpenShell and the Kubernetes SIGs’ Agent Sandbox also move sandbox management outside the harness, with different priorities.

Access controls have to hold even when the model makes an unexpected choice.

The second chore is networking. A gateway can give the harness one API for several model providers, inject credentials outside the sandbox, route requests, apply budgets and token limits, authenticate callers and present tools from many servers through one endpoint. What stays in the harness is the hard part: planning the work, managing context, and verifying results against the goal. The author is careful that the products named are examples. The shift, not the vendor, is the point.

Thirty thousand merges a day, and a tool built for people

The DevOps Bulletin puts the week’s strangest infrastructure story in a single line: Anthropic replaced Git after reaching more than 30,000 merges a day. The Bulletin links the report and adds a meme, and leaves the design unexplained. A Medium writer, Greek Ai, names the replacement Scion in a headline and says it exists because coding agents produce changes faster than traditional development infrastructure can comfortably handle. That piece is member-only. The stand read the preview, and the name and the reasoning stay that writer’s account until the design is public.

The same digest carries a second number. AWS reports that its penetration-testing agent exploited 33 of 37 recent CVEs through the intended vulnerability, in audited, containerised tests, and the Bulletin’s tutorial list includes a post-deployment penetration-testing gate built on it. Alongside sit DigitalOcean on pausing and resuming Firecracker microVMs in milliseconds, and incident.io on what two years of building an AI SRE taught it.

Dumping 10,000 log lines into a prompt is poor debugging.

The Bulletin’s own take is the most usable thing in the letter. Do not pour the logs into the prompt. Give the agent a way to search by service, time window and request ID, let it pull more as the investigation develops, and keep the full logs where it can check what the first query missed. Its sample prompt asks for errors grouped by signature, with counts, a traced request from each group, and the original log lines for every finding. That last demand is the point: it gives a person something to verify when the agent names a cause.

Review moves from the gate into the work

Luca Mezzalira’s weekly architecture letter leads its picks with the Claude Code team. Addy Osmani, Morgan Westlee Lunt and Qing Wang describe how the team reviews changes written by agents, and the question they open with is the question of this issue: how do you review code at the volume agents produce it?

Mezzalira’s summary gives the shape of the answer. Review moves from a final pull-request gate to checks that run while the change is still being written, so people are spent on the failures only they can catch. The excerpt in his letter is precise about the target. Once the team had high coverage and deep reviews, it started optimising for the minimum amount of human review time that does not raise reverts or incidents. Review becomes a dial with a measured floor, not a ritual at the end.

An impressive diagram is often a warning sign.

Two other picks sit well beside it. Hillel Wayne shows how property strength, state-space verification and stated environment assumptions expose retry and double-execution failures while a system is still only a description. Sean Goedecke argues that state is the hard part of system design, that writes should sit behind one service, and that a good system is one that stays quiet for a long time. The stand read Mezzalira’s summaries of all three and leaves the full articles unread rather than guess at their detail.

Three percent in January. Sixty percent now.

The Stack’s Runtime letter carries the week’s plainest measure of load. At the beginning of 2026, coding-agent activity made up about 3 percent of overall traffic on Vercel’s platform. Founder and chief executive Guillermo Rauch told The Stack it now accounts for 60 percent, and that the company is changing its product strategy in response. A platform built for front-end developers now mostly serves machines.

The containment story runs alongside it. After what the letter calls OpenAI’s demonstration this summer of what a faulty sandbox can do, Perplexity has open-sourced SPACE, the Sandboxed Platform for Agentic Code Execution, under the Apache 2.0 licence. It is built on AWS’s open-source Firecracker microVMs, and Perplexity describes it as a production-tested base with isolation, state recovery, and credential and network controls built in. Chainguard, meanwhile, has launched a harness that uses Claude Mythos 5.1 to find and fix exploitable vulnerabilities, sold through the Claude Marketplace.

The gap is between monitoring and legal accountability.

Two more items price the problem. Proofpoint paid $6.3 billion for Varonis Systems, in part to get better at verifying agent activity on customer networks. And Datadog’s troubleshooting model, which Saturday’s paper met through Ken Huang’s letter, now has a name, Scout, a base, Z.ai’s open-weight GLM-5.3 Flash, and a private preview. The quote of the week, from Info-Tech’s Thomas Randall, is the one to keep: organisations may be unable to detect or demonstrate how an AI system caused a harmful outcome, and the deploying enterprise will usually carry more of the immediate reputational risk.

Every abstraction sends an invoice to the future

The Architect’s Notebook is not writing about agents, which is why it belongs at the end of this issue. Its example is an order API that works: it validates, checks the rules, saves the order, returns. Then come the reasonable suggestions, one at a time. A generic workflow engine. A database abstraction layer. Microservices. A validation framework, a rules engine, a plugin mechanism. None sounds absurd alone. Together they make a system harder to understand, test, deploy and operate than the problem justified.

The letter’s line for it is the one this paper borrows: every abstraction sends an invoice to the future, paid in maintenance, debugging, onboarding or operational support. Its rule for spending is specific. Invest early in the decisions that are hard to reverse, naming sound data ownership, security boundaries, observability and clear contracts. Keep everything else simple until real requirements justify more.

Build what matters. Make it good enough for the risks it carries.

Read next to the rest of the bag, the list is almost a specification. Sandboxes and gateways are security boundaries. Logs an agent can search are observability. A merge system that can keep up is a contract. Those are the pipes worth laying now. The letter’s three questions decide the rest: what problem exists today, what the improvement will cost, and what evidence would show it was worth doing. If you cannot answer them, the Notebook says, you may not have enough evidence to proceed yet.

Access controls have to hold even when the model makes an unexpected choice.

The Collection · The PlumbingPiece

Standing Orders

Five rules for this issue

  1. I

    Put the controls where the model cannot argue with them.

    Credentials, budgets, routing and network limits belong in the sandbox and the gateway, not in the prompt or the harness the agent drives.

  2. II

    Measure the tools against agent traffic, not human traffic.

    Merges, reviews, deploys and sign-ins were sized for people. Count what the agents now send through them before the queue tells you.

  3. III

    Review while the change is written, and measure the floor.

    Spend human review where only a person can catch the failure. Let reverts and incidents tell you when you have cut too far.

  4. IV

    Give the agent a search, not a dump.

    Let it query logs by service, window and request ID, keep the full record within reach, and require the original lines behind every finding.

  5. V

    Name the problem before you lay the pipe.

    Build early only what is hard to reverse: data ownership, security boundaries, observability, contracts. Everything else can wait for evidence.

The Collection · The PlumbingOrders