Everyday productivity

Their first month, written from your workspace

A 30-day plan built from the board as it stands: who to ask about what, the work already assigned to them, and the decisions already settled.

Join the waitlist See what it produces

Someone joins

Onboard a new teammate

Who it is for: Managers who write a 30-60-90 by hand, and know theirs was written for the last person.
What starts it: On demand, from the automations catalog, once you name the person who has joined; On demand

Coming soonOnboard a new teammate is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

Every onboarding document in every company is written for the last person who joined. It was accurate for about a fortnight. The owners in it have moved, half the decisions it explains were reopened and settled differently, and the "good first ticket" it names shipped in March. Everybody reading it knows this, which is why nobody trusts a line of it and everybody asks a colleague instead.

This writes the plan from the board as it stands on the morning somebody arrives. Who holds the most open work in each area, and the tickets that count came from. What is already assigned to the new person, because somebody made that commitment on their behalf before they got here. What is open and unassigned on their own team, so there is somewhere to start that is an offer rather than an interruption. And what this workspace has already settled — the approved decisions, constraints, procedures and known pitfalls — so week two is not spent reopening a question somebody answered in August.

It does not contain a list of every project. That is the thing a stale handbook already does badly, and it is noise on day one. It does not contain an org chart either: Aestus does not record who reports to whom, so the honest answer to "who do I ask about payments" is "the person holding the most open payments work right now", stated as exactly that and cited. A plan that implied seniority it had not read would send a new person to the wrong colleague with confidence.

The part that took the most care is who the document is allowed to describe. Every other thing Aestus writes asks what an established reader may see. This one hands a document to somebody who arrived this morning — the person in the workspace with the least ability to notice a row they should not have — and it is set up by somebody else, whose teams are not theirs. So the plan holds what both of them can see: the board is read under the visibility of whoever asked for it, then narrowed again to the new joiner's own team membership. A ticket or a recorded decision on a team they have not joined is dropped entirely, never redacted and never shown with a placeholder, and the number of dropped rows is printed in the document. Get that backwards and onboarding becomes a way to disclose work through the one reader who cannot tell.

Every number in it is computed from rows before a model is asked to write anything, and the opening sentence is composed in code and copied across verbatim — a plan whose headline was rephrased is rejected rather than published. Each line carries the record it came from. A ticket id, a person or a figure that appears in no record fails the review step, and so does a line of advice: the plan reports what is written down and does not tell anybody how to succeed, what to prioritise, or how long anything should take.

Then it nearly stops. It assigns nothing and sends nothing to a channel. The one ticket it writes is a single onboarding ticket for that person, created under a key held in the database, so running it again in week three produces a new version of the same document rather than a second ticket and a second plan.

The one thing it offers to do in the world is book the conversations it named. A plan that says "talk to Amira about checkout" is still a task somebody has to remember, so after the document is filed the run asks once — how many holds, for whom, how long, and who would be invited — and you approve it or you do not. It can only create new events on your primary calendar, never edit or cancel one you already have, and the addresses it invites come from your own setting rather than from anything it read, so the worst a line typed into a ticket can do is get a meeting booked with the wrong title. Decline and the plan is filed exactly the same. Connect no calendar at all and the step has nothing to do, which is the state most workspaces start in.

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

Your first 30 days — Dana Ruiz · 2 people to meet · 1 already assigned to you · 1 you could pick up · 2 decisions already made · 2 not visible to you

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

Your first week: 4 items, and CORE-12 is first because somebody assigned it to this person before they arrived. Every line says which of three things put it there — work already assigned to you, somebody who owns the area, or open work on your own team — so a person on their first morning is never left to work out why something is in front of them.
Who to ask about what: 2 people, each named beside the area they hold the most open work in: Amira Haddad on Checkout reliability, counted from 2 open tickets and citing CORE-35, CORE-36. It is a fact about the board, not an org chart — Aestus records no reporting lines, so the plan claims none.
Waiting for you already: 1 ticket was assigned to this person before day one: CORE-12, in In Progress. It is first in the plan because it is the only thing in it they can already be held to.
Where you could start: 1 open ticket on their own team that nobody is holding: CORE-34. Nothing is assigned by this run — it is an offer, and a ticket somebody else already owns is an interruption rather than a place to start, so it is never listed here.
Decided before you arrived: 2 approved claims from Workspace Memory, so week two is not spent reopening them: "Retries go through the shared queue rather than an in-process timer", recorded with the record it came from. Candidate claims are never used, and with Workspace Memory switched off this section is empty rather than reconstructed from ticket titles.
How this workspace works: 1 recorded procedures and known pitfalls: "A payments change ships behind the billing flag and is enabled the next morning". The plan reports what is written down and gives no advice — a line telling somebody how to succeed is rejected before the document is written.
Left out: 2 rows were owned by a team this person is not a member of, so they were dropped entirely and counted here rather than shown without their team. This section also states that the plan holds only what the person who set it up can see too, and that no mail, chat, calendar or HR system was read.
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 ticket id this run did not read fails the review even when the ticket is real.

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

01You name the person who joined
Everything after this is judged against their team membership, not yours. That one choice is what stops an onboarding document becoming a way to read work somebody has no business seeing.
02It reads the board twice over
Once as you, so a plan you are about to review cannot name a team you are not on either, and then again as them, so a ticket on a team they have not joined is dropped entirely and counted rather than shown.
03It works out the plan in code
Who holds the most open work in each area, what is already assigned to the new person, what is open and unassigned on their own teams, and which decisions and conventions this workspace has actually approved. Every count is computed before a model sees anything.
04It checks itself four times before anybody reads it
Four separate checks read the draft: did every value come from a record, can every statement be opened, is anybody named or advised who should not be, and does the document have the shape and carry nothing it must not. Each one gets its own repair attempt aimed at its own fault, so a plan with two problems is told about both. Two failures at any check and the run fails rather than publish.
05It files the plan, and offers to book the first conversations
The document lands on one onboarding ticket for that person, posted on that ticket and saved as one document with a revision history, and you are notified. Then it asks once whether to put a hold on your calendar for each person the plan named to meet. You approve or decline every time; declining changes nothing else. No ticket is assigned, no message is sent to a channel, and running it again writes a new version of the same document.

By hand, and on Aestus

The same job, on either side.

By hand
Copy the last hire's document and change the name.
On Aestus
Written from this week's board, the morning they arrive.
By hand
Owners come from memory, or from a page nobody has edited since March.
On Aestus
Named from who actually holds the open work in each area, with the tickets the count came from.
By hand
"Ask somebody about how we deploy."
On Aestus
The decision and the convention themselves, each with the record it was approved from.
By hand
The first ticket gets picked in week two, if at all.
On Aestus
Open, unassigned work on their own team, named on day one and assigned to nobody.
By hand
Nobody can tell whether a line is still true.
On Aestus
Every line links to its record, so you can check — and so can they.
By hand
A handbook shows a new person whatever it happens to contain.
On Aestus
It holds only what that person may see. Anything on a team they are not on is counted in a number the document states.
By hand
"Go and introduce yourself to a few people."
On Aestus
One hold per named person, in their first week, after you approve it.

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 plan
A document artifact on that person's onboarding ticket, with revision history — so a plan rebuilt in week three sits beside the one from day one.
What it withheld
The run records who the plan was about, who asked for it, and how many rows were dropped because the new joiner is not on the owning team.
The calendar decision
Whether you approved the check-ins, and what was created if you did. Nothing reaches a calendar without that decision on the record.

What it connects to

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

google-calendarOptional

Questions teams ask

Can it show a new person work they should not see?

No. The plan is built against their own team membership, not against the membership of whoever set it up. A ticket or a recorded decision owned by a team they are not on is dropped entirely — never redacted, never shown with a placeholder — and counted in a number the document prints under "Left out".

Can I see everything it wrote?

Yes, and the plan holds nothing you cannot see either. The board is read under your visibility first, so a document you are about to hand somebody can never name a team you are not on yourself.

Does it assign work or book meetings on its own?

It assigns nothing, ever: it names tickets that already exist and says which are already assigned to the new person. It books nothing on its own either. After the plan is filed it asks once, showing how many holds, for whom, how long and who would be invited, and you approve or decline. It can only create new events on your primary calendar, never edit, move or delete one you already have, and whom it invites comes from your own setting rather than from anything the plan read. With no calendar connected the step does nothing and the plan is identical.

What happens if I run it twice?

You get a new version of the same document on the same ticket. The ticket is created under a key held in the database, so a second run cannot produce a second ticket.

Where do the decisions and conventions come from?

Approved claims in Workspace Memory, each with the record it was recorded from. Candidate claims are never used. If Workspace Memory is off, those sections are empty rather than guessed at from ticket titles.

All use cases How access is governed

Sources

content/integrations/google-calendar.md

Hand over Onboard a new teammate.

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

Talk to us

Onboard a new teammate

Who it is for

Managers who write a 30-60-90 by hand, and know theirs was written for the last person.

What starts it

On demand, from the automations catalog, once you name the person who has joined

On demand

Coming soonOnboard a new teammate is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

Your first 30 days — Dana Ruiz · 2 people to meet · 1 already assigned to you · 1 you could pick up · 2 decisions already made · 2 not visible to you

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

Your first week: 4 items, and CORE-12 is first because somebody assigned it to this person before they arrived. Every line says which of three things put it there — work already assigned to you, somebody who owns the area, or open work on your own team — so a person on their first morning is never left to work out why something is in front of them.
Who to ask about what: 2 people, each named beside the area they hold the most open work in: Amira Haddad on Checkout reliability, counted from 2 open tickets and citing CORE-35, CORE-36. It is a fact about the board, not an org chart — Aestus records no reporting lines, so the plan claims none.
Waiting for you already: 1 ticket was assigned to this person before day one: CORE-12, in In Progress. It is first in the plan because it is the only thing in it they can already be held to.
Where you could start: 1 open ticket on their own team that nobody is holding: CORE-34. Nothing is assigned by this run — it is an offer, and a ticket somebody else already owns is an interruption rather than a place to start, so it is never listed here.
Decided before you arrived: 2 approved claims from Workspace Memory, so week two is not spent reopening them: "Retries go through the shared queue rather than an in-process timer", recorded with the record it came from. Candidate claims are never used, and with Workspace Memory switched off this section is empty rather than reconstructed from ticket titles.
How this workspace works: 1 recorded procedures and known pitfalls: "A payments change ships behind the billing flag and is enabled the next morning". The plan reports what is written down and gives no advice — a line telling somebody how to succeed is rejected before the document is written.
Left out: 2 rows were owned by a team this person is not a member of, so they were dropped entirely and counted here rather than shown without their team. This section also states that the plan holds only what the person who set it up can see too, and that no mail, chat, calendar or HR system was read.
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 ticket id this run did not read fails the review even when the ticket is real.

Questions teams ask

Can it show a new person work they should not see?

Can I see everything it wrote?

Yes, and the plan holds nothing you cannot see either. The board is read under your visibility first, so a document you are about to hand somebody can never name a team you are not on yourself.

Does it assign work or book meetings on its own?

What happens if I run it twice?

You get a new version of the same document on the same ticket. The ticket is created under a key held in the database, so a second run cannot produce a second ticket.

Where do the decisions and conventions come from?

Sources

content/integrations/google-calendar.md

Their first month, written from your workspace

Onboard a new teammate

What you get

Your first 30 days — Dana Ruiz · 2 people to meet · 1 already assigned to you · 1 you could pick up · 2 decisions already made · 2 not visible to you

How it runs

By hand, and on Aestus

What Aestus records

The run

The plan

What it withheld

The calendar decision

What it connects to

Questions teams ask

Other use cases

Hand over Onboard a new teammate.

Their first month, written from your workspace

Onboard a new teammate

What you get

Your first 30 days — Dana Ruiz · 2 people to meet · 1 already assigned to you · 1 you could pick up · 2 decisions already made · 2 not visible to you

How it runs

By hand, and on Aestus

What Aestus records

The run

The plan

What it withheld

The calendar decision

What it connects to

Questions teams ask

Other use cases

Hand over Onboard a new teammate.