How to Get Your AI Agents From Good Enough to Great
AI agents can produce work faster than you can review it. Learn how to define done, require proof, and turn every quality decision into a better next run.
Most of us remember the first time a coding assistant came back with a real task finished and correct. It stopped feeling like a tool. So you opened a second terminal, then a third. You gave it a recurring job. Soon you were handing it anything you could explain in a sentence.
The trouble arrived later, as a pile. Research drafts, briefs, prototypes, and PRs you asked for and now couldn’t close. Closing one meant deciding whether it was actually good, and that cost more attention than making the request. Some of the pile you quietly abandoned. It didn’t fail; you couldn’t justify finding out whether it succeeded.
Everyone calls this the verification bottleneck: agents produce work faster than you can check it. But watch what happens when you do check something. You read the draft, weigh it, accept it or send it back. Then how you decided lives nowhere but your head. A week later, the same kind of work lands and you start again.
The second review costs as much as the first because the first left nothing behind.
The scalable unit is not another agent. It is a recurring workflow with a definition of done and a memory of why.
To improve AI agent work, define five things before the run: the outcome, proof, boundaries, stop conditions, and a human owner. After every review, save why the work was accepted or rejected and apply that lesson to the next run.
The draft that looked done
We learned this while writing the article you’re reading. Its second draft opened with the line “That feeling is a poor instrument. In a 2025 randomized trial…” It was sourced, structured, and on message. Every specialist review passed it. The editor responsible for publishing it didn’t even finish reading it before he rejected it. The workflow was optimized for the rules, not the actual reader’s experience.
Nothing in our rubric caught that.
The rejection could have died in a comment thread. Instead, we overhauled the entire workflow, skill and critics. Later drafts could be judged against that standard without waiting for the editor to rediscover it.
Write the contract down
You don’t need new software to start. Pick one recurring task and define good enough where the work happens.
In Dotta’s Paperclip company, an agent collects new X bookmarks each night. Its contract is simple:
- Outcome: Save every new bookmark in full. If nothing new arrived, say so and stop.
- Proof: Report what was collected, what was checked, any errors, and the cost.
- Boundaries: Collect and verify. Don’t publish or change the company’s shared knowledge.
- Stop conditions: Stop if source data is missing, validation fails, or access expires.
- Owner: The Feed Operator runs the task. Dotta owns the contract and handles exceptions.
When the Feed Operator returned a collection, Dotta did not have to reopen the source and reconstruct the job. The evidence could be checked against the contract. If it passed, the verified material moved to a strategy agent with the boundaries intact.
A contract can get worse as easily as it gets better. If every rejection becomes a rule, it fills with one-off preferences and contradictions.
Some feedback belongs immediately: a factual error, a safety boundary, a false product claim. Some reveal a standard you would hold every future run to. Taste belongs in a third bucket. Record it, look for recurrence, and promote it only when you can name its scope and show that it improves later work. Taste is often where a standard begins. It is not automatically the standard.
Tests and CI already carry old quality decisions into new code. For knowledge work, you have to carry the standards, examples, and rejection reasons forward just as deliberately.
Give learning an owner
A Paperclip community member running several agent companies asked the question directly: how do you carry “the nuggets” from one company into the next without carrying all the context bloat and confusion?
Treat that as an organizational job, not a better prompt. Give an agent a narrow role. It reviews accepted work, rejections, and human feedback, then proposes lessons with links back to the source. A person decides what gets promoted into a versioned company memory. When you start the next company, import the approved memory, not the old company’s entire history.
This is what strong leaders do when they change jobs. They bring judgment earned through experience, not every email, meeting, and mistake that produced it.
Paperclip tasks keep the loop inspectable. The brief, output, revisions, acceptance decision, and rejection reason stay attached to the work. Company artifacts remain available across issues and runs. The learning agent can cite the evidence behind each proposed lesson. The human owner can accept it, narrow it, or leave it behind. Paperclip does not decide what good enough means. It keeps the decision close enough to the work that the organization can learn from it.
Make every review improve the next run
A written contract gets the first run to good enough. What happens after review is what moves the work toward great.
Each acceptance, rejection, and revision should leave behind a better starting point: a sharper contract, a stronger example, or a lesson promoted into company memory. The next run should begin with what the last one taught you.
Before you add more agents, make sure the first workflow gets better every time you review it.