The Four Color Status Method for Humans and AI Agents

By Dennis Yu

Article revision 1.1 · Reporting contract 1.0 · 13 October 2026

Status	What it means
🔴 NEEDS YOU	a specific human decision or action is required.
🟠 BLOCKED — WE'RE HANDLING IT	something is blocking progress, and the agent or team owns the resolution.
🔵 WORKING	execution is actually underway.
✅ DONE	the stated outcome has been verified.

This method extends How the Agents Run the Company. Keep the same outcome owner and authoritative task record. Add a consistent way to read its current condition.

I like being able to scan an update and immediately see where I’m needed. Color helps. But the color only works when everyone agrees on what it means.

Our variation on the stoplight method uses four signals:

Read the task → choose the status → act within authority → verify → update the same record.

The purpose is to help people allocate attention. An update should tell me what changed, who owns the next move, and whether I need to do anything. It should give another agent enough context to continue the work without making up the missing pieces.

Everything we do for humans should be available for agents, and vice versa. That means the same definitions, evidence, ownership, and acceptance tests. Access and authority still follow the permissions for that person or agent.

Client relationship health has a separate legend

Client relationship health has a separate legend, explained in the agency client-health stoplight method:

🟢 CLIENT GREEN: the client explicitly said they were happy within the last seven days.
🟡 CLIENT YELLOW: recent satisfaction is unconfirmed; yellow is the default when unsure.
🔴 CLIENT RED: no communication for over seven days, or a team member believes there may be dissatisfaction.

Seven-day example: the client said they were happy eight days ago, then sent a routine message yesterday. With no concern about dissatisfaction, client health is yellow. The latest deliverable can still be ✅ DONE.

A red client requires owned action; use task-level 🔴 NEEDS YOU only when the named recipient must act. Keep client health and task workflow in separate fields: recent happiness does not prove every task is done, and verified task completion does not establish client happiness.

What each color requires

Red means a specific decision or action

Use 🔴 NEEDS YOU when the task genuinely requires the person receiving the update to act. Name the decision, explain the consequence of waiting, and recommend a choice.

“Please advise” leaves too much work with the reader. “Approve the shorter article or keep the longer version? I recommend the shorter version because it fits the agreed audience” gives them something they can decide.

Include the actual deadline, if there is one. Red identifies a dependency on the reader; it does not automatically mean urgent. An approval due next week can be red. A serious outage being resolved by the authorized team can be amber. Importance, urgency, and status belong in separate fields.

An agent should first check whether the answer is already in the task, evidence, or recorded permission. Don’t turn a routine lookup into a human decision. Don’t hide a required approval in a progress paragraph either.

Amber means the owner is responsible for the blocker

Use 🟠 BLOCKED — WE'RE HANDLING IT when progress depends on something unresolved, but the reader does not need to act.

State the exact blocker, the person or agent responsible for resolving it, the next action, and when the owner will check again. If another team owns the dependency, the outcome owner still owns following it through.

For example: “The export service hasn’t returned the file. Morgan owns the retry and will check at 15:00 UTC. The completion estimate depends on that response.”

Amber includes honest waiting. It never means the task can disappear. A promised check must have a real owner and a workable way to occur. If the current environment cannot run later, record that limitation and arrange an authorized handoff. Don’t claim monitoring has been set up just because a sentence says it will happen.

Blue means actual execution

Use 🔵 WORKING when someone or something is actively doing the next step. Say what is underway, what comes next, and the best supported completion estimate.

A request sent to another agent does not prove execution. Neither does a task sitting in a queue. “Checking the revised page on mobile; next I’ll test its links” describes work. “On it” tells the reader very little.

An estimate can be a range, such as “About 20–30 minutes to finish the mobile and link checks.” If there is no defensible estimate, say it is unknown, explain the dependency, and give the next check. Never invent precision to make the status look better.

Green means verified completion of the named scope

Use ✅ DONE when the stated acceptance tests have passed and the intended recipient can inspect suitable evidence.

Name exactly what is complete. Link the result or receipt, state what was checked, and identify any remaining scope. “Draft complete” and “Article published” make different claims.

Follow the task’s required review level, including independent review where required. Record who checked which revision, when, and what passed.

If the draft is finished but publication is waiting for approval, the draft can be green while the article project remains red. Show the overall project condition alongside the finished substep. A green component must never conceal an unresolved outcome.

Our Trust but Verify guide makes this practical: check the result where it was supposed to land. A local export can prove a file was created. Public availability requires opening the intended live destination and checking the intended revision.

Keep queued work visible

Work that has not started belongs in a plainly labeled “Queued” or “Not started” section, with its owner and start condition. It has no color yet. This is a neutral queue, not a fifth status.

If a queued task needs the reader’s decision before it can start, show red and retain “not started” as its execution condition. If it is waiting on an unresolved dependency owned by the team, show amber. If it is simply scheduled for later, leave it neutral.

Likewise, label cancelled, parked, or out-of-scope work honestly in the task record. Cancellation is not successful completion. Colors summarize attention; they do not replace every lifecycle detail.

Choose and change status from evidence

Use this decision order for the exact scope being reported:

Does this scope require a specific decision or action from the named human recipient? Use red, state the ask, and recommend the next move.
Have all required acceptance tests passed? Use green with evidence.
Is progress blocked or waiting on a dependency the owner is handling? Use amber.
Is authorized execution actually happening? Use blue.
Has it simply not started, or has it been parked or cancelled? Use the explicit neutral lifecycle label.

Update the record when the facts change. Red becomes blue only when the required action happened and execution began. Approval alone may move it to the neutral queue. Amber becomes blue when the blocker clears and execution resumes. Blue becomes amber when progress stops on a dependency. An open task becomes red when a necessary action from the named human recipient emerges. Team-owned human work stays blue or amber according to its condition.

Blue becomes green after verification, not merely after implementation. If new evidence invalidates a completed result, reopen it with the appropriate current color and explain what failed. Preserve the earlier receipt so the history remains understandable.

For a project with parallel work, roll up to the decision or blocker that governs the overall outcome. Show meaningful active branches underneath. Don’t average the colors or count completed subtasks to infer completion.

Distinguish a handoff from a result

Keep four milestones explicit:

Dispatched: the request was sent through the intended route.
Accepted: the next owner acknowledged the scope and can continue.
Implemented: the requested change or artifact exists.
Verified or live: the relevant acceptance checks passed; a publication claim also passed checks at the live destination.

These are milestones, not extra colors. A task can be accepted and still queued. It can be implemented while verification is actively blue or waiting amber.

How Work Moves explains the accepted handoff. Until the next owner has the right artifact, understanding, tools, and authority, the current coordinator retains responsibility. Sending an instruction does not transfer accountability by itself.

One compact update for people

The following is a fictional example. Names, dates, and timing demonstrate the format; they are not service commitments.

🟠 BLOCKED — WE'RE HANDLING IT | Training article publication

Outcome: publish the approved article and verify public access.
Blocker: the publishing service has not returned the requested preview.
Owner: Morgan, publication coordinator.
Next: check the existing request, then retry if appropriate.
ETA: unknown until the preview is available; allow 20 minutes for the remaining checks after it arrives.
Next check: 14 October 2026, 15:00 UTC.
Human action: none.
Evidence: the current task record and request receipt, accessible to the authorized team.
Completed substep: ✅ DONE | Copy approved. Overall publication remains blocked.

Keep the headline short enough to scan. Put supporting details in the linked record. Red updates should lead with the decision and recommendation. Green updates should lead with the verified result.

The same update for agents

Use a structured record when another system needs to parse the update. Generate the human summary from the same facts so the two versions cannot quietly disagree.

Here is the same fictional example. The example.invalid addresses are placeholders, not usable evidence.

{
  "framework_version": "1.0",
  "task_id": "training-article-publication",
  "record_url": "https://example.invalid/tasks/training-article",
  "scope": "Publish approved article and verify public access",
  "status": "blocked_owned",
  "label": "BLOCKED — I'M HANDLING IT",
  "execution_state": "waiting",
  "owner": "Morgan, publication coordinator",
  "resolution_owner": "Morgan, publication coordinator",
  "observed_at": "2026-10-14T14:30:00Z",
  "blocker": "Publishing service has not returned preview",
  "next_action": "Check existing request; retry if appropriate",
  "eta": {
    "completion_at": null,
    "dependency": "Preview available, then 20 minutes of checks"
  },
  "next_check_at": "2026-10-14T15:00:00Z",
  "check_owner": "Morgan, publication coordinator",
  "check_method": "Morgan's confirmed manual check",
  "human_action": null,
  "acceptance_tests": [
    "Approved revision published",
    "Anonymous access and page links verified"
  ],
  "milestones": {
    "dispatched": true,
    "accepted": true,
    "implemented": false,
    "verified_live": false
  },
  "evidence": ["https://example.invalid/tasks/training-article"],
  "completed_substeps": ["Copy approved"],
  "remaining_scope": ["Publish", "Verify public access"],
  "authority": "Existing recorded publishing permission only"
}

Store the record’s location, evidence references, and authority source in the real implementation. A boolean milestone needs a supporting observation. Use null for an unknown fact rather than quietly treating it as false.

The companion agent specification, reporting contract version 1.0, defines field requirements and validation rules. A structured file makes the method portable; each host still needs its own tested integration. Pasting a prompt does not prove installation or reliable execution.

A reusable prompt

Give a person or agent the task, the current record, and this instruction:

“Use the four-color status method. Keep one outcome owner and one authoritative task record. Use red NEEDS YOU only for a specific necessary human decision or action, with your recommendation. Use amber BLOCKED — WE'RE HANDLING IT for an unresolved dependency you or the team own, with the blocker, owner, next action, ETA dependency, and next check. Use blue WORKING only for actual active execution, with the next step and best supported estimate. Use green DONE only for the named scope after verification, with accessible evidence and remaining scope disclosed. Keep ordinary not-started work in a neutral queue. Distinguish dispatched, accepted, implemented, and verified or live. Keep the human summary and agent record consistent. Follow existing permissions and safety requirements. Never manufacture activity, evidence, access, or completion. Send an update when it changes attention, decisions, timing, or the accepted result.”

Adopt it with a small test

Start with one real workflow and a clear definition of done.

Name its outcome owner, authorized audience, authoritative record, and required checks.
Add the four labels to the existing reporting surface. Include text every time; color alone is insufficient for accessibility, voice, or plain-text systems.
Record dependencies, actual owners, permission boundaries, and evidence links. Confirm the intended reader can open them.
Choose practical check times and escalation conditions. Verify that reminders or scheduled checks really work before relying on them.
Run the cases below through both the human update and the structured record. Fix disagreements before wider adoption.

Use these acceptance tests:

Request sent, no acknowledgment: dispatched only. Neutral if normally queued; amber if acceptance is blocking progress. Never claim active work without evidence.
Approval required: red, with a specific ask and recommendation.
External service delayed, owner resolving it: amber, with a next check.
Worker actively checking an artifact: blue, with the current check and next step.
Draft passed its checks, publication awaits approval: green draft substep; red overall publication.
Editor says “published,” live page is wrong: no green publication claim. Blue during active repair or amber when blocked.
Evidence cannot be opened by its authorized reviewer: delivery remains unverified; name the missing check.
A recipient lacks permission: retain the boundary. Share a safe summary or seek the necessary approval.
A completion estimate slips: update the estimate and cause. Ask the human only if their action is necessary.

These tests check honesty and consistency. They do not establish a universal productivity improvement.

Improve the method with MAA

Use Metrics, Analysis, Action to evaluate what the reporting changes in the actual work.

Metrics: record observable facts, such as time waiting for a decision, blocked tasks missing a next check, reopened completion claims, or results accepted on first review. Define the measure and period before comparing runs.

Analysis: ask why the delay or defect happened. Was the permission unclear? Did nobody accept the handoff? Was the definition of done incomplete? Distinguish evidence from a hypothesis.

Action: make a specific correction, assign an owner, and check the result on the next run. Counting blue updates tells us little about accepted outcomes.

How the System Learns describes how a supported lesson becomes a reviewed change to the maintained recipe. Keep the article and reporting contract compatible; record their separate revisions. Test a valid example and a deliberately invalid example, then verify the revised instructions reach the workers using them.

Protect attention and permission

Send an update when a decision is needed, a material blocker appears, an estimate changes, a promised check is due, or a result is verified. Combine routine progress where practical. Repeated “still working” messages should earn their place by adding useful information.

The four colors grant no new authority. They do not authorize purchases, publication, private-data sharing, security changes, or contacting additional people or agents. Follow the permission and safety requirements that apply to the task.

Human and agent parity means either can understand the work, inspect the permitted evidence, and continue within their authority. It does not require exposing private records publicly or giving every worker the same access.

The test is simple: can the reader tell what is happening, whether they are needed, and what happens next? If the update answers that honestly, the colors are doing their job.

Four Color Status Agent Specification

Version 1.0 · 13 October 2026

Purpose and source

This is the executable reporting companion to The Four Color Status Method for Humans and AI Agents by Dennis Yu, article revision 1.1. This reporting contract remains version 1.0; the task-status meanings are unchanged. Adopt them in the existing authoritative task record; do not create a competing board or outcome owner.

Public operating-model references:

https://dennisyu.com/how-agents-run-the-company/
https://dennisyu.com/how-agents-run-the-company/how-work-moves/
https://dennisyu.com/how-agents-run-the-company/trust-but-verify/
https://dennisyu.com/how-agents-run-the-company/how-the-system-learns/

Trigger and prerequisites

Use when reporting a task, handing it off, changing its observed state, checking a dependency, or recording completion.

Read the current task, source revision, owner, audience, authority, acceptance tests, and latest evidence first. Find the existing task before opening a new record. Verify which tools, access, and scheduling capabilities are actually available.

A pasted specification is guidance. It does not install a runtime, prove activation, or authorize new actions.

Stable status mapping

needs_you → 🔴 NEEDS YOU. A necessary action belongs to the named human receiving the decision request. Require a specific ask, recommendation, reason, and real deadline or explicit absence of one. Ordinary team-owned human work remains blue or amber; it does not become red merely because a human performs it.
blocked_owned → 🟠 BLOCKED — WE'RE HANDLING IT. An unresolved dependency prevents progress; the outcome owner or team owns resolution. Require the blocker, resolution owner, next action, ETA dependency, and next check or an explicit check-arrangement blocker. Human action is null.
working → 🔵 WORKING. Authorized execution is observably active. Require the actual current step, execution evidence, next action, and best supported ETA or reason it is unknown.
done → ✅ DONE. The exact stated scope passed its acceptance tests. Require the result, verification receipt, evidence accessible to the authorized reviewer, and any remaining scope outside the completed scope.
null → no color. Use an explicit execution state such as queued, parked, or cancelled. Null is the absence of an attention status, not a fifth color.

Always render the text label beside the symbol. A plain-text or voice channel can omit the symbol while retaining its full meaning.

Required record fields

All records need framework_version, task_id, record_url, scope, owner, execution_state, status, label, observed_at, authority, acceptance_tests, and evidence.

Open records also need next_action, eta, and next_check_at or a documented reason no check can yet be arranged. Use absolute timestamps with time zones. A completed scope can set next action and next check to null. If further monitoring is part of the scope, it is not complete until the agreed stopping condition is reached.

Use execution_state for queued, active, waiting, complete, parked, or cancelled. Keep the host’s existing lifecycle state separately if needed. Do not relabel the existing packet or capability vocabulary to force a one-to-one mapping.

status permits only needs_you, blocked_owned, working, done, or null. label must match the mapping. A null status needs a neutral label such as “Queued” or “Cancelled”.

Additional conditional fields:

human_action: null, or an object with recipient, exact ask, recommendation, consequence of waiting, deadline, and the authorization or decision required. A missing recommendation must state why no supported recommendation is possible.
blocker: null, or a precise description of what cannot proceed and why.
resolution_owner: who owns the next attempt or dependency follow-through; preserve the accountable outcome owner too.
current_step: observed active work; never infer it solely from dispatch or acceptance.
eta: estimated completion timestamp or range, assumptions, and dependencies. Null timing plus an explicit reason is acceptable.
next_check_at: the next promised observation time. Record who will perform it and how; verify a scheduled mechanism if one is claimed.
verification: checker, observed timestamp, artifact revision, destination, acceptance-test findings, and receipt references. Identify unperformed checks.
milestones: dispatched, accepted, implemented, and verified or live, each with its own observation and evidence. Booleans alone are summaries; preserve receipts in the linked record. Unknown is null, not false.
remaining_scope, completed_substeps, priority, and deadline: keep these separate from color.

Decision procedure

Fix the scope being reported and read current evidence.
If a necessary decision or action from the named human recipient remains for that scope, choose needs_you.
Otherwise, if every required acceptance test passed, choose done.
Otherwise, if progress depends on an unresolved owner-handled dependency, choose blocked_owned.
Otherwise, if execution is actually active, choose working.
Otherwise use null and the truthful neutral lifecycle label.
Write the same facts to the human summary and structured record. Preserve the previous observation and reason for a transition.

For parallel projects, report the governing overall dependency and describe active branches separately. A blocked noncritical subtask does not automatically make the entire project blocked. A green subtask never proves the overall outcome complete.

Red approval received does not imply blue execution. Amber dependency cleared does not imply green completion. Implementation does not imply verification. A new defect can reopen a green result. Parked and cancelled tasks never become green merely because no further work is planned.

Evidence and authority controls

Keep dispatched, accepted, implemented, and verified or live distinct. The current owner retains responsibility until the receiving owner accepts the handoff with the canonical revision, scope, acceptance tests, tools, and authority.

Do not claim sent, delivered, published, fixed, or installed from a local artifact or intent alone. Test the appropriate destination or behavior. Follow the task’s required review level, including independent review where required. Verify recipient access where relevant. Never widen access merely to make an evidence link open.

This reporting method grants no permission to spend, publish, send messages, disclose private data, change security settings, or contact additional agents. Resolve required authorization before those actions. Keep secrets and private client information out of public examples.

Notification and stopping rules

Notify when a decision is needed, a consequential blocker appears, scope or ETA materially changes, a promised check is due, or the accepted result is verified. Consolidate routine activity. An unchanged status can justify an update if a promised check was due; state what was actually checked and the next step.

Keep owner-handled waiting active in the task record. Choose the next check from the dependency, deadline, or agreed cadence. Stop on verified completion of the agreed scope, explicit cancellation, accepted handoff, or a genuine need for additional user authority. An accepted handoff ends the sender’s execution role, while the new owner continues the task. Never imply continuous activity or automatic wake-ups that the runtime does not support.

Validation cases

The following are fictional tests of the reporting contract:

Dispatched, no acknowledgment, ordinary queue: null / queued; current owner retained.
Acceptance delay is blocking delivery: amber, with follow-through owner and next check.
Human budget approval required: red with exact request and recommendation; no purchase from this specification alone.
Export pending, team owns recovery: amber with unknown ETA explained.
Reviewer is actively checking the final file: blue, even though implementation finished.
Draft verified, publication awaits approval: green draft; red overall publication.
Publisher reports success but live page has wrong revision: no green publication result.
File exists locally but authorized recipient access is untested: no verified-delivery claim.
Task cancelled by the authorized owner: null / cancelled with reason.
New evidence contradicts a green receipt: reopen, preserve history, explain the defect.
Claimed active work has no current observation: do not fabricate blue; investigate the state and report any blocking uncertainty.
Public summary requests private evidence: preserve the audience boundary; provide an authorized summary or ask for the needed permission.

Run valid and deliberately invalid samples. A validator that accepts “done” without evidence must fail acceptance. Automated field checks cannot establish that evidence is true; an appropriate reviewer must inspect the result.

Improvement and adoption receipt

Use MAA: record observations, analyze the cause, assign the smallest useful correction, and check it on the next run. Preserve source revision and evidence. Review changes before adopting them.

An adoption receipt names the specification revision, host and scope, installation or configuration performed, activation test, valid/invalid test results, observed real use, limitations, and owner. A shared URL, installed file, and successful runtime use are different claims. No fleet-wide adoption claim is valid until the defined fleet scope has matching evidence.