Loop Engineering and the End of Agents

In this post, I share my most forward-looking ideas after experimenting with loop engineering.

Today, people talk to agents a lot. But think about what you are really doing when you talk to agents. You are digging through walls of text to fish out only 2 things: decisions you need to make, and actions you need to take.

So I propose a system that makes Decisions and Actions the first-class citizens, and agents the implementation detail.

eDPM

Some people today are automating the SDLC (Software Development Life Cycle) and merging hundreds of PRs a day with loop engineering.

But, you know Goodhart's law: "when a measure becomes a target, it ceases to be a good measure".

The easy PRs to push through are not the valuable ones. And agents always find something to polish. Feature PRs generate clean-up PRs. Even clean-up PRs generate clean-up PRs.

I propose a metric: eDPM

eDPM: effective Decisions Per Minute

An "effective decision" is one that requires my judgement. One where two reasonable humans could disagree, and that disagreement would have a meaningful downstream impact. In practice, it's one where my agents can't predict what I want.

eDPM is the thing to optimize for.

The EDA framework

Loop engineering reminds me of event-driven architectures (EDA):

• Events: past facts, like "task filed", "merged at sha X", or "I decided go, P1".
• Policies: rules like "whenever event X happens, decide, and then take action Y".
• Actions: something that results in new events.

Workflows like the SDLC can be seen as a chain of policies.

Every policy that holds a choice has a Decider, and every action has an Actor. Both are pluggable: code, an agent, or the human. A decider can also be a mix: the agent decides above a confidence threshold the human sets, else the human does.

Every policy starts with the human as the decider. Over time, they can be handed off to an agent or codified as code. Irreversible decisions, like cutting a release, stay with the human.

All the decisions that need the human land in a single queue: the Decision Node. So do the actions only the human can take.

The idea is that humans will sit at the Decision Node throughout their entire work time, making decisions and taking actions.

Every decision should come with a Premove (an agent that predicts and prefills your call) based on Precedent (your calls on prior similar situations). As trust is earned, the decider can be switched to the agent making the premoves.

What about the actions?

People emphasize actions (like merging a PR), but once the necessary decisions are made, actions are mostly process to automate. 90% of actions agents can already do; 9% are "meat proxy" actions you wish they could (2FA, sudo, payments, captcha, etc.). The remaining 1% are things you actually want to do (like writing this post :).

What about our beloved agents?

As mentioned, we interact with agents mostly to get to the decisions and actions that need us.

So, agents (harnesses, meta-harnesses, agent orchestration, agent swarms, all that) are the how; the mechanism. They are low-level implementation details. The EDA framework is a layer of abstraction above. Agent swarms may go away tomorrow; the implementation changes, but the framework stays.

I predict that we won't chat with agents anymore except where it's helpful to make a decision.

What's new about all this?

EDA is textbook stuff, but my angle here is optimizing for eDPM. Some ideas:

1. Optimizing for Ease of Decision with flexible Decision Packets

Take the example of merging a PR.

• Bad: you go to GitHub, look at the PR, decide, and message your agent to ask it to merge it.
• Good: your agents bring the PR to your loop engineering app and prepare a decision packet for you.
• Better: your agents also predict your decision and nitpicks; you just press enter.
• Token-maxxing: your agents preemptively build the PR in a worktree and show you a decision packet with before/after screenshots and videos, as well as takeaways from the implementation; an independent agent predicts your call.

The idea of decision packet is central. Every decision brought to you must be optimized for ease of choice, and the decision packet format must be very flexible to let the agent optimize for that. It could contain

• a smart diff,
• screenshots with red frames around the important part,
• a working demo,
• a forecast,
• a chart,
• etc.

Every decision packet comes with an adversarial recommendation, confidence score, copy edit suggestions to match your voice, etc. Picture a mama bird chewing the food for her baby.

One pattern: the decision packet offers a few alternatives. If one is what you want, you pick it. If not, you pick the closest one, and the packet comes back with a few variations of it. You keep narrowing down until you get what you want, without typing anything.

Of course none of this is hard-coded; you constantly vibe-refine every aspect of the system.

2. The black hole effect

You might start with a single workflow, like pushing PRs for one project.

But you don't want to manage a loop app per project, so you add all your projects as inputs (Events) to your Decision Node.¹ Then you realize: why am I making decisions anywhere else, if this has the best eDPM? So it progressively eats every event source in your life. Your email. Your bills. Your online shopping. Your group chats. Your whole life falls into the Decision Node, like a black hole gobbling everything up.

3. The single Decision Node architecture

Most people doing loop engineering have various human gates along the SDLC. Maybe there's triage at the top and sign-off at the end.

There's no point for you the human to be jumping between different queues. It's all decisions at the end of the day. Bring them all to a single queue (with flexible decision packets), so that the system can scale to unlimited events and actions.

What are the problems with this framework?

There are some quirks I'm still trying to work out:

1. Decision fatigue. We don't enjoy doing a single thing all day; and by removing all the mechanical work, we left only the part where we need to pay attention.
2. The human's role feels reductive. It's like Bryan Johnson eating whatever the Health Algorithm says. Agents feel empowering, but somehow eDPM flips that and makes you feel like a metric.

What's the end game?

eDPM is still short-term thinking. The end game is turning the Decision Node into the Anti Feed. A feed is designed to scroll endlessly. We want the opposite.

I predict a shift toward:

• integrating more events (so all your decisions are routed to the Decision Node)
• predicting decisions better (RL on your past decisions)
• automating more actions (browser use, computer use)

Once everything is integrated into the Decision Node, all decisions are predicted correctly, and all actions are automated, labor ends for good.

Footnotes

1. In practice, each project gets its own Premove agent, so no single agent needs context about every project. ↩︎