Calendar and scheduling

Read the calendar without being able to move it

Aestus reads events, attendees and free time through read-only scopes; creating or changing an event needs a separate scope, a saved policy and a person.

Join the waitlist See the Google Calendar example

Google Calendar with Aestus

Keep the tool. Change what the team can see.

Most of what a team wants from its calendar is answers, not changes. What is tomorrow about, who is coming, what did we last decide with them, when is everyone free. Every one of those is a read, and Aestus asks for read-only scopes to get them: the calendar list, the events, and free/busy. A connection granted that way cannot move a meeting even if a run decided it wanted to.

Changing the day is a different grant. The events write scope is requested separately, a saved write policy has to exist, and only then does a workflow see a tool that can create or patch an event. Adding attendees is split off again, because putting a name on an invitation reaches a person in a way that editing a title does not.

That split is what makes the read path quiet. A briefing that runs at half past seven every weekday holds nobody up and asks nobody for permission, and the day it starts booking things for you is the day somebody had to agree to it in writing.

Good first workflows

Prepare for tomorrow
Turn each external meeting into a short brief built from the work the attendees already have open.
Find a slot people will accept
Read free/busy across the team and propose times, leaving the invitation for a person to send.
Book only with a named approval
Creating or changing an event needs the write scope and a saved policy; inviting people needs its own decision.

A complete Google Calendar example, from trigger to proof.

The example names the people, task event, tool boundary, returned evidence, and acceptance state. The run row below it is a fixed product example, not customer data.

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

Inside the connected tool

What the calendar connection can and cannot do

The read-only scopes answer questions about the day. Creating an event, or inviting somebody to one, is held for a named person.

calendar@meridian.example · connectedRead-only scopes

Runs without an approval

List the calendars this account can see
Read tomorrow's events and attendees
Read free/busy across the team

Held for a named person

Create or change an event
Add attendees to an invitation

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

Concrete workflow example

Walk into the 9:00 review knowing what changed

A scheduled workflow reads tomorrow's agenda, writes one brief per external meeting, and touches nothing on the calendar itself.

TriggerEvery weekday at 07:30 in the workspace time zone

1
Aestus workflow
Reads the day's events with read-only tools
Free/busy, the event list and one event's detail. No write scope is requested for this path.
3 read tools · 0 write scopes
2
Aestus workflow
Matches each attendee domain to work already in the workspace
Open tickets, recent runs and the last decision, counted by code rather than guessed by the model.
4 meetings · 11 linked items
3
Aestus workflow
Writes one brief per meeting as a document
Every line cites the event or ticket it came from, and says plainly what it could not read.
EXAMPLE-GC-01 · 4 briefs
4
Dana · Account lead
Opens the brief beside the invitation
Nothing was booked, moved or declined; the calendar is unchanged by the run.
read-only · no approval needed

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

Illustrative product example — not a production run

Brief the 9:00 customer review

Example run		Runtime	Outcome
EXAMPLE-GC-01	Aestus workflow	aestus	Completed	$0.0164	21.0s

Tokens in / out: 6,200 / 480
Failure code: —
Agent: —

Illustrative Aestus workflow; actual costs and results vary

Example run cost

$0.0164 in the illustrative product example

A fixed example that stands for one scheduled briefing run of 6,200 input tokens, not a measurement of your calendar. Reading the day is part of that run.

Set it up in four steps.

Follow the real Google Calendar connection path. Provider steps link to the provider documentation. Aestus steps name the contract they follow.

01
Connect the calendar account
An organization admin opens Settings, Integrations and connects the Google Calendar account this organization owns. The connection belongs to the organization, not to whoever set it up.
Read the provider docs
02
Approve only the read scopes first
Google shows the access being requested. Reading needs the calendar list, event and free/busy read-only scopes; nothing in that set can alter a calendar.
Read the provider docs
03
Confirm the primary calendar
An admin verifies which calendar the organization means before any workflow points at it, so a run cannot quietly read the wrong one.
Read the provider docs
04
Turn on a workflow that uses it
Enable the use case from the catalog. A read-only calendar workflow starts producing briefs without any further grant.
Aestus product guide

The boundary stays visible while the work moves.

See what Google Calendar can do, where a person still decides, and what Aestus records for every governed run.

Where control lives

Reading is not a decision

A read-only calendar step runs with no gate in front of it. An approval on every read would train people to click through the ones that matter.

Writing needs the scope and a policy

Creating or changing an event requires the events scope and a saved write policy. Without both, Aestus does not offer the tool to the run at all.

Inviting people is separated out

Adding attendees to an event is its own decision, apart from changing the event, because the two reach different people.

What Aestus records

Which calendar answered

The connected account and the calendar that was read stay on the run, so a surprising brief can be traced to its source.

What the run could not see

A calendar that exposes only free/busy gives only free/busy, and the brief says which meetings it could not describe.

Run economics

Tokens, latency, cost and any failure code stay on the run row. Reading a calendar is part of that run, not a second bill.

Questions teams ask

Can Aestus move or cancel my meetings?

Not through a read-only connection. Moving, creating or cancelling an event needs the events write scope and a saved policy, and it stays a separate step from reading.

Does it see what is inside a private event?

It sees what the connected account can see. Where a calendar shares only free/busy, that is all the run gets, and the output says so rather than guessing.

Do we have to approve the morning brief every day?

No. A briefing workflow only reads, so there is nothing to hold and nobody to interrupt.

See all integrations See the security controls

Start with one Google Calendar run.

Bring one real run. Map its actors, boundary, evidence, cost, and acceptance step.

Talk to us

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

Concrete workflow example

Walk into the 9:00 review knowing what changed

A scheduled workflow reads tomorrow's agenda, writes one brief per external meeting, and touches nothing on the calendar itself.

TriggerEvery weekday at 07:30 in the workspace time zone

1
Aestus workflow
Reads the day's events with read-only tools
Free/busy, the event list and one event's detail. No write scope is requested for this path.
3 read tools · 0 write scopes
2
Aestus workflow
Matches each attendee domain to work already in the workspace
Open tickets, recent runs and the last decision, counted by code rather than guessed by the model.
4 meetings · 11 linked items
3
Aestus workflow
Writes one brief per meeting as a document
Every line cites the event or ticket it came from, and says plainly what it could not read.
EXAMPLE-GC-01 · 4 briefs
4
Dana · Account lead
Opens the brief beside the invitation
Nothing was booked, moved or declined; the calendar is unchanged by the run.
read-only · no approval needed

Example run

Runtime

Outcome

EXAMPLE-GC-01

Aestus workflow

aestus

Completed

$0.0164

21.0s

Questions teams ask

Can Aestus move or cancel my meetings?

Not through a read-only connection. Moving, creating or cancelling an event needs the events write scope and a saved policy, and it stays a separate step from reading.

Does it see what is inside a private event?

It sees what the connected account can see. Where a calendar shares only free/busy, that is all the run gets, and the output says so rather than guessing.

Do we have to approve the morning brief every day?

No. A briefing workflow only reads, so there is nothing to hold and nobody to interrupt.

Read the calendar without being able to move it