Everyday productivity

Six changes that would fix next week

Every Friday, a review of next week's calendar: each conflict, each back-to-back run, each meeting with no work behind it, and the change to make.

Join the waitlist See what it produces

Before the week starts

Clean up your calendar

Who it is for: Anyone whose next week is already booked and has ten minutes on Friday to send declines, not an hour to find them.
What starts it: Every Friday at 15:00 in your workspace time zone, and on demand whenever you want one; On a schedule

Turn it on in Aestus

A calendar review is only worth reading if you can act on it in the ten minutes you actually have, and only worth trusting if every line in it can be checked. Everything below follows from those two sentences.

So it never changes anything. That is the decision the whole use case is built around, and it is worth saying plainly because the obvious version of this product does the opposite. A wrong decline is not a small mistake you correct later: it sends mail to whoever called the meeting, it takes you out of a room somebody was counting on, and there is no undo. Cancelling a recurring series deletes other people's time. The rules that find these meetings are good enough to put a line in front of you — an overlap measured in minutes, a ticket that is closed, an agenda that is empty — and nowhere near good enough to act on your behalf. An empty agenda can mean the agenda is in a document. Two attendees can mean the other six read the notes. So the review hands you the list and you send the declines.

An approval step would not fix that, which is the second reason. Approval in Aestus covers a run, not a change, so one click would authorise six calendar edits that the person clicking had seen only as a summary sentence. That is the kind of approval people learn to click without reading, which is worse than no approval at all. A per-change decision already exists and it is the checklist on the ticket.

What it does instead is compute. Every claim in the review is arithmetic over the week it read: the overlap between two meetings in minutes, the gap between each pair in a run, the longest free block in the middle of the day, the number of attendees, the total hours booked, and the minutes each proposed change would give back. None of those is a number a model arrived at. Where a figure cannot be recomputed from the calendar it came from, the review step sends it back once and then fails the run rather than publishing it — because a figure that looks right and has no source is the most expensive thing this document could contain, and you would repeat it to somebody.

It is equally careful about what it will not say. A meeting you already declined is invisible to it: you dealt with that one, and counting it as busy time would manufacture clashes that do not exist. A day outside your working days is not reviewed at all, because a full Saturday is a choice and not a defect. A meeting you listed as protected stays busy — the point of protecting one is that everything else moves around it — but it is never the thing proposed for a change, and a review that proposes one fails before you see it. And there is no class of finding that means "this looks unnecessary". Every finding is a fact about a record.

The step that reads your calendar holds nothing else. Event titles, agendas and organizer names are text people outside your organization wrote, so the step that reads them has no access to your workspace at all, and the step that turns them into sentences holds no tools. Neither half has both, which means an instruction typed into a meeting invite has nothing to reach for: the worst it can do is make one review wrong, and that is what the review step and the citations are for.

Then it ends in work rather than prose. The review is a document, and one ticket for the week carries the changes as a checklist — one line per change, with the meeting, the minutes it frees and the person to ask. Run it again the same week and it updates that ticket instead of filing a second one. When the week is fixed you move the ticket, which is also how Aestus records that the review was worth producing.

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

Calendar review — week of Mon 14 Sep 2026

Produced by: Run EXAMPLE-CC-01 · calendar read-only · document artifact · demo values

Conflicts: Every overlap, measured. "Pricing review" 10:00–10:30 overlaps "Support escalation sync" 10:15–11:00 by 15 minutes. The one named for a change is the one you are least committed to — here you are an optional attendee, so the change is to decline it rather than to move the meeting you called. A meeting you had already declined is invisible to all of this: it is not a clash and it is not busy time.
Back-to-backs without a break: Wed 10:00–14:30 runs 5 meetings over 270 minutes with gaps of 0, 0, 0, 0 minutes. The meeting proposed for shortening is the longest one in the run that you own, so the change needs nobody else's agreement. "Board prep" sits in the middle of this run and is never proposed for anything — you listed it as protected — but it still counts as busy, which is why the run around it is named.
Meetings with no work behind them: "Growth brainstorm" has 9 attendees and no agenda, and Dana organizes it. Not "this looks unnecessary" — there is no such finding. An empty agenda and no open ticket, plan or goal matching the subject are both facts about records, and the review says which check it ran so you can disagree with it.
Recurring meetings gone stale: "Mobile release sync" recurs weekly on Tue and its linked work LIORHEBE-1788 is closed. That is the whole argument for dropping a series, and it is a ticket id rather than a feeling. Because you do not organize this one, the change is to reduce its frequency and the ask is addressed to the person who does.
After-hours and no-break days: Thu has no free block of 90 minutes inside 09:00–18:00; the longest is 60 minutes. Days outside your working days are not reviewed at all — a full Saturday is a choice, not a defect — and an evening meeting is named only when somebody else called it.
Waiting on you: The 3 changes of the 8 that need somebody else to agree, each phrased as the message to send and naming the person. A change you can make on your own is deliberately not here: this section is the part that costs you a conversation.
What the changes give back: Three columns — the change, the meeting, the time it frees — totalling 210 minutes across 8 changes. A change that frees nothing reads "none — removes a clash" rather than "0m", and an agenda is one of those: it makes a meeting worth attending, it does not give the half hour back. Aestus sends none of these; you do.
Sources: 10 numbered lines, one per calendar event or ticket the review leaned on, so every "[n]" above resolves to something you can open. A finding whose number cannot be recomputed from these rows is sent back once and then fails the run.

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 reads next week, read-only
Titles, times, attendee counts, agendas, recurrence and whether you accepted. No attendee email addresses, no join links, and no more than a short excerpt of any agenda — the shape the calendar arrives in has no field for them, so there is nothing to leak even if a meeting invite asks for one.
02It checks the work behind each meeting
Aestus already holds your tickets, plans and goals. A meeting whose agenda is empty and whose subject matches no open work gets named as such, and the review says which check it ran so you can disagree with it.
03It names one change per defect
Decline, move, shorten, make it async, reduce the frequency, cancel the series, ask for an agenda, or protect a block. One change per finding, with the minutes it frees and the person who has to agree.
04It checks its own arithmetic
A review step recomputes every number against the week it came from: overlap minutes, gaps, free blocks, attendee counts, the total time given back. A figure that cannot be recomputed sends the review back once, then fails the run rather than publishing a guess.
05It files the review and the checklist
A document you can read and share, and one ticket for the week with the changes as a checklist. A second run in the same week updates that ticket rather than filing another.

By hand, and on Aestus

The same job, on either side.

By hand
Scroll next week on Friday and hope you spot the clashes.
On Aestus
Every overlap listed with the exact minutes, and which of the two you are optional on.
By hand
You notice the five-meeting morning while you are living it.
On Aestus
Named on Friday, with each gap in minutes and which meeting to shorten.
By hand
You guess whether a meeting still matters.
On Aestus
Checked against your open tickets, plans and goals, with the check it ran written down.
By hand
Recurring meetings outlive the work that created them.
On Aestus
The closed anchor ticket is cited by id, and the change is reduce to monthly or cancel the series.
By hand
Decisions live in your head until you forget them.
On Aestus
One ticket a week with the changes as a checklist, on the board your work is already on.
By hand
A scheduling assistant moves your meetings for you.
On Aestus
Aestus never changes your calendar. It hands you the list; you send the declines.

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 a failure code if it fails, on the same ledger as every other run in the workspace.
The document
A document artifact with revision zero, every claim carrying the calendar event or ticket it came from.
The ticket
One per week, updated rather than duplicated. Moving it to a done column is how the run is recorded as accepted.
The rule you keep
When a cleanup ticket says in writing that a meeting is protected, Aestus can propose that as a workspace constraint, cited to your ticket, for a person to approve.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

google-calendarRequired

Questions teams ask

Will it change my calendar?

No. The step that reads your calendar declares read-only intent, and a calendar write is refused at execution whenever the workflow has no approval step in front of it — this one has none at all, so a write refuses however it is reached. Nothing in it asks for one.

Why does it not just decline the meetings for me?

Because a wrong decline cannot be undone, and it is felt by the person who called the meeting. An approval step covers a whole run, not each change, so one click would authorise six calendar edits somebody had seen only as a summary. A list costs you ten minutes and no risk.

How does it know a meeting has no work behind it?

It reads your open tickets, plans and goals and looks for the meeting's subject among them, and it reports that check rather than asserting a conclusion. An empty agenda plus no matching work is what it names; it never claims a meeting is unimportant.

What about meetings I will never drop?

List them when you turn it on. A protected meeting is still counted as busy time, so its neighbours are judged around it, but it is never proposed for a change and the review step fails if one appears.

Does it work with Outlook?

Not yet. Google Calendar only.

All use cases How access is governed

Sources

content/integrations/google-calendar.md

Hand over Clean up your calendar.

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

Talk to us

Calendar review — week of Mon 14 Sep 2026

Produced by: Run EXAMPLE-CC-01 · calendar read-only · document artifact · demo values

Conflicts: Every overlap, measured. "Pricing review" 10:00–10:30 overlaps "Support escalation sync" 10:15–11:00 by 15 minutes. The one named for a change is the one you are least committed to — here you are an optional attendee, so the change is to decline it rather than to move the meeting you called. A meeting you had already declined is invisible to all of this: it is not a clash and it is not busy time.
Back-to-backs without a break: Wed 10:00–14:30 runs 5 meetings over 270 minutes with gaps of 0, 0, 0, 0 minutes. The meeting proposed for shortening is the longest one in the run that you own, so the change needs nobody else's agreement. "Board prep" sits in the middle of this run and is never proposed for anything — you listed it as protected — but it still counts as busy, which is why the run around it is named.
Meetings with no work behind them: "Growth brainstorm" has 9 attendees and no agenda, and Dana organizes it. Not "this looks unnecessary" — there is no such finding. An empty agenda and no open ticket, plan or goal matching the subject are both facts about records, and the review says which check it ran so you can disagree with it.
Recurring meetings gone stale: "Mobile release sync" recurs weekly on Tue and its linked work LIORHEBE-1788 is closed. That is the whole argument for dropping a series, and it is a ticket id rather than a feeling. Because you do not organize this one, the change is to reduce its frequency and the ask is addressed to the person who does.
After-hours and no-break days: Thu has no free block of 90 minutes inside 09:00–18:00; the longest is 60 minutes. Days outside your working days are not reviewed at all — a full Saturday is a choice, not a defect — and an evening meeting is named only when somebody else called it.
Waiting on you: The 3 changes of the 8 that need somebody else to agree, each phrased as the message to send and naming the person. A change you can make on your own is deliberately not here: this section is the part that costs you a conversation.
What the changes give back: Three columns — the change, the meeting, the time it frees — totalling 210 minutes across 8 changes. A change that frees nothing reads "none — removes a clash" rather than "0m", and an agenda is one of those: it makes a meeting worth attending, it does not give the half hour back. Aestus sends none of these; you do.
Sources: 10 numbered lines, one per calendar event or ticket the review leaned on, so every "[n]" above resolves to something you can open. A finding whose number cannot be recomputed from these rows is sent back once and then fails the run.

Questions teams ask

Will it change my calendar?

Why does it not just decline the meetings for me?

How does it know a meeting has no work behind it?

What about meetings I will never drop?

Does it work with Outlook?

Not yet. Google Calendar only.

Sources

content/integrations/google-calendar.md

Six changes that would fix next week

Clean up your calendar

What you get

Calendar review — week of Mon 14 Sep 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

The ticket

The rule you keep

What it connects to

Questions teams ask

Other use cases

Hand over Clean up your calendar.

Six changes that would fix next week

Clean up your calendar

What you get

Calendar review — week of Mon 14 Sep 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

The ticket

The rule you keep

What it connects to

Questions teams ask

Other use cases

Hand over Clean up your calendar.