JustSwipe: the agent should earn the interruption

An agent that asks me to read everything it did has handed me another job.

More parallel work can still leave me as the bottleneck: reconstructing updates, finding the decision and repeating a correction. That’s the problem behind JustSwipe, the private decision inbox I’m building.

The agent should earn the interruption.

Do the work before asking me to manage it

A useful decision explains what changed, why it matters now, the options and what happens if I do nothing.

Who does the preparation?

1. 01

   An update can hand me another job.

   The facts are scattered across working notes. I have to reconstruct what changed and whether it needs me.

   Dependency slippedDemo tomorrowAttendees affectedAn alternative date?

   ↓Someone must reconstruct the choice

   An update“The project is delayed.”

   What changed? What do I need to do?

2. 02

   Prepare the choice first.

   Check the context, alternatives and consequences before asking for attention.

   Dependency slippedDemo tomorrowAttendees affectedAn alternative date?

   ↓Check context · compare options

   A prepared decisionMove the demonstration?

   The missing dependency affects the demo. Moving it gives time to recover, but changes attendees’ plans.

   What happens if we keep the date?

3. 03

   Earn the interruption.

   Bring a decision I can understand and question. If the agreed work can be finished and checked, finish it.

   Dependency slippedDemo tomorrowAttendees affectedAn alternative date?

   ↓Bring only the decision that needs me

   A prepared decisionMove the demonstration?

   The missing dependency affects the demo. Moving it gives time to recover, but changes attendees’ plans.

   What happens if we keep the date?

Illustrative preparation sequence, not a live appointment or evidence of time saved.

Imagine tomorrow’s demonstration depends on something that has slipped. “The project is delayed” leaves me to find the choice. The agent should prepare the alternatives and consequences first.

That still leaves a decision for me. It removes the need to excavate it from a conversation.

The useful output is a decision you can understand and question, with the preparation already done.

AI-generated conceptual model, not a live appointment or a control. Choosing a plan does not send a message to attendees.

OpenClaw keeps the work moving; JustSwipe brings me the choice

OpenClaw provides an agent gateway. In my setup it is the continuing operator, while JustSwipe brings me the decisions. The private organisation around them is my own system.

The work inbox, server task scout and route for surfacing decisions have implementation behind them. One August server run stayed silent because a proposal was already waiting. Adding another proposal before I deal with the first would not solve the attention problem.

That narrow result does not prove time saved, reliable arrival of every proposal or an advantage over a plain list.

A swipe can be dangerously easy

Making a choice effortless can make it thoughtless. The system has already chosen the issue, framed the options and left out facts before I touch the card.

Illustrative decision inbox

Move the demonstration?

The dependency has slipped. Moving the demo may give time to repair it; keeping the date may preserve attendees’ plans.

Inspect the recommendation

First check whether a smaller demonstration would still serve its purpose. The answer could change if the dependency arrives or attendees accept a narrower scope. The proposed date and effect on attendees also need checking. This example has no live appointment.

Question the factsDecide laterNone of these

Try a response to see where the work should go next.

Reset example

Local demonstration only. No choice sends a message, changes an appointment or authorises an external action.

A useful correction must change the recommendation. Suppose the late dependency is needed for the full product, but tomorrow’s demo only needs a feature that already works. Asking me again to postpone would preserve the original mistake.

The agent should retain the corrected purpose, check whether it still holds and avoid raising the same false alarm. The simple interaction belongs at the end of that preparation.

Choosing a plan is not permission to send invitations. A real send needs agreement on the recipients, wording and exact action.

Prediction only matters if it changes the timing

I want to connect this to useful personal forecasts, so alternatives are ready while there is still room to act.

Before the problem

1. Forecast
2. Prepare alternatives
   Room to act
3. Decision
4. Outcome

After the problem

1. Outcome
2. “Prediction”

That is an explanation of something already known.

Conceptual sequence, not measured lead time. The joined forecast-to-decision loop remains a development goal.

The joined loop remains a development goal. Accuracy alone would not show that a forecast changed a useful decision.

This is the practical side of my scarcity argument: more machine activity can make attention more expensive. If I end up swiping through endless low-value questions, the interface has failed.

Sources and further discussion

• Anthropic: Trustworthy agents in practice (April 2026). This engineering discussion considers when agents should proceed, expose uncertainty or ask for clarification. It helps frame the attention trade-off, but it is a vendor’s design perspective, not independent evidence that JustSwipe reduces decision burden.