Agents that finish the job

A demo impresses. An agent that finishes the job earns its keep.

The difference is ownership of the outcome, not the cleverness of the prompt.

Everyone has seen the demo by now. A model takes an instruction, does something that looks like magic, and the room nods. Then the demo ends, the human takes back the keyboard, and the real work — the follow-through, the retries, the edge cases, the bit where something goes wrong at 2am — stays exactly where it always was. On a person.

A demo is a performance. An agent is a colleague. The gap between them isn't a better model or a more elaborate prompt. It's whether the thing actually owns the outcome, or just produces a convincing first step and hands the hard part back to you.

We learned this the slow way, building Superfan and then the agents running underneath Orolo. The clever bit was never the problem. Getting something to finish — reliably, unattended, and honest about what it did — was the whole job.

Three rules

• Give it a goal, not a task
• Let it retry
• Make it report what it did

Those three lines are the difference between a demo and a worker. Here's what each one means once you stop nodding and start building.

Give it a goal, not a task

A task is "fetch the latest sold prices for this reference." A goal is "keep this reference's price band accurate." The first is a single instruction that succeeds or fails once. The second is a standing responsibility the agent has to keep meeting as the world changes underneath it.

Task-shaped agents are brittle because the real world rarely matches the instruction. The listing format changes. A source goes down. A reference gets discontinued. A task-shaped agent hits the unexpected and stops, because finishing the instruction was the whole of its job. A goal-shaped agent hits the same wall and looks for another way over it, because the instruction was never the point — the outcome was.

This is also what makes a goal-shaped agent feel like it owns something. You're not handing it a step in your process. You're handing it the result you actually care about and letting it figure out the steps. That's a transfer of responsibility, and responsibility is what turns a tool into a teammate.

Let it retry

The single biggest jump from demo to dependable is permission to fail and try again. Demos are built to succeed once, on a clean path, in front of an audience. Production is nothing but unclean paths — the timeout, the rate limit, the malformed response, the source that's fine 95% of the time and garbage the other 5%.

An agent that can't retry treats every one of those as a dead end. An agent that can retry treats them as weather. It backs off, tries a different source, waits and comes back, escalates only when it has genuinely exhausted its options. Most failures in the real world are transient, and a system that simply tries again a moment later quietly handles a startling share of the things that would otherwise page a human.

The discipline here is bounding it. Retry forever and you've built an expensive infinite loop. The rule we use: retry with backoff, cap the attempts, and when the cap is hit, fail loudly to a person rather than silently to nobody. Which brings us to the last rule.

Make it report what it did

An agent you can't see is an agent you can't trust, no matter how good it is. The thing that lets you actually leave one running overnight isn't faith — it's the log it leaves behind. What did it do, what did it skip, what did it retry, where did it give up and why.

This matters for two reasons. The obvious one is debugging: when something goes wrong, the report is the difference between a five-minute fix and an afternoon of guessing. The deeper one is trust. You extend an agent more responsibility in exact proportion to how clearly it tells you what it's been doing with the responsibility it already has. A silent agent stays on a short leash forever. A transparent one earns more rope every week.

Our agents end every run with a short note in plain language: here's what I refreshed, here's what looked off, here's the one thing I think you should look at. We read it over coffee. Most mornings, the answer is "nothing" — and that's the point. The reporting is what makes "nothing" believable.

The shift that matters

Put the three together and something changes in how the work feels. You stop operating the tool and start managing the outcome. You're not pulling levers; you're reviewing a colleague's night shift and deciding what to do with the hours it gave you back.

That's the move from a clever demo to something that runs while you sleep. Not a smarter model. A thing with a goal it owns, the room to fail its way to success, and the honesty to tell you exactly how it got there.

Build for the finish, not the flourish.