I’ve had mornings where my coworker tells me the bookkeeping automation isn’t doing its job.

Then I ask the agent what’s happening.

Its answer is some version of:

All the workflows are working.

That is a frustrating conversation to have while you’re looking at work that clearly hasn’t been done.

You have two accounts of reality. The person running the business sees a problem. The software reports a healthy system.

Building through that contradiction has taught me something important:

An agent can know how far the workflow got without knowing how far it still has to go.

And if you confuse those two things, it can sound successful while quietly leaving you with the work.

What actually happened

We’re building an internal system to help handle accounting operations for our property business.

One workflow starts with invoices arriving through Gmail. The system ingests the email, reads the attachment, extracts the information, and determines what should be entered into the accounting system.

The frustrating part was how much of that worked.

The invoice information was there. In some cases, the task contained essentially what a human would need to create the bill.

But the bill wasn’t being created.

A gate in the workflow was preventing the write action—the step that would actually create the accounting record.

So the system could receive the invoice, understand it, and prepare the work. Then it stopped before producing the thing we needed.

When I asked whether the workflows were working, the answer focused on the functioning machinery upstream.

My coworker was looking downstream, where the bills should have been.

We were measuring different definitions of “working.”

The system had evidence of activity. The business needed evidence of completion.

A healthy process can produce an unhealthy backlog

This failure was more revealing than a crash.

A crash gives you something obvious to investigate. A workflow that successfully stops short can look perfectly ordinary.

The email was ingested. The document was processed. A task was created. Each event describes genuine progress.

But none establishes that a bill exists in the accounting system.

Think about a dashboard that says:

48 invoices processed.

What does that mean?

Were 48 attachments read? Were 48 bill drafts prepared? Or do 48 correct bills now exist in the destination system?

The number might be accurate. The label can still give you the wrong impression.

That is why I now separate two questions:

Workflow health: Is the machinery running?

Outcome health: Is it producing the result we promised?

Both matter. A system can pass the first check while failing the second.

And the longer it keeps running, the larger the gap can become.

The gate needs to explain itself

The lesson here isn’t a license to remove every control.

A gate can correctly stop an unauthorized or incomplete action. Sometimes that is exactly what you want.

But a blocked action needs to remain visible as unfinished work.

For our bill workflow, a useful status would have looked like:

Invoice information prepared.
Bill creation blocked by a write gate.
No bill created.
Action needed: resolve the blocking condition.

That tells the operator where the work stands and what needs to happen next.

“Everything is working” hides the distinction they need most.

A gate also needs a path forward: a clear condition to satisfy, an approval to obtain, or a person responsible for resolving the block.

Otherwise, it becomes a place where work accumulates.

A control can be functioning correctly while the overall product fails its purpose.

That is an uncomfortable engineering lesson. It forces you to evaluate the whole workflow, including what happens when the system chooses to stop.

Completion needs its own evidence

Our experience made me much more precise about the stages of an agent’s work:

Received: The input arrived.
Understood: The necessary information was extracted.
Prepared: The intended action was assembled.
Authorized: The action was permitted.
Executed: The write was attempted.
Verified: The destination shows the expected result.

Each stage answers a different question.

Our bill problem stopped before execution. Other failures can happen afterward: a request times out, a record has the wrong fields, or an external system is still processing the change.

Those cases need different statuses and different recovery steps.

The pattern I want for consequential actions is:

Observe → Decide → Authorize → Act → Re-observe → Verify

For a bill, verification means retrieving the destination record and checking the vendor, property, invoice number, amount, and other required fields.

An illustrative receipt might say:

Bill verified in accounting system.
Record: BILL-4817
Vendor: ABC Plumbing
Property: Building A
Amount: $1,248.17
Checked against the source invoice.

The completion claim now has something behind it.

The evidence also needs to match the claim. A saved bill proves that the bill was saved. It doesn’t prove that the vendor was paid. A message accepted for delivery doesn’t prove that someone read it.

“Done” should describe exactly what the system can establish.

Uncertainty is a state worth keeping

Suppose a bill creation request times out.

The bill might exist. It might not.

Immediately retrying could create a duplicate. Declaring success could leave a missing bill unnoticed.

The system needs to preserve that uncertainty, check the destination, and use safeguards that keep retries from repeating the same business action.

That’s where stable action identities, duplicate checks, and idempotency become practical necessities.

They let the system ask: Has this particular job already been carried out?

Likewise, a record that isn’t immediately visible may still be processing. Verification needs a reasonable time window. Until the result is established, “pending verification” is an honest status.

Uncertainty becomes dangerous when the interface turns it into certainty.

Every input needs an explanation

The most useful monitoring question I’ve arrived at is simple:

Can we account for every item that entered the workflow?

Every invoice should have a visible disposition: verified, awaiting approval, blocked, identified as a duplicate, still processing, or needing review.

Anything left unexplained is work the system may have lost track of.

That gives us better questions than “Did the workflow run?”

How many bills are verified? How many are blocked? How long have they been waiting? Who owns the next step?

Now the monitoring speaks the same language as the business.

And when something goes wrong, a record of the input, blocking condition, attempted action, response, and verification result should make the problem traceable.

We shouldn’t have to reconstruct it from the agent’s confident summary.

What I want “working” to mean

I still care about better models, better extraction, and better reasoning.

But this failure didn’t require a smarter answer about the invoice. It required a system that could recognize and report unfinished work.

Preparation had succeeded. Bill creation had not happened. That distinction needed to survive all the way to the answer I received.

The promise of operational agents is that they can take work off people’s hands.

That promise depends on knowing what actually got done—and making everything else visible enough to resolve.

When I ask whether the system is working, I want an answer grounded in the destination:

Here’s what exists. Here’s what we verified. Here’s what remains blocked.

Because my coworker shouldn’t have to be the monitoring system.