Operator NotesAi Operating SystemAi Agent Management

The Status Update Your Agent Should Write: Owners, Recommendations, and Nothing Twice

An agent status update is a routing document, not a summary. Six rules and a copy-paste update card so the human reads it in two minutes and acts.

The update looked complete. Progress by workstream. Risks highlighted. Timeline shifts noted. Green where things moved. Amber where they hadn't.

The exec still asked the same question at the end of the meeting: so what do you need from me?

That is the failure mode of most agent-written status updates this fall. The report summarizes the work. It does not route the work. The human still has to dig for the decision that belongs to them, chase items that belong to someone else, and wonder whether "quiet" means stalled or waiting.

Status is a routing document

Vendors spent September and October shipping agents that write the report for you.

  • monday's Status Reporter pulls progress, risks, and timeline changes on a schedule, with a simulation mode before you turn it on.
  • Asana's AI Teammates include an Executive Reporter and a "Chief of Staff" surface for what needs attention.
  • Wrike's Project Manager Workmate is coming with meeting-to-status and risk monitoring.
  • Empwr refreshes status from tickets and meetings, and every line links to its source. Their line is the right one: the judgment stays with the people running the program.

Those products answer useful questions: who writes the report, can I check the source, will it refresh when a ticket moves. They do not answer the operator question: what must an agent's update contain, and what must it leave out, so the human reads it in two minutes and acts.

A summary lists what happened. A routing document tells each reader which lines are theirs, what to decide, and which lines they can ignore because someone else owns them.

That is the shift. Treat the agent update as routing, not narration.

Six rules for an agent-written update

1. Every line names an owner

If a line has no owner, it is not ready for the update. The agent invents motion without accountability. Put a name (or a role) on every item before it lands in the report.

2. Your lines come with a recommendation

When the item is on the reader's plate, status alone is not enough. The agent should say what it recommends: approve, defer, kill, or ask X for Y by date. The human can reject the recommendation. They should not have to invent one from a paragraph of context.

3. Other people's lines get tagged and stop there

Items owned by someone else are tagged to that person and go no further. The agent does not chase people. It does not escalate a tagged item into the reader's action list. Program-level items stay with the human program owner. One later piece in this series covers the routing behind that rule; for this playbook the rule is enough: tagged, then stop.

4. One agent per stream raises asks

Duplicate asks are how agents waste a founder. If three bots can raise the same client's or workstream's asks, the human answers the same question three times. One delivery agent per stream is the only one allowed to raise that stream's asks. Everyone else writes to the ticket, not to the human.

5. Quiet isn't stalled when the ball is with a person

A channel that went quiet is not proof the work stalled. If a person has the ball, say who has it and since when. Mark it waiting-on-human. A weekly score that once flagged a quiet bot as stalled had to be retracted for exactly this reason. Waiting is a state. Stalled is a different state. Do not collapse them.

6. Must-fix items repeat until fixed or deferred

Important open items do not get to vanish because the agent got tired of saying them. They keep appearing until they are fixed, or until someone writes down why they are deferred. A deferred must-fix without a reason is just a quiet fail.

Two supporting habits sit under the six:

  • Generate status from tickets, dates, and decisions. Do not keep a second tracker by hand. Empwr's source-linked refresh is the right direction; the point is the same whether you buy that product or not.
  • Mark what the source said versus what the agent inferred. A claim is validated only when the source said it. That is the same split as evidence-aware CRM fields: observed on top, inference labeled, never mixed into one confident sentence.

What to check when you switch a vendor agent on

This is not a teardown. Ask the product, or write the gaps into the agent's instructions, before you trust the first report:

  1. Can every line name an owner?
  2. Can it separate "needs you" from "tagged to others"?
  3. Does a "needs you" line carry a recommendation?
  4. Can it suppress asks another agent already raised?
  5. Can it tell waiting-on-a-person from stalled?
  6. Does each line link to its source?

If the product can link to source and refresh from tickets, keep that. Add the routing rules above as standing instructions. Source tracing without routing still leaves the exec reconstructing the ask.

The agent update card

Copy this. Fill it for one stream, one cadence. Give the blank sections to the agent as the shape of every update.

markdown
# Agent update card — [stream] — [date]

## Needs you (with recommendation)
- Item | Owner: you | Recommendation: approve / defer / kill / ask __ by __
  Source: [link]

## Tagged to others (no action from you)
- Item | Owner: __ | Tagged: yes | Stopped: yes
  Source: [link]

## Waiting on a person
- Item | Who has it: __ | Since: __
  Source: [link]
  Note: not stalled

## Still open must-fix
- Item | Open since: __ | Deferred?: no / yes — reason: __
  Source: [link]

## Done with receipt
- Item | Receipt: [link or confirmation]

One-line instruction to give the agent:

Write every update in the five sections above. Name an owner on every line. Put a recommendation on mine. Tag other people's items and stop. Say who has the ball when work is waiting. Repeat must-fix items until fixed or deferred with a reason. Link each line to its source. Do not keep a second tracker.

A single finished task still needs a receipt. This card is the recurring update across many items. Bring the filled card into the weekly operating review; that meeting should decide, not reconstruct.

Try it this week

Pick the status agent you already turned on, or the one you are about to. Paste the one-line instruction. Demand the five sections on the next run. If the first report still leaves you asking what you need to decide, the agent is summarizing. Make it route.

Questions or a card you want a second pair of eyes on: rick@datasaa.com.

Frequently asked questions

What should an AI agent include in a status update?

Every line needs a named owner. Lines that belong to the reader carry a recommendation. Other people's lines are tagged and stop there. Must-fix items keep repeating until they are fixed or deferred with a written reason. Quiet work waiting on a person is labeled that way, not stalled.

Why do AI status reports still leave executives asking what they need to decide?

Most vendor agents answer who writes the report and whether you can check the source. They do not answer what must appear on the reader's plate and what must stay off it. Without owners, recommendations, and a stop rule for other people's work, the update is a tidy summary that still needs a human chase.

How is an agent status update different from a weekly operating review?

The agent update is the input. The weekly operating review is where a human decides what to keep, fix, or stop. Fill the update so the review only looks at decisions, not reconstruction.

What should I check before turning on a vendor status agent?

Can it name owners, separate your lines from everyone else's, carry a recommendation on yours, suppress duplicate asks, tell waiting-on-a-person from stalled, and link each line to its source? If any of those are missing, put them in the agent's instructions before you trust the report.