The Decision Feed

The Decision Feed is a system that maximizes for what I call eDPM: effective Decisions Per Minute.¹

Think about what you are really doing when you talk to agents: digging through walls of text to fish out the 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.

The system is a feed of Decision/Action Packets aggregated across all your agent workflows.²

eDPM

Some people track how productive their agentic workflow is by counting PRs. But you know Goodhart's law: "when a measure becomes a target, it ceases to be a good measure".

Agents always find something to polish: feature PRs generate clean-up PRs, and even clean-up PRs generate clean-up PRs.

That's why I propose the eDPM metric.

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. Not PRs or tokens used.

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 (Software Development Life Cycle) 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 Feed. So do the actions only the human can take.

The idea is that humans will sit at the Decision Feed 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). Track how often the Premove is right: as trust is earned, the decider can be switched to the agent making the premoves.

What about 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 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.

Chatting with an agent is still the best way to start things: an idea, a task, a new workflow. But once things are running, what you need from agents is mostly decisions and actions, and those don't need a chat.

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 Feed.⁴ 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 Feed, like a black hole gobbling everything up.

3. The single Decision Feed architecture

Most people doing loop engineering have various human gates along the SDLC (maybe triage at the top and sign-off at the end), or different workflows per project.

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.

Isomux Implementation

I first built a loop engineering app specific to Isomux development (GitHub). Then, I built a separate generic Decision Feed app (GitHub), based on this write-up.

But then I realized that the Isomux Inbox feature is a better fit (for someone who already spends all day in Isomux).

In Isomux, when an agent needs you, it opens an ask: a card in your Inbox with the question, the options, and a reply box. Asks from every agent, in every room, land in the same Inbox, and they stay there until you answer.

The Inbox can be turned into the Decision (and Action) Feed.

Each ask carries a decision packet:

• agent-provided options, with the agent's pick marked,
• images and videos,
• red/green diffs,
• filters and sorts by room, priority, and age,
• a Simplify button for when an ask is unclear,
• an Undo before my answer is sent.

Apps can open asks too.

Project crews

A coding project can join as an agent crew, effectively absorbing loop engineering into the Decision Feed:⁵

• PM: my point of contact, with the final say on process. If I bring an idea to the PM, it files it as a task. A small app watches the task board and wakes the Curator agent when there are new tasks.
• Comms: collects tasks from every outside channel: GitHub issues and PRs, the Discord server, the landing-page chatbot, and the support inbox. A webhook wakes it for each new item. It adds the item to an open task on the same topic (without personal data), or files a new task. It never replies to anyone outside.
• Curator: opens one triage ask per new task.
• Consult: the Premove. It predicts my call from my past answers. The Curator asks it for the prediction before creating the ask.
• Worker and reviewer pairs: they implement the triaged tasks, in a worktree. Can be multiple pairs at once.
• Sign-off Scout: opens one Approve or Revert ask per merged task.
• Main: the only agent that writes to main. It brings pushes as asks.

For example, here's the crew for Isomux itself. I have an equivalent one for wallgame.io.

The crew agents auto-handoff their context at around 350k tokens used, so their context is made of past calls. After a handoff, they can pull past decisions from their own conversation history.⁶

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.⁷ 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 of the Decision Feed is 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 Feed)
• predicting decisions better (RL on your past decisions)
• automating more actions (browser use, computer use)

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

Footnotes

1. The term is based on eAPM (effective Actions Per Minute) in competitive videogames like StarCraft. eAPM counts only the actions that do something, not spam clicks. ↩︎

2. I got here after experimenting with loop engineering. ↩︎

3. This principle started as slide mode, a failed experiment from a few months ago. The premise was that agents yap too much and users tune out, so slide mode forced the agent to design a single slide for each turn. It didn't work because it added delay to each turn, but the Inbox is asynchronous, so it's not an issue. ↩︎

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

5. As of Oct 31, Isomux and Wall Game run this way. ↩︎

6. Isomux logs every ask, so past calls can be analyzed for accuracy. ↩︎

7. It's like Bryan Johnson eating whatever the Health Algorithm says. ↩︎