Showing progress as plain steps instead of jargon

TL;DR:

• A good assistant tells you what it is doing in the words you would use, not in the names of its internal tools.

• Every step should say what it is about to touch, and the end should be an unmistakable done signal.

• Plain steps are also your control surface: they let you catch a wrong turn before anything is sent or paid.

Say you ask an assistant to book a study room at your library for Thursday afternoon. A few seconds later it reports: "navigate(url), find_element(selector=#date), click(node_47), type(field_3), submit(form)". Did it book the right room? You cannot tell, and neither can anyone who did not write the software.

Now imagine the same job reported as: "Opened the library booking page. Picked Thursday. Chose Room 3, 2 to 4 pm. Ready to confirm: need your OK." Same work, but now you can follow it, check it and stop it. This article is about why that second style is the right one and what it needs to include.

The short answer

An assistant that operates software for you is really a loop. It looks at what is on the screen, decides on one small action, does it, then looks again. Inside the software each action has a technical name, such as a click, a keystroke or a page load. Those names are useful for programmers and meaningless to everyone else.

Showing progress "as plain steps" means translating each action into what it means for you: what it is looking at, what it is choosing, and why. The technical record can still exist for debugging, but it should not be the thing you are asked to read.

What happens step by step

Under the hood, a job like this tends to follow the same pattern every time, whatever the task is.

1. Understand the goal. It restates what you asked, including the details it will need: day, time, place, who it is for.

2. Look. It reads what is on screen, such as a page, a window or a form.

3. Choose one action. Click a date, fill a box, press a button.

4. Check the result. Did the page change the way it should have? If not, it tries something else or tells you.

5. Repeat until finished, or until it reaches a point that needs you. Anything that sends a message, spends money or changes something hard to undo should wait for your approval.

The plain-step report is just a running caption on this loop. Each line should be one sentence, in the past tense for what is done and the present tense for what is happening now, so you always know where in the job you are.

Walk-through: an agent's step list for a booking

Here is a hypothetical request: "Book a study room at the library on Thursday between 2 and 4 pm for me and two friends." First the jargon version, then the plain version of the same run.

tool_call: open_page(url="library.example/rooms")
tool_call: find(role="combobox", name="date")
tool_call: click(id=312)
tool_call: type(id=318, text="3")
tool_call: click(id=330)
status: 200 OK

Notice what changed. Every line is something you could check by looking at the same page. The line that explains a choice ("only Room 3 fits three people") lets you spot a mistake, for example if you actually wanted a bigger room. And the stop point comes before the booking, not after.

Done signals you can trust

The hardest line to write is the last one. "Finished" is not a done signal unless it points to evidence. Good done signals are things you can see: a confirmation message, a new item in a list, a file that now exists. A weak one is "I clicked submit", because clicking is not the same as succeeding. The page may have shown an error.

• Say what changed. "Room 3 now shows as booked in your name" beats "Done".

• Say what did not happen. If the confirmation email has not arrived yet, say so.

• Make it visible. A clear end state, such as a color change or a short sound, tells you the work is over even if you glanced away.

One example from DuckyHelper, in early access: when the orb is working in a window for you, a ring on the edge of your screen turns green at the end. That is the whole done signal, and you can notice it without reading anything. It's also built to ask before sending a message or paying for anything.

What it can't do

Plain steps are a summary, and a summary can be wrong. An assistant can describe a step as "chose the right room" when it picked the wrong one. The words are only as good as the checking behind them, so it is worth glancing at the actual screen for anything important.

• It cannot make a risky action safe just by describing it nicely. The approval point has to be a real stop.

• It cannot know what you meant if you were vague. "Thursday afternoon" might be 12 to 5.

• It may hit a page that behaves differently from last time, and a good report says "this looks different than expected" instead of pushing on.

Privacy and control

A step list is also a privacy tool. If the report says "opened your email", you know it saw your email. If it says only "opened the booking page", the scope of the job was smaller. Read the steps for what they reveal about what the assistant could see.

Two rules are worth insisting on. First, anything that sends something or spends money should pause for you. Second, passwords and card numbers should be typed by you, not by the assistant. You should be able to stop the job at any line, and the steps should make it obvious where you would do that.

Try it yourself

Next time you use any assistant that acts on your behalf, read its progress as if you were a new coworker watching over a shoulder. Can you tell what it is touching? Is there a stop before anything irreversible? Is the last line backed by something you can see? If the answer to any of these is no, treat the result as unchecked.

If you want to see an AI that looks at your screen and talks you through it, DuckyHelper lets you try it for 10 minutes with no card. For how an assistant takes over a window, see handing a window to an assistant to finish a job.

Frequently asked questions

Why not just show me everything it does?

A full technical log is accurate but unreadable. Plain steps keep the meaning and drop the noise, and the detailed record can stay available for someone who needs to debug.

Can I trust a done message?

Trust it as much as the evidence it points to. A confirmation you can see on screen is worth more than a bare "done".

What if I do not understand a step?

That is a flaw in the report, not in you. Ask the assistant to say it again in plainer words, and do not approve anything you cannot explain.