How to Make AI Tasks Control the Work, Not Just Describe It

What is an executable work record?

An executable work record is a saved task or bug whose fields affect what the team may do next. It does more than describe the work. It can refuse a bad status change.

Think of a paper work card at a repair shop. The card names the job, owner, expected result, current state, and checks. The mechanic can start with some blanks. The shop should not stamp the card complete while the owner, result, or inspection is missing.

The same rule applies to AI task management. A task can begin as a rough idea. Before it moves into active work, its purpose, owner, scope, linked need, and criteria should be clear. Before it moves to done, its proof references should be present.

Engineers may call a rule that must remain true an invariant. A final-state guard is the check that applies that rule before done or released is saved.

The guard belongs where the real status changes. A prompt can propose the record. A checklist can remind the team. Neither one controls the work if another path can still set done without the check.

This task-level record is not the whole workflow. A workflow state machine controls the stages of a full run. The task record controls one unit of work inside that run. It also does not prove that linked evidence is true. It only makes missing proof visible and blocks a final state when the required reference is absent.

What should the smallest useful task hold?

Start with the fields that change a decision. Do not copy a large project-management template and hope the team fills it in.

The table below is a small contract for one product task. The exact labels can change. The decisions they support should not.

Give the record one owner at a time. Microsoft documents the same pattern for Azure Boards work items. A work item can hold an assignee, state, reason, links, attachments, and change history. Microsoft also says only the title is required for every work-item type by default.

That contrast matters. A tool can provide useful fields without making them required at the moment they matter. Your team still has to set the rule.

Links help another person walk from the task back to the need and forward to the check. A link is still only a pointer. It does not prove the target is current, correct, or passed.

How should a bug move into executable work?

A bug report starts with an observation. A task starts with a chosen piece of work. Do not force both into one vague card.

Triage then makes a decision. The team can close the report as a duplicate, defer it with a reason, request more evidence, or promote it into a work task.

Promotion should create or link one task. That task gets the owner, scope, acceptance criteria, and evidence plan. The bug keeps the original observation. Do not paste two independent copies and call them synchronized.

The link between them should work in both directions: Bug I-104 -> work task T-219. Work task T-219 -> source bug I-104.

This makes the handoff inspectable. It also prevents a common trick: marking the bug fixed because a task was created. Creation is not completion. The bug should close only after the task reaches its valid final state and the observed behavior is checked again.

What must be true before a task can be done?

The final-state guard should check two different things.

First, it checks the requested move. A task in proposed should not jump straight to done. Second, it checks the final record. A task in in_review should still fail if its owner, criteria, or proof reference is missing.

This small table is enough for a first version.

A useful refusal says: REJECTED. Done cannot follow proposed. Missing owner. Missing linked need. Missing acceptance criteria. Missing evidence reference. Allowed next state: planned.

Atlassian documents this pattern for Jira Cloud. A team can add a required-field validator to the transition into Closed. If that field is empty, Jira refuses the move.

That is real enforcement, but it has a limit. A filled proof field does not mean the proof is real. It may point to an old result, the wrong version, or a failed check.

The rule here is narrower: no final state without an inspectable reference, and no skipped state even when the fields look complete.

What do current agent tools already control?

Some current agent tools already use task records to control part of the work.

Anthropic's Claude Code agent-team documentation describes shared tasks with pending, in progress, and completed states. A pending task with unfinished dependencies cannot be claimed. A configured TaskCompleted hook can also return an error and stop a task from being marked complete.

Those are useful controls. They show two places where the record can make a decision: before work starts and before it ends.

Anthropic also lists task-status lag as a known limitation of the experimental feature. A teammate may finish the work without updating the task. Dependent tasks can remain blocked until someone checks the work and repairs the status.

That does not mean every completion label is false. It means the saved label and the real work can drift apart. The repair path needs a person or process that can inspect both.

I use those examples to derive one design rule for my own systems.

What happened when I tested the final-state guard?

I tested the rule against a frozen public version of WarpOS, my agentic operating-system project for long-running AI work.

The experiment used made-up tickets in a disposable copy of commit 8b083d78948263c998134ac5d34947c383e17a85. It made no network call. It did not read or change live WarpOS work records.

I evaluated each request with a small proposed guard. I then let the frozen helper write the requested status so I could compare the two decisions.

The second case matters. Filling every field did not make proposed -> released a valid move. Record completeness and transition order are separate checks.

The third case matters too. The proposed guard did not ban final states. It allowed a reviewed task with one owner, a linked need, acceptance criteria, evidence references, and no open blocker.

The experiment proves only these three synthetic decisions at the frozen commit. It does not prove that an evidence reference is true. It does not test production reliability, security, concurrent updates, release safety, or outside approval. It does not claim that later WarpOS versions behave the same way.

What did WarpOS reveal about executable tasks?

WarpOS already had a strong record shape at that frozen commit.

Its ticket guide called a ticket the smallest executable unit. The record could hold an owner, linked requirements, acceptance criteria, tests, commits, releases, blockers, and completion evidence. The create command checked the title and type. It also blocked an ambiguous sprint choice. Status changes repaired the current-sprint buckets so one ticket did not stay listed in two states.

Those are real controls.

The gap was in the final write. A new ticket could start with no owner, links, criteria, or evidence. That is reasonable early in its life. The update command later checked whether the requested status was a known word. It did not compare the old state with the new one. It also did not require the missing fields before done or released.

So the record could describe the right model without enforcing its meaning.

The bug path showed a related handoff problem. Its promotion command printed the next task-creation command for a person to run. That no-side-effect choice can be sensible. But the guide described the new ticket and back-link as if they had already been recorded.

The safe lesson is not that enforcement was absent. WarpOS had useful input checks and real bucket repair. The lesson is that each claim in the guide must match a check in the write path.

A rich record is still documentation until a decision reads it.

How can your team build the first version this week?

Pick one task that often gets reopened. Do not begin with the whole backlog.

Write the minimum record from this guide. Choose four or five states. Name the allowed moves. Then place one guard where the real status changes.

Plant three tests before trusting it. Try one normal move, such as planned -> in_progress. Try to move an empty proposed task straight to done. Fill every final field, then try a skipped move such as proposed -> released.

The first should pass. The other two should fail for different reasons.

Use the prompt below to draft the contract. A person still needs to confirm the facts and connect the guard to the real status change.

Review the returned owner, links, criteria, and state table. Then make one person responsible for the guard. If a manual edit can bypass it, test that path too.