SFisms defines “meat proxy” as:

A person who forwards AI-generated text, code, or other output without reading, understanding, or validating it. The person acts only as a relay between the AI system and the intended recipient.

Being a meat-proxy is to knowledge work what vibe coding was to programming.

In software engineering, since Karpathy’s definitional tweet, we have been experimenting with and solidifying ways to use agents in ways that enable us to build systems faster and with rigor and reliability. We did not “fully give into the vibes”, but have been trying to figure out how to do software engineering with agents.

We are seeing the beginnings of that with knowledge work. We need to do the same thing we did with vibe coding. Use agents for knowledge work but not “without reading, understanding, or validating it”. But the patterns and structures for doing so are not yet as clear as the software world.

Today, it would be a red flag if a SWE interview candidate were unfamiliar with or resistant to using agents for programming. Just like in 2015 it would have been a red flag if a candidate said they do not use IDEs. Similarly, I predict that very soon for all knowledge work jobs it will be a red flag if a candidate is not using agents.

Let’s spell it out – why should we be agent-maxing daily knowledge work? For software, the value proposition was clear. As Yegge and Kim put it in their FAAFO framework, agents allow you to build software faster, increase your ambitions, do so autonomously, make the process more fun, and carry out lots of experiments that buy you optionality. All those reasons transfer over to using agents for knowledge work, but the material and ends of it are different than software.

My driving motivation for agent-maxing daily knowledge work was avoiding the pain and frustration that comes with the admin and bookkeeping that is an inextricable part of all work today. I explained this as the “colored pebbles problem” (back in 2014!):

What I really need to keep track of are not emails and docs and appointments, but projects.

Imagine these emails/docs as pebbles, and each project as a collection of pebbles. This project is red pebbles. That one is blue pebbles. Yet another one is yellow pebbles. Then imagine throwing all of them on the floor. Then imagine being asked “can you construct for me a coherent state of all the yellow pebbles?” That’s how it feels trying [to] get a high-level view of a project from all these pebbles flying around.

I feel like email and shared docs are like assembly language, and we need an abstraction above them.

This is project management. We have tried to solve this with a plethora of tools, over decades. There is an entire job function – technical project management – at big tech companies, dedicated to solving this problem. We’ve all been in meetings with twenty stakeholders and a giant spreadsheet tracking projects and sub-projects and deliverables and blockers and owners and timelines and dependencies and the dreaded “green/yellow/red” status next to each.

This admin and bookkeeping is a large part of day-to-day knowledge work. I’d hazard to say this is even the majority of it.

Modern knowledge work consists of three main steps.

  1. Ingest and understand granular contexts from myriad sources. Email, docs, meetings, hallway conversations, Slack, Teams chats.
  2. Synthesize all that context into a new artifact, judgment or decision.
  3. Send that new contribution out into the corporate ocean to serve as input for everyone else’s step 1.

I call this the “read-cognify-write” (RCW) loop.

Complex projects are a long series of these read-cognify-write steps. A massive undertaking like launching a new product is composed of thousands of smaller RCW loops. Sometimes they’re strung together in bursts carried out in a few minutes, other times they might have weeks-long pauses.

You can probably guess by now where I’m going with this. Agents are the perfect processors for all this admin, bookkeeping, and large parts of the RCW loop are just the fodder agents need to do a great job. Agents are the perfect fit for solving the colored pebbles problem!

Think of all the things one needs to keep track of to advance any project: who owns which part of it, what is the status of it, what was discussed and promised in meetings, what action items are on me, when are they due, which action items are on other people etc etc. And then making sense of all that, how they fit together, which ones are actually important and on the critical path.

The crucial implementation challenge is getting all your work context (docs, email, meeting notes etc) into a form that agents can consume. The other part of this is maintaining a place for synthesized notes, status, and the relations among all these items.

My working setup is a work cockpit organized around projects, people, and open loops or TODOs.

An open loop might be something I owe someone, something someone owes me, or a decision we have not made. It has an owner, a state, and supporting evidence. Projects have current context and history. People are connected to the projects and commitments we share.

All this is just a bunch of markdown files in a folder. There’s some JSON in there too, but the agent itself came up with that as a structured representation to maintain some state, and established rules to keep it updated.

The following tasks have gone from becoming dreaded ordeals to quick lookups: before meeting someone, I want to know what we last discussed, what changed, what I promised, and what remains unresolved; looking at a project, I want to see what is moving, what is blocked, and where the next move is mine.

Jason Liu over at OpenAI has been advocating for a similar style of work.

I started with just chatting over the repo that contained these markdown files and an AGENTS.md containing my preferences and high-level context and instructions. But quickly I realized I needed a more bespoke UI that treats projects, people and action items as first-class objects. So I had the agent build me a web UI that shows me all that and also lets me chat at different levels of the hierarchy (task, project, people, or everything). That has rapidly become my central work cockpit.

So far I am loving it. We’ve all seen the meme about “workday is for meetings and email, evenings and weekends are for real work” which is funny precisely because it is true. This is the kind of setup that lets me get away from the dreaded admin and project management and actually lets me focus on the real work: strategy, direction, and the work that needs my particular brain. I wish that for all of us.