How to Write Tasks AI Agents Can Actually Finish

Start with the change you want to observe

Weak tasks describe activity: investigate the bug, improve the page, clean up the code. Strong tasks describe an observable change. A visitor can submit the form with a valid phone number. A project owner can see overdue work without opening every task. The build completes with the new route included in the sitemap.

That distinction matters because an agent can produce a great deal of activity without reaching the result you meant. Put the outcome in the first two sentences. If the task has several outcomes, split it before the agent starts. Smaller contracts are easier to review and much easier to roll back.

Put the evidence beside the outcome

Define how the agent can prove the change works. Name the relevant checks, the route to inspect, or the behavior that must remain unchanged. Evidence can be a focused unit test, a type check, a production build, a screenshot, or a short manual path. Choose the lightest proof that matches the risk.

Avoid the phrase make sure it works. It transfers the most important decision to the agent. Say what working means: duplicate slugs fail a test; an unknown article returns 404; the mobile navigation still exposes the Blog link; no private application routes appear in the public sitemap.

• Name the command or user path that proves the result.
• Call out one behavior that must not change.
• Say whether browser, live-service, or deployment checks are in scope.

Bound the agent’s authority

Context tells the agent what is true. Authority tells it what it may change. Keep those separate. A repository can contain old experiments, local credentials, generated artifacts, and half-finished work. Their presence is not permission to edit, delete, publish, or migrate them.

Useful boundaries are concrete: keep the existing authentication flow; do not change Firestore rules; add the feature inside the marketing route group; preserve demo-mode parity; do not start a development server. These instructions reduce accidental scope more effectively than a long description of the product.

Give context in the order it will be used

Lead with the current user path, then the owning files, then the relevant conventions. An agent should be able to trace page to component to data boundary without reconstructing the entire product history. Link to a design or architecture document when it is authoritative, but summarize the rule that matters for this task.

Do not paste every meeting note into the task. Excess context raises the chance that an obsolete idea looks like a current requirement. Prefer a short statement of present behavior and a link to the source of truth. If two sources disagree, name which one wins.

Use a task brief that can survive a handoff

The final test is simple: could a teammate understand what changed, why, and how it was verified without reading the chat that produced it? If not, the task is still dependent on hidden context.

A durable brief uses five fields. Keep each field short enough to scan before work begins.

• Outcome — the user-visible or system-visible change.
• Current path — where the behavior lives today.
• Boundaries — what the agent may and may not change.
• Evidence — the checks that demonstrate completion.
• Handoff — files changed, decisions made, and remaining operational work.

Review the diff, not the confidence

An agent can sound certain while misunderstanding the architecture. Review the changed contract: routes, data shapes, permissions, and tests. Ask whether the implementation preserved the boundaries in the brief. The answer should be visible in the code and verification output, not inferred from a confident summary.

This is also where a task manager earns its place. The brief, implementation notes, verification, and follow-up work should stay attached to the task. The next person should not need to search a chat transcript to discover why a boundary exists.