Don't be your team's meat proxy

When your agents run on your machines, your team can only reach them through you. Peter Steinberger, who created OpenClaw and now works on agents at OpenAI, calls that being a meat proxy. At OpenAI DevDay he showed his fix: move the agent sessions onto a shared team server, where anyone can read, prompt or pick up anyone's session.

The last two talks I wrote up were about the agents themselves: Dex Horthy's software factory and MintMCP's AI coworkers in Slack. Peter's is about the people around them. Everyone on his team had agents. They still weren't working together.

More machines didn't fix it

He opened with how his own setup grew this year. First the terminal: split screens, lots of Codex sessions, a finger on the escape key to steer. The models got better and he steered less, so he moved to the Codex desktop app, where running many sessions at once is easier. Then his laptop ran out of disk and his fans "sounded like a jet engine", so he spread the work over six to ten machines: devboxes, plus cloud boxes that run the tests.

None of that fixed the real bottleneck:

When my teammates wanted to get involved, they still had to come through me. You know, we were all working with agents, but we weren't really working together.

Meat proxy, take two

The term is Niklas Gruhn's. His August post, Don't be a meat proxy, is about someone who pastes AI output to coworkers without reading it, so the coworker might as well have asked the AI. It's an insult for a habit.

Peter uses it for something bigger: being the interface to the AI, passing messages back and forth. You can read every word your agent writes and still be one, if the agents only exist on your laptop. That's what's new for me in this talk. It's not about discipline. It's about where the sessions live.

Show me the prompt

His first try wasn't a server. One sentence can now produce tens of thousands of lines of code, but the conversation behind it stays on someone's machine. He reviewed plenty of PRs where he understood what changed, but not why.

So he added a skill that asked contributors to attach a sanitized transcript to their PR. Very few said yes, and he admits he sometimes said no too. Sharing how you talk to your agent feels surprisingly personal.

When his team made every session visible, it felt awkward for a day. They read each other's conversations, laughed a little, and then it was normal. Now they learn from each other's prompting and catch mistakes earlier.

The demo made the case better than the slides. He wakes up to a PR where Victor, a teammate, made the tables smaller, the day after Peter made them bigger. The old reflex would have been what he called a "not very Californian message". Instead he opens the work session behind the PR. Victor had reused Peter's own session, pinged him first, and fixed what Peter got wrong. Crisis over before lunch.

His conclusion is blunt: pull requests as the way to collaborate "just feels not the future anymore". On the team server, anyone sees and prompts anyone's session, so the one rule is to invite only people you're fine with messing with your sessions. Next, he wants to invite OpenClaw's top contributors: they get the tokens, and the project gets a bit of their ideas. "I think it's an amazing deal."

The server is a place, not an app

The sidebar of that server is full of small apps: CI times, community numbers (PRs opened, issues, merges), a "daily Claw" newspaper written from whatever merged, a slop meter that keeps pushing the agents to clean up, activity reports, and meetings. They used to pay for meeting software until he decided "this is a prompt". Now the agent joins their Discord calls, writes the summary, and can answer back by voice.

He describes a dashboard as a session that generates an artifact, plus an automation that keeps it updated. Want it blue? Tell the agent. It changes so fast he'd rather call it jellyware than software. And because each dashboard is a session on the shared server, anyone on the team can change it, not only whoever built it.

He also thinks CI as we run it no longer makes sense, and is trying Codex to pick which tests a change actually needs. He saved that one for another talk.

Loops, goals and taste

Then the factory part. He runs two kinds of long-lived work:

The triage loop is the one I'd copy:

Those loops used to run on his own machines. Sometimes they stopped, and sometimes he wasn't sure which machine was running which. Now he's moving them to the team server one by one, so others can maintain them and learn from them. Taste is the part he won't hand over: it's hard to describe and "often just a feeling". Where he wants to end up is an agent per project, with its own memory, automations, goals and loops, taking high-level direction from him.

That's the software factory again, with one change: the factory is a shared room, not one person's terminal.

Agents get their own badge

Kevin Lin, who leads OpenClaw Enterprise at OpenAI, took the second half and open-sourced it: a control plane that makes OpenClaw multi-tenant. The controls he walked through:

• the deterministic code runs in a separate container, in their case a separate cluster, so an agent can't change its own runtime
• sandboxing for network access, the files an agent can write and the repos it can push to
• auto-review: another model checks the agent's actions and blocks the dangerous ones before they run
• agents run as their own identities, with service accounts and their own connectors, because "agents aren't impersonating users"

That last one is the point of my AI coworkers note, now in an open-source platform. OpenAI runs over 400 Claws internally with these controls. He said that if you filed a Codex issue in the last month, there's a good chance an OpenClaw agent triaged it, reproduced it and, in many cases, merged the fix. He pitched it as Kubernetes for agents. The announcement says it's for internal pilots until 1.0, later this year.

Where my own fleet sits

Yesterday I wrote that next I wanted Nova, my generalist agent, to open a channel for a coding job and bring in Spark, my coder. That works now. Nova opens a job channel in Slack, invites Spark and me, and posts the brief. Spark builds, Nova makes the calls, and I only get tagged for things like secrets, spending or anything destructive. Since this morning the same flow runs in Discord forum threads.

So the agents talk in the open. By Peter's standard I'm still half a proxy, though: the channel shows what Nova and Spark tell each other, not the sessions behind those messages, and nobody but me can open those. For a team of one that's fine. The day someone works on these projects with me, his server is the first thing I'll try.

The talk is 35 minutes. The meat proxy slide is at 2:27, and the Victor story at 11:46 is the part I'd show a team lead. If your team already shares agent sessions, I'd love to hear how the awkward first day went.

Plain text: dont-be-your-teams-meat-proxy.md · Atom feed · All notes