← FIELD NOTESSeptember 24, 2026 · 5 min

A task isn't finished when it leaves your hands

The same request stalled with a person and with an agent in the same week, for the same reason. What that taught me about writing end states instead of tasks.

Last week someone on the team emailed me asking for proof of employment. One email, completely routine.

I read it and passed it to someone in admin, because I wanted it done and I wanted someone holding it. That's a small decision I make thirty times a week without thinking about it, and it's the decision I want to talk about, because what happened next taught me more about AI agents than anything I've read this year.

Nothing came back. So I passed the same request to Nino, which is one of our agents, the one that handles contracts and admin documents.

Nino came back quickly: "I created a task for admin."

I hadn't asked for a task. I'd asked for a certificate. But notice that Nino wasn't wrong, exactly. It had done something, it had moved the request toward a person who could act on it, and it reported back honestly. If you squint, that's a completed job.

I pushed. Second attempt, Nino sent the document through PandaDoc to the person who had to sign it. Better. Still not the thing. A document waiting for a signature is not a document in someone's inbox, and the person who asked still had nothing.

By the end I'd routed the same request three times, and the only reason it closed is that I was still carrying it in my head.

Everyone finished their version of the job

Here's the part I keep coming back to. Nobody in that chain refused to work. Each one completed a defensible version of the task, and each one stopped at a different place.

For the first person, done meant the request had been received. For Nino, first try, done meant a task existed. Second try, done meant a document was waiting for a signature. For me, done meant a signed certificate sitting in the inbox of the person who asked.

Four definitions of finished, all reasonable, none of them the same. And the gap between them isn't laziness, it's that nobody ever said which one counted. I certainly didn't. I forwarded an email and assumed the goal came along with it.

It doesn't. Goals don't travel with forwarded emails. What travels is the task, and the task is not the point.

The thing I said, and the thing I meant

I wrote a line in Slack that day, in Albanian, in the middle of a rant: an agent is correct when it finishes your work.

I liked it enough to build on it, and then I realised it's not quite right, because every single one of them finished the work. What I actually meant is narrower and much harder:

A task isn't finished when it leaves your hands. It's finished when the person who asked has what they asked for.

That sentence is the whole thing. It sounds obvious written down. It is not obvious in practice, because almost nothing we build enforces it. Tickets close when someone marks them closed. Handoffs count as progress. Every tool I've used treats "assigned to someone else" as a state of forward motion, and most of the time it is, right up until the moment it isn't and nobody notices for four days.

Pushing works, which is the problem

I got it moving by pushing. That worked, and it should bother me more than it does.

Pressure produces accountability. It tells people there will be a consequence, and things move. What it doesn't produce is anyone actually holding the goal, because the moment the pressure stops, the behaviour goes back to what it was. I can be the person who chases every request until it closes, and for a while I have been, but that's not an operating model, it's just me being the missing piece.

And with an agent, I don't even have that. You can't put pressure on Nino. There's no consequence, nothing at stake, no reason for it to care whether the certificate arrived. All the informal pressure that makes human teams eventually work does not exist.

So for software, "responsible" can't be a quality you hope the agent has. It has to be something written into the job itself.

What that means when you build one

Three things, and I'm saying them as much to myself as to anyone else, because our agents don't all do this yet.

Write the end state, not the task. "Handle this certificate request" is a task. "The person who asked has a signed certificate in their inbox" is an end state. Those produce completely different behaviour, and the second one is the only one you can actually check.

Make handoffs a step, not an ending. If the agent creates a task or sends a document for signature, that's the middle of the job. It should come back to it. An agent that hands off and goes quiet is a relay, and a relay is exactly what I already have too many of.

Come back with proof, or come back stuck. Either the end state is true and here's the evidence, or it isn't and here's precisely where it jammed and who's sitting on it. "I created a task" is neither of those. It's a status update dressed as a result.

The uncomfortable bit

None of this is really about AI.

The same request stalled with a person and with an agent, in the same week, for the same reason: I never said what finished meant. The agent just made it visible faster, and without the politeness that usually hides it. A person who stops halfway gives you a plausible reason and you move on. Nino told me flatly that it had made a task, and I could see immediately that it thought the job was done.

Which is useful, honestly. Agents are a very direct mirror of how clearly you define things. If your definition of done is vague, a human will paper over the vagueness with judgment and you'll never find out. An agent will do exactly what you specified and hand it straight back to you.

I'd been running a system where I was the only one holding end states, and I only saw it because I gave the same job to something that couldn't pretend.

Founders code. Konstrukt engineers.

Thought by Deborah Jace, written with Claude (Anthropic).

KONSTRUKT STUDIO

Want to see this approach running on your repo? Send us access and we'll come back with at least 5 concrete risks within 5 business days.

Book an intro call