Define AI Agent Work as Verifiable Execution Slices

The wrong way to make work "agent-sized" is to make it small. A tiny task can still be ambiguous, irreversible, or impossible to review. The useful unit is a bounded claim: one outcome, one changed surface, one proof path, and one decision before the next move.

That changes senior engineering work. The leverage is less about issuing more instructions and more about choosing slices whose results reduce uncertainty for the system as a whole.

Small output is not bounded work

One session asked an agent to produce three publishable pieces and return them as strict JSON. The output parsed correctly. That proved the serialization contract and almost nothing about whether the pieces were distinct, rendered correctly, or were worth publishing.

The task looked decomposed because it had three outputs and a schema. It was still carrying several independent claims:

• the evidence supported three separate angles;
• each draft was substantively different;
• the JSON was valid;
• the MDX rendered;
• the public result met the editorial standard.

When one agent run owns all of those claims, a green check at the easiest layer tends to stand in for the rest. Valid JSON becomes "done."

The fix is not to split the task by files or by agent. Split it at the points where a reviewer would make a different decision.

Use a slice contract

I use this compact contract before delegating implementation work:

OUTCOME
One observable claim this slice should make true.
 
SCOPE
The files, resources, records, or routes it may change.
 
NON-GOALS
Attractive adjacent work that must remain untouched.
 
EVIDENCE
The command, query, render, or live check that can prove the outcome.
 
ROLLBACK
How to return to the prior state if the evidence fails.
 
STOP
The condition that returns control to the reviewer.

For the publishing example, the first slice should not have been "generate three posts." It could have been:

OUTCOME
Produce three candidate theses that use disjoint evidence and promise different reader artifacts.
 
SCOPE
The selected redacted session evidence only. No drafting or publishing.
 
EVIDENCE
A comparison table showing thesis, source incident, artifact, and overlap risk.
 
ROLLBACK
Discard candidates without changing stored posts.
 
STOP
Reviewer approves the set or merges overlapping candidates.

Only then does each approved thesis become a drafting slice. Rendering and editorial review remain separate decisions because they fail for different reasons.

Sequence slices by information gain

The best next slice is not always the most visible feature. It is often the cheapest action that invalidates a risky assumption.

Suppose an agent is asked to change an authenticated workflow across a frontend, API, and deployment. A weak plan mirrors the architecture:

1. Change frontend.
2. Change API.
3. Deploy.
4. Test.

A stronger plan follows the uncertainty:

1. Reproduce the current auth decision with one request and capture the response.
2. Identify which layer owns the incorrect decision.
3. Patch only that decision path with a regression test.
4. Exercise the authenticated workflow locally.
5. Deploy behind a reversible gate.
6. Verify the live route with the same request shape.

That sequence may touch the same files, but every step has a reason to stop. It also gives the reviewer a chance to change direction before a wrong model spreads across layers.

The staff-level tradeoff

Very small slices create coordination cost. They can encourage local optimization, produce a trail of mechanical reviews, and make cross-cutting design harder to see. Some changes, such as a schema migration with application compatibility requirements, only make sense as a coordinated set.

The answer is not maximal fragmentation. Keep the architectural decision whole, then make execution slices independently falsifiable. A slice can touch multiple layers if one end-to-end claim requires it. What it should not do is carry unrelated proof obligations merely because the same agent can edit all the files.

I also avoid slicing by time estimate. "A 30-minute task" says nothing about its blast radius or evidence. A two-hour read-only investigation may be safer than a five-minute production toggle.

A review test for every slice

Before an agent starts, ask four questions:

1. If this succeeds, what exact uncertainty disappears?
2. If it fails, will the result still teach us something?
3. Can the proof be reviewed without reading the entire conversation?
4. Can we stop here without leaving the system in a misleading intermediate state?

If the answers are vague, the task is not yet agent-sized. It is merely smaller prose wrapped around the same ambiguity.