Everyday productivity

Your first hour back, spent on work

One cited briefing of what happened while you were away, led by the things waiting on you and why each one reached you.

Coming back

Catch me up

Who it is for: Anyone who takes leave, and the lead who watches the day after cost more than the day off.
What starts it: Weekdays at 07:00 in your workspace's time zone, and only for somebody who was actually away; On a schedule

The cost of a week off is not the week. It is the Tuesday morning that follows it, spent reconstructing a state of the world that everyone else has been holding in their heads the whole time. Nine ticket histories, a board that has moved, and somewhere in it the four things that actually need you today.

Every recap that ships anywhere covers a fixed window — a day, a week, "since yesterday", "after hours". This one covers the absence. Your own last action in Aestus starts the period it reads, so somebody back after four days gets four days, and somebody who was at their desk gets nothing at all: below the threshold no run is created and nothing is charged.

What makes it short is what it refuses to read. The briefing is narrowed to the work that touches one person before a model sees anything, so there is no long list to be asked to shorten. Then it is capped, and every cap reports the number it left out rather than trimming the list quietly.

The part that earns it is at the top. "Waiting on you" is first, and each line says which of three things put it there: somebody else is blocked by one of your tickets, a run failed and nobody picked it up, or it is yours and has aged past the same staleness rule the rest of the product grades a waiting ticket by. Those three are ranked in that order, because being the reason another person is stopped costs more than your own ticket sitting still. A person coming back has no independent knowledge of what happened, so "why is this in front of me" is not something to leave them to work out.

Every number is computed before the model is asked to write anything, and the headline sentence is composed in code and copied across verbatim — a briefing whose headline was rephrased is rejected rather than published. Each line carries a source with a reference and a timestamp, and a figure with no source fails the review even when it looks right. No line is allowed to merge two records into one confident sentence, which is the specific way a summary that reads well becomes a summary that is wrong.

It is a personal answer, so it contains only what one reader may see. Every read is made as that person: a ticket owned by a team they are not on is dropped entirely — never shown with a placeholder — and counted in a number the document prints. Who the briefing is for comes from the run itself and cannot be supplied as a setting, so asking to be caught up as somebody else is refused rather than quietly honoured.

Then it ends in work rather than prose. Each ask becomes a ticket assigned to you, capped at a number you choose; an ask an earlier briefing already filed is updated instead of appearing a second time. Nothing else is written, nothing is sent, and the briefing waits on your standing catch-up ticket for the next time you are away.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Catch-up — Dana Okafor · 2026-09-03 → 2026-09-08 (2 working days away) · 4 waiting on you · 1 decided without you · 1 moved · 2 not visible to you

Produced by: Run NW-RUN-892 · read-only · document artifact · demo values

Waiting on you: 4 items, and NW-412 is first because PLAT-88 cannot move until it does. Every line says which of three things put it there — [someone is blocked by this], [a run failed and nobody picked it up], [assigned to you and waiting] — so a person who has been away is never left to work out why something is in front of them.
Decided without you: Sam Ferrer changed NW-412 while this person was out. A decision somebody else took is kept separate from work that merely moved, and an action the reader took themselves is never reported back to them.
If this changes while you read it: At most three if-then lines, each about an item already listed above and each citing a source: if NW-412 has left In Review since the briefing was written, the ask is already handled. Nothing here guesses at how likely that is.
What moved: NW-377 reached Done. Anything that finished inside the window is collapsed to its outcome in one sentence and can never appear as something waiting on you.
Quiet, so you know it is quiet: NW-301 has not been touched by anybody for 21 working days. Silence is stated rather than left to be assumed, and it is graded on the same staleness rule the rest of Aestus uses.
Left out: 2 rows were on a team this reader is not a member of, so they were dropped entirely and counted here rather than shown without their team. This section also states that mail, chat and meetings were not read at all.
Sources: One numbered row per record behind the lines above, each with its reference and the moment it was observed. A statement that cites nothing is refused before the document is written, and a figure with no source fails the review even when it looks right.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01It works out that you were away
Your own last action in Aestus starts the window, so the period it covers is the absence rather than a fixed day or week. Weekend days are not counted, and under the threshold nothing runs and nothing is charged.
02It reads only what touches you
Your tickets, the decisions other people took on them, the work that moved, and anything of yours that has gone quiet. The rest of the workspace never reaches the briefing, which is what keeps it short.
03It works out what is waiting on you, in code
Somebody blocked by one of your tickets comes first, then a run that failed and nobody picked up, then your own work that has aged past the same staleness rule the rest of Aestus uses. Every item states which of the three it is.
04It checks itself before you see it
A review step reads the draft first. Every number has to trace to a source it cites, and a figure with no source fails even when it looks right. One repair attempt, then the run fails rather than publish.
05It files the asks and saves the briefing
Each ask becomes a ticket assigned to you. An ask an earlier briefing already filed is updated instead of duplicated. The document is saved on your standing catch-up ticket and you are notified.

By hand, and on Aestus

The same job, on either side.

By hand
Scroll back through nine ticket histories to find the four things that need you.
On Aestus
A short list, led by what needs you, with everything else below it as context.
By hand
Read a summary and have no way to check it.
On Aestus
Every line cites a source with a reference and a timestamp. Open it.
By hand
Guess why something is in front of you.
On Aestus
Each item says which of three reasons put it there: somebody is blocked by it, a run failed, or it is yours and waiting.
By hand
Re-read a thread that was settled while you were out.
On Aestus
Anything that finished inside the window is collapsed to its outcome and can never appear as an ask.
By hand
Copy the asks you found into your own list.
On Aestus
They are already tickets, assigned to you, and a repeat ask updates the ticket instead of making a second one.
By hand
Never know what the summary skipped.
On Aestus
"Left out" names every dropped count and every source it did not read, with the reason.
By hand
Ask a colleague to catch you up, costing them half an hour.
On Aestus
Nobody is asked. The briefing is waiting when you open Aestus.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, duration and whether the review step passed, on the same ledger as every other run in the workspace.
The briefing
Every absence's briefing is a document on your standing catch-up ticket, so this morning's sits beside the one from your last time off.
What it read
The run records who it was for, the window, how long you were away and how many rows were withheld — so a short briefing can be told apart from a broken one.

What it connects to

This use case reaches no system outside Aestus. It reads governed evidence and writes a document, so there is nothing to connect and no approval to wait on.

Questions teams ask

Will it brief me every morning?

No. Only when you have actually been away. The default is two working days and you can change it. Below that, no run is created and nothing is charged.

Can it see work my colleagues can see but I cannot?

No. Every read is made as you. A ticket owned by a team you are not on is left out of the briefing entirely and counted in a number the document states, so the briefing is never quietly shorter than it looks.

Can somebody ask to be caught up as me?

No. Who a briefing is for comes from the run itself, never from a setting, and a request naming anybody other than the person running it is refused rather than ignored.

Does it read my mail, chat or calendar?

No. It reads the work Aestus already holds, including issues synced from Linear and Jira, and every briefing says under "Left out" that mail, chat and meetings were not read. A briefing that hid that gap would be worse than a short one.

Can it reply to anything for me?

No. It sends no mail, posts no messages and changes no calendar. The only thing it writes is the follow-up tickets it files for you, and it files no more than you allow.

All use cases How access is governed

Sources

docs/runbooks/use-case-workflows.md

Hand over Catch me up.

Tell us how your team does this today and we will set it up with you.

Talk to us

Questions teams ask

Will it brief me every morning?

No. Only when you have actually been away. The default is two working days and you can change it. Below that, no run is created and nothing is charged.

Can it see work my colleagues can see but I cannot?

Can somebody ask to be caught up as me?

No. Who a briefing is for comes from the run itself, never from a setting, and a request naming anybody other than the person running it is refused rather than ignored.

Does it read my mail, chat or calendar?

Can it reply to anything for me?

No. It sends no mail, posts no messages and changes no calendar. The only thing it writes is the follow-up tickets it files for you, and it files no more than you allow.

Sources

docs/runbooks/use-case-workflows.md

Your first hour back, spent on work

Catch me up

What you get

Catch-up — Dana Okafor · 2026-09-03 → 2026-09-08 (2 working days away) · 4 waiting on you · 1 decided without you · 1 moved · 2 not visible to you

How it runs

By hand, and on Aestus

What Aestus records

The run

The briefing

What it read

What it connects to

Questions teams ask

Other use cases

Hand over Catch me up.

Your first hour back, spent on work

Catch me up

What you get

Catch-up — Dana Okafor · 2026-09-03 → 2026-09-08 (2 working days away) · 4 waiting on you · 1 decided without you · 1 moved · 2 not visible to you

How it runs

By hand, and on Aestus

What Aestus records

The run

The briefing

What it read

What it connects to

Questions teams ask

Other use cases

Hand over Catch me up.