Everyday productivity

The meeting is over when the work is on the board

Forward the recap. Aestus files the action items with the sentence each came from, records the decisions and proposes the next check-in.

Join the waitlist See what it produces

After the meeting

Close the loop on a meeting

Who it is for: Anyone who runs recurring meetings and writes up the follow-through afterwards.
What starts it: Forward the meeting recap to your workspace address. One meeting, one run.; On an inbound message

Turn it on in Aestus

A meeting ends and four things are owed: the action items nobody filed, the decisions nobody wrote down, a follow-up nobody sent, and a next check-in nobody booked. A notetaker solves none of them. It writes you a list, and somebody still has to open the board and re-type it — which is why the list is usually still a list a week later.

So this starts where the list stops. You forward the recap your notetaker already sends, and the work in it goes on the board: a ticket per commitment, each carrying the verbatim sentence that created it, so anybody can check that it was really said. An owner only where a name was actually said. A due date only where a date was actually said. Where the meeting said one thing waits on another, the two tickets are linked in that direction and nowhere else.

The part that matters most is what it refuses to do. It reads your board before it files anything, so a promise repeated in three meetings is named once and filed once. A commitment it is not sure about — two open tickets might already be it, or nobody agreed to anything — is not filed at all; it is listed for you with the reason. And the record ends with what was deliberately left out: the small talk, the number said but not agreed, the status report that was not a commitment. That section is what makes the rest believable.

Aestus is not in the room. There is no recorder, it joins no call, and there is nothing to turn on in your meeting software. The whole input is the message you forwarded, plus a notes document when that message links to one. That is a real limit and it decides the honest answer to the case that matters: a meeting that left no record at all produces no close-out, and a meeting that left a record but settled nothing produces a record that says so in one line. Neither is filled in with a plausible summary — the check that runs before anything is written refuses a quote that is not in the source it names, so an invented commitment cannot reach your board.

Nothing leaves your workspace on its own. The follow-up waits at an approval step with the draft and the recipients in front of you, and with no recipients configured it is never sent. The next check-in waits at its own: you see the date, the length, the purpose and the people, and you book it or skip it. It can create one new event on your primary calendar; it cannot edit or delete one you already have. Declining either still writes the record and still leaves the tickets on the board — the work is not thrown away because you said no to an email.

The step that can create a ticket holds no mailbox, no channel and no calendar. That is not a policy, it is the shape of the thing: a line typed into a transcript by anybody who learns your workspace address has no way out of Aestus from the one step that writes to your board. And a ticket owned by a team you are not on is never read at all — the record counts how many were withheld, so a short list can be told apart from a broken one.

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

Close-out — Northwind renewal sync

Produced by: Run DEMO-RUN-8812 · document artifact on the meeting log · demo values

Decisions: 3 settled agreements, each with the sentence that settled it — "we're agreed: 24 months, price held" for "The renewal moved to a 24-month term at the current unit price.". A proposal, a preference or an option still under discussion is refused here, because a proposal recorded as a decision is the one that outlives the meeting and gets quoted as settled six weeks later.
Filed: A table of the tickets this run created, with the real short ids the board gave them. DEMO-118 carries the owner Priya Raman and the date 2026-09-15, both because the meeting said them out loud; the third row shows an em dash where no date was said rather than a guess. Below it, the dependency the meeting stated: DEMO-119 depends on DEMO-120.
Merged into existing work: The board was read before anything was filed, so "Update the Northwind account plan" became a line here rather than a twin of DEMO-84. Added the due date 2026-09-19; nothing else on that ticket changed. A commitment an already-finished ticket covers is named too, and nothing is created for it.
Held for you: 2 commitments this run refused to file, each with its reason in one line — "Get an answer on the EU data question before signing" is here because no owner was named and no action was agreed. This is the section that proves the run was uncertain somewhere; a record without one reads exactly like a run that was sure about everything.
Open questions: What was asked and not answered, with who it was asked of and the sentence it came from: "Tom: I'll have to check who signs on our side.". A question is not an action item, so it never becomes a ticket.
Next check-in: The event, once a person approved it: the date, the length, who was invited and who was left out because no address was given. Choosing Skip instead renders one line saying so, and the calendar is untouched. It can create one new event; it can never edit or delete one you already have.
Follow-up: The draft's subject and audience — never its body, because the record is shared more widely than a message addressed to a customer. With no recipients configured, the record says so and nothing is sent.
Not captured: 3 lines saying what was deliberately left out and why: small talk, a price said aloud but not agreed, a status report that was not a commitment. This is the section that makes the other eight believable. A meeting that created no work gets the whole record anyway, opening with "Nothing to close — what was forwarded records no decision and no commitment.".
Sources: Every [n] marker above resolves to a line here, and a marker that resolves to nothing stops the record being written at all. 1 open ticket on a team you cannot see was not read, so it could not be matched.

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 what you forwarded, and only that
Aestus joins no call and records nothing. The input is the recap your notetaker already wrote, forwarded to your workspace address — plus, when that message links to one, up to three notes documents in Drive. The step that reads it holds no access to your board, so a line typed into a transcript has nothing here to reach for.
02It turns the text into a record, quote by quote
Decisions, action items, open questions, a proposed check-in and a follow-up draft. Every item carries a verbatim sentence from the source it came from. An owner only where a name was said; a date only where a date was said.
03A check runs before anything is written
A paraphrased quote, a due date nothing supports, or a proposal dressed up as a decision is sent back once. On the second failure the run stops and files nothing. The check sits ahead of every write, so a failed judgement can never file the same ticket twice.
04It reads your board, then files
A new commitment becomes a ticket carrying its quote. One an open ticket already covers is named, not repeated. One that only needs a date gets the date and nothing else changes. Anything uncertain is held for you with its reason. Where the meeting said one thing waits on another, the two tickets are linked in that direction.
05Two decisions are yours
The next check-in: you see the date, the length, the purpose and the invitees, and you book it or skip it. The follow-up: you see the draft and the recipients before it sends. Neither happens on its own, and declining either still saves the record.
06It writes one record
A close-out document on your meeting log: what was decided, what was filed, what was merged, what was held, what was asked, and what it deliberately left out. The tickets it filed carry the run, so a wrong capture is traceable to the sentence that caused it.

By hand, and on Aestus

The same job, on either side.

By hand
A list at the bottom of the notes; someone re-types it later, or nobody does.
On Aestus
Tickets on the board, each carrying the sentence that created it.
By hand
The same promise from three meetings becomes three tickets, or none.
On Aestus
The board is read first; work already covered is named, not filed again.
By hand
Owners and dates guessed, or left blank.
On Aestus
Set only where a name or a date was actually said; otherwise held for you.
By hand
Decisions in the notes, and nowhere you would look in a month.
On Aestus
Written into the record with the quote, and proposed to workspace memory.
By hand
The follow-up written from memory, an hour or a day later.
On Aestus
Drafted from the record and sent only after you approve it.
By hand
The next check-in booked when somebody remembers.
On Aestus
Proposed with date, length and invitees; booked only when you approve.
By hand
No way to tell a quiet meeting from a run that went wrong.
On Aestus
A meeting that created no work says so in one line, and files nothing.

What Aestus records

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

The run
Cost in dollars, tokens, duration and whether the check passed, on the same ledger as every other run in the workspace.
The close-out record
A document on your meeting log with a revision history, listing what was filed, what was merged, what was held and why, and what was left out.
What it could not see
A ticket owned by a team you are not on is never read, and the record states how many were withheld — so a duplicate filed against invisible work is explainable rather than mysterious.

What it connects to

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

Questions teams ask

Does Aestus record my meetings?

No. It has no recorder and does not join calls. You forward the recap your notetaker already writes, or paste the notes into a run.

What if no owner was named?

The ticket is filed unassigned and the record says no name was said. Aestus does not resolve “we”, “they” or “someone” to a person.

What if the same promise comes up every week?

The board is read before anything is filed. Work an open ticket already covers is named in the record, not filed again, and a re-forwarded recap is one run rather than two.

Will it email my customer without asking?

No. The follow-up waits at an approval step with the draft and the recipients in front of you. With no recipients configured it is never sent at all.

Can it change a meeting already on my calendar?

No. After you approve, it can create one new event on your primary calendar. It cannot edit, move or delete an event you already have.

All use cases How access is governed

Sources

docs/runbooks/use-case-workflows.md
content/integrations/google-calendar.md
content/integrations/gmail.md

Hand over Close the loop on a meeting.

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

Talk to us

Close-out — Northwind renewal sync

Produced by: Run DEMO-RUN-8812 · document artifact on the meeting log · demo values

Decisions: 3 settled agreements, each with the sentence that settled it — "we're agreed: 24 months, price held" for "The renewal moved to a 24-month term at the current unit price.". A proposal, a preference or an option still under discussion is refused here, because a proposal recorded as a decision is the one that outlives the meeting and gets quoted as settled six weeks later.
Filed: A table of the tickets this run created, with the real short ids the board gave them. DEMO-118 carries the owner Priya Raman and the date 2026-09-15, both because the meeting said them out loud; the third row shows an em dash where no date was said rather than a guess. Below it, the dependency the meeting stated: DEMO-119 depends on DEMO-120.
Merged into existing work: The board was read before anything was filed, so "Update the Northwind account plan" became a line here rather than a twin of DEMO-84. Added the due date 2026-09-19; nothing else on that ticket changed. A commitment an already-finished ticket covers is named too, and nothing is created for it.
Held for you: 2 commitments this run refused to file, each with its reason in one line — "Get an answer on the EU data question before signing" is here because no owner was named and no action was agreed. This is the section that proves the run was uncertain somewhere; a record without one reads exactly like a run that was sure about everything.
Open questions: What was asked and not answered, with who it was asked of and the sentence it came from: "Tom: I'll have to check who signs on our side.". A question is not an action item, so it never becomes a ticket.
Next check-in: The event, once a person approved it: the date, the length, who was invited and who was left out because no address was given. Choosing Skip instead renders one line saying so, and the calendar is untouched. It can create one new event; it can never edit or delete one you already have.
Follow-up: The draft's subject and audience — never its body, because the record is shared more widely than a message addressed to a customer. With no recipients configured, the record says so and nothing is sent.
Not captured: 3 lines saying what was deliberately left out and why: small talk, a price said aloud but not agreed, a status report that was not a commitment. This is the section that makes the other eight believable. A meeting that created no work gets the whole record anyway, opening with "Nothing to close — what was forwarded records no decision and no commitment.".
Sources: Every [n] marker above resolves to a line here, and a marker that resolves to nothing stops the record being written at all. 1 open ticket on a team you cannot see was not read, so it could not be matched.

Questions teams ask

Does Aestus record my meetings?

No. It has no recorder and does not join calls. You forward the recap your notetaker already writes, or paste the notes into a run.

What if no owner was named?

The ticket is filed unassigned and the record says no name was said. Aestus does not resolve “we”, “they” or “someone” to a person.

What if the same promise comes up every week?

The board is read before anything is filed. Work an open ticket already covers is named in the record, not filed again, and a re-forwarded recap is one run rather than two.

Will it email my customer without asking?

No. The follow-up waits at an approval step with the draft and the recipients in front of you. With no recipients configured it is never sent at all.

Can it change a meeting already on my calendar?

No. After you approve, it can create one new event on your primary calendar. It cannot edit, move or delete an event you already have.

Sources

docs/runbooks/use-case-workflows.md

content/integrations/google-calendar.md

content/integrations/gmail.md

The meeting is over when the work is on the board

Close the loop on a meeting

What you get

Close-out — Northwind renewal sync

How it runs

By hand, and on Aestus

What Aestus records

The run

The close-out record

What it could not see

What it connects to

Questions teams ask

Other use cases

Hand over Close the loop on a meeting.

The meeting is over when the work is on the board

Close the loop on a meeting

What you get

Close-out — Northwind renewal sync

How it runs

By hand, and on Aestus

What Aestus records

The run

The close-out record

What it could not see

What it connects to

Questions teams ask

Other use cases

Hand over Close the loop on a meeting.