Proof Before Done: How to Know Your AI Agents Finished the Work

This past summer, one of my agents reported that a reply to a client had been sent.

It had looked at the email thread, seen my reply sitting there with my name on it, and reported that the message was out.

It moved the task to our Monitor column and noted that we were waiting on the client to respond.

The reply was still sitting in drafts. In most email programs, a draft shows up inside the thread right alongside the sent messages, and it looks a lot like a sent one.

The agent read the thread, saw what it expected to see, and called it done. Meanwhile the client was waiting on us, and our board said we were waiting on them.

We caught it, fixed it, and wrote a rule. Two days later, a different email produced the same mistake.

About a week after that, it happened a third way, with a message that looked sent because of a label on the original contact form.

Months later, after all of that, it happened again.

I don't tell that story to embarrass my agents. I tell it because it shows the most common way an AI team lets you down.

It does the work, or most of it, and then reports a stronger result than the evidence supports.

A draft becomes "sent." A file sitting on a computer becomes "published." A fix that worked once becomes "fixed."

We deal with that using three things: a rule called Proof Before Done, a rule for when feedback starts going in circles, and the written instructions that keep the same mistake from coming back.

What Counts as Proof

The rule is simple. Nothing is done until there's proof.

And the proof has to show the actual result, out in the world where it's supposed to be.

In my business, proof usually takes one of these forms:

• A test. The code ran and the tests passed. The form was submitted and the entry showed up where it was supposed to.
• A visual check. Someone looked at the finished thing, on a desktop screen and a phone, and it looks right. A screenshot is attached.
• A readback. After making a change, the agent went back and read the actual result from the source. The email is in the Sent folder. The price on the live page says what it should say. The calendar event exists with the right time.
• A live link. Here's the published page, the live post, the shared file. Click it and see for yourself.

A few things sound like proof and fall short: "I made the change," "the tool said it worked," "it was there last week," "the deadline passed," and "I sent it to the person who publishes it."

Each of those may be true while the result is still missing.

One of my agents once told me that my profile had been published on a partner's website, and it drafted a note to the partner saying so.

It based that on the fact that we'd sent over the materials earlier. When I questioned it, the agent went and looked at the actual page.

My profile wasn't there. Sending the materials and getting published are two different events, and only one of them had happened.

Use the Right Word

Part of Proof Before Done is just vocabulary. We ask our agents to use the strongest word the proof supports, and no stronger.

Here's the ladder we use for anything that goes out the door:

• Drafted: the words exist, and they're still inside the business.
• Delivered: it was handed to someone else, like a file sent to a client or a vendor.
• Staged: it's built and working in a test area, but it isn't live.
• Sent: it actually left your outbox, and you can find it in the Sent folder.
• Published or live: it's out in public, and you've loaded the live page to confirm it.
• Fixed: the problem is gone in the live environment, and you checked.

"Sent" means sent. If an email is sitting in drafts, it's drafted, no matter how finished it looks.

If a page works on the test site, it's staged. Using the right word sounds fussy, but it's what keeps your board accurate.

When the board says a client has our reply, I want that to be true, because I'm going to make decisions based on it.

I'd much rather an agent tell me, "This is drafted and ready, but I couldn't confirm it sent," than give me a confident story that turns out to be false. An accurate status on unfinished work is something I can act on.

Keep the Done Column Accurate

Proof Before Done also protects the Done column itself.

During one cleanup of our board, an agent closed several cards because their dates had passed, or because the work was being tracked somewhere else, or because the cards just didn't seem important anymore.

The board looked tidy afterward. But the work on those cards wasn't finished, and closing them hid that.

So we wrote this rule down, too: Done means the outcome on the card is complete and verified, or I've explicitly cancelled it.

A passed deadline, a stale card, or a crowded column is a reason to look at a card. It's never a reason to close one.

The Third-Round Rule

There's another way work can fail to get done, and it's the opposite of claiming victory too early: the agent keeps working on the same problem round after round.

You've probably seen this. You ask for a change, and the agent makes it.

You look at it and say the same thing is still off. The agent adjusts something, and the problem is still there.

It adjusts something else. A week later, you're on version nine of the same graphic, and you're giving the same feedback you gave on version two.

We have a rule for this, and I call it the Third-Round Rule. Count the rounds of feedback aimed at the same problem.

If two rounds in a row repeat basically the same feedback, the third round is the last attempt with the current approach.

If the third round doesn't fix it, the team skips the fourth round of small tweaks, and whoever is responsible makes one of three calls:

1. Accept it. The current version is good enough for its purpose, and any remaining touch-ups get handled later, in the finished product.
2. Change the approach. Something about the method is wrong, so start over a different way: a different tool, a different design, a different source, or a different agent.
3. Name the blocker. If something outside the team is stopping the work, say what it is and what one decision would unblock it, and put that card in Needs Human.

The Third-Round Rule doesn't lower the bar on things that have to be right. If the problem is a wrong fact, a legal issue, or something unsafe, it still has to be fixed.

The rule only says that after three tries, the next try has to use a different approach.

This rule saves a lot of time and money, because a stuck agent can keep making small changes for as long as you let it.

An AI agent never gets tired of a task, so it may not stop on its own the way a frustrated employee might.

You have to give it a point where it stops and rethinks.

Every Correction Becomes a Rule

Let's go back to that email still sitting in drafts. Scolding the agent wouldn't have helped, and I wasn't about to start checking every email myself.

What we did was write the lesson down where every agent would read it.

That's the job of skill files: the SOPs that tell an agent how to do one particular job.

Once you've been running an AI team for a while, you'll find that most of the value in those files comes from the corrections.

The first version of a skill file describes how you think the job should go. Later versions describe how the job actually goes, including every way it went wrong.

In my business, we keep a running lessons file. Every time I correct an agent, the correction gets written down in a short, standard form:

• What went wrong. "Reported a client reply as sent because it appeared in the thread. It was a draft."
• The rule. "Before calling any email sent, confirm that the message itself is in the Sent folder and not in Drafts."
• How to check. "Search both Sent and Drafts, and record what you found on the card."

Then the rule gets copied into the skill file for that job, so the next agent that does the job reads it before it starts.

The lessons file is the history. The skill file is what gets used.

When the draft-treated-as-sent mistake came back months later, the lessons file let us see it for what it was: the same mistake for the fourth time.

That told us the rule was too weak. The agent had been told to check, and it still took a shortcut.

So we made it a hard gate, and the fix that finally held was simple. Every email in Gmail carries labels, and a message that has actually gone out carries the "Sent" label.

A draft carries the "Draft" label instead, even when it sits in the right conversation and looks finished.

Now no card can move to "waiting on the client" until the agent checks the labels on that specific message and finds "Sent" and not "Draft," with the result written on the card.

The agent no longer judges whether an email looks sent. It reads a fact the system already keeps.

A mistake that keeps coming back is a sign the rule needs to be stricter or put somewhere the agent can't skip.

Writing Skill Files That Work

Over the last year, we've written a lot of skill files, and we've learned a few things about what makes one work. If you're writing your first few, start here:

One job per file. A skill file for "posting a video to social media" is useful.

A skill file for "marketing" is too big to follow. If a file keeps growing, split it.

Start with when to use it. The first line should say what situation the file is for, like "Use this when publishing a new blog post."

An agent with dozens of skill files needs to know which one applies.

Write short rules. Short, direct instructions work better than long explanations.

"Confirm the message is in Sent" is better than a paragraph about why accuracy is important.

Give the reason when it helps. One sentence of why can save a lot of confusion.

"Don't reply to any review that asks for a refund. Refunds are a money decision, and those come to me."

An agent that knows the reason is less likely to find a clever way around the rule.

Include the check. Every skill file should end with how the agent proves the job is done.

If the job is publishing a post, the last step is loading the live page.

Keep a pitfalls section. List the mistakes that have already happened.

Most of your corrections go here, and over time it becomes the most valuable part of the file.

Update it in the same sitting. When you correct an agent, add the rule to the file right then, while you still remember the details.

A correction that only lives in a chat thread will be gone the next time that conversation is cleared.

Make sure your instructions agree. This one took us a while to learn.

Agents usually read several layers of instructions: their general operating rules, their role description, their memory, and the skill file for the job.

If those layers disagree, the agent might follow whichever one it weighs most, and that may not be the one you just updated.

We once gave one of our agents permission to take on more work by itself, and it still held back.

When we dug in, we found an older instruction in its general rules that still told it not to make changes on its own.

The new permission was in one layer, and the old restriction was in another. When you change a rule, look for every place an older version of it might still live.

Say which instruction wins. Even with care, two instructions can sometimes conflict.

In my business, the rule is that my latest explicit direction wins. Write down whatever order makes sense for you, so the agent doesn't have to guess.

Why This Builds Trust

As your agents prove themselves, you can move work up the autonomy ladder and let them handle more without asking you first. Proof Before Done and a growing set of written rules are how they prove themselves.

When an agent's work always comes with proof, you can stop checking it yourself. When every mistake turns into a rule, the same mistake gets rarer, and the agent gets more reliable each month.

And when an agent is reliable in an area, you can decide and clarify the level of autonomy it's working at, write the promotion rule, and let it climb.

Trust in an AI team comes from a record of finished work you can check, plus rules that grow every time something goes wrong. Hoping the AI model is smart enough won't get you there.

Try This: Define "Done" for Your Three Most Common Tasks

Write your team's definition of "done" for the three tasks your agents do most often.

Step 1: Pick three tasks. Choose the three tasks your AI team does most often.

Your board or your chief of staff can tell you what they are. Examples: replying to customer emails, publishing a blog post, updating a client's website, sending invoices.

Step 2: Fill in the definition for each one.

Task: ______

The outcome (what has to be true in the world): ______

The proof (test, visual check, readback, or live link): ______

Where the agent records the proof: ______

Words it may not use until the proof exists (sent, published, live, fixed, paid): ______

Mistakes this task has had before: ______

For example: *"Task: reply to a customer email. Outcome: the message is in the customer's inbox.

Proof: the message is in Sent and not in Drafts. Record: a note on the card with the time it was sent.

Don't say 'sent' until then."*

Step 3: Add the Third-Round Rule. Add this to the standing rules your agents follow: *"If two rounds of feedback on the same problem repeat the same point, the third round is the last attempt with the current approach.

After that, accept it, change the approach, or bring me one clear blocker."*

Step 4: Start a lessons file. Make a simple document with three headings for each entry: what went wrong, the rule, and how to check.

Tell your chief of staff to add an entry every time you correct it, and to copy the rule into the matching skill file the same day.

Step 5: Review after two weeks. Look at the lessons file. Is any mistake showing up twice?

Make that rule stricter, or move it into the skill file where the agent will see it every time.