Mail delivery

Aestus can send mail for you. It cannot read yours

The connection creates drafts and sends approved mail from the mailbox you name; there is no tool in it that reads your inbox.

Join the waitlist See the Gmail example

Gmail with Aestus

Keep the tool. Change what the team can see.

It is worth being blunt about the shape of this one, because the name suggests more than it does. Aestus connects to Gmail to put messages out, not to take messages in. The reviewed operation list has three entries: find out who the mailbox is, make a draft, send. There is no search, no thread fetch, no inbox listing. A use case that says it did not read your mail is describing this limit, not apologising for a missing feature.

Delivery is deliberately two moves. An unattended run may write a draft, because a draft harms nobody. Turning that draft into mail somebody receives is held, and the person holding it sees the recipients, the subject and the whole body as it will arrive. They say yes or no to that, and no to it means running again rather than quietly editing what was approved.

Where a message goes out on a schedule to a fixed list, waiting on a human every Friday is theatre. A standing grant covers exactly that case: a named workflow, agreed recipients, no per-run prompt, and the same receipt on the run afterwards.

Good first workflows

Deliver a recurring summary
Let a schedule write it and a person release it, with the sent body kept beside the run.
Answer from a shared inbox
Draft the reply with the ticket context attached and leave the send as a human decision.
Send without waiting
A standing send grant lets a named unattended workflow post to fixed recipients, still on the record.

A complete Gmail 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 mail connection can and cannot do

It knows who the sender is and can write a draft. Sending that draft is held, and nothing in it reads received mail.

operations@meridian.example · connectedDrafts, plus approved send

Runs without an approval

Read the mailbox identity
Create a draft message

Held for a named person

Send the drafted message

No tool in this connection reads received mail.

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

Concrete workflow example

Send the weekly summary only after someone approves the words

The workflow drafts the message and holds it. A named person reads the exact body that would go out, then releases it.

TriggerThe Friday summary workflow finishes writing its document

1
Aestus workflow
Drafts the message instead of sending it
The draft tool and the send tool are separate; only the draft runs unattended.
draft created · not sent
2
Aestus
Holds the send behind the approval gate
Recipients, subject and full body are shown to the approver before any decision.
held · 1 approver
3
Priya · Operations
Reads the body and releases the send
Editing the recipients means rejecting and re-running; the approved text is the text that goes.
approved · 09:41
4
Aestus workflow
Sends once and keeps the receipt
Message id, recipients, approver and run cost stay on the card that asked for it.
EXAMPLE-GM-01 · receipt kept

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

Illustrative product example — not a production run

Send the approved weekly summary

Example run		Runtime	Outcome
EXAMPLE-GM-01	Aestus workflow	aestus	Completed	$0.0172	18.4s

Tokens in / out: 5,600 / 620
Failure code: —
Agent: —

Illustrative Aestus workflow; actual costs and results vary

Example run cost

$0.0172 in the illustrative product example

A fixed example standing for one summary run of 5,600 input tokens. Writing the message and sending the approved version are both inside that run.

Set it up in four steps.

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

01
Pick the mailbox that should be the sender
An organization admin connects the mailbox recipients will see in the From line. Use a shared or role mailbox where the mail is not from one person.
Read the provider docs
02
Review the access Google asks for
Google lists the requested access before you approve it. What Aestus uses is the mailbox identity, draft creation and send.
Read the provider docs
03
Decide who releases a send
Name the person a held send goes to. Aestus shows them the recipients, subject and full body before they decide.
Aestus product guide
04
Turn on the workflow that delivers
Enable the use case whose delivery step is email. Its first run drafts, holds, and waits for that named person.
Aestus product guide

The boundary stays visible while the work moves.

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

Where control lives

Drafting and sending are different tools

Creating a draft and sending it are separate operations. An unattended run reaches the first one; the second is held.

The approver reads the actual mail

Recipients, subject and the complete body are shown before the decision, so nobody approves a description of a message.

Unattended sending is granted, never assumed

A scheduled workflow may send without a per-run approval only where a standing grant says it may, to recipients agreed in advance.

What Aestus records

Who released it

The approver, the moment they decided, and the exact body they saw are kept beside the task that asked for the mail.

The provider receipt

The message identifier and the recipients come back from the send and stay on the run, so delivery is a fact rather than an assumption.

One run, one cost

Tokens, latency and cost belong to the workflow run. The send is part of it, not a charge that arrives from somewhere else.

Questions teams ask

Can Aestus read our inbox?

No. The Gmail connection carries three operations: read the mailbox identity, create a draft, and send. None of them reads received mail, which is why a briefing use case tells you plainly that it did not read your mail.

Can a workflow send without asking anyone?

Only where a standing send grant exists for that workflow and those recipients. Without one, the send is held and a named person releases it.

Can the approver edit the wording first?

No. They approve or reject the body in front of them. Changing the words means rejecting it and running again, so the approved text is always the text that went out.

See all integrations See the security controls

Start with one Gmail 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

Send the weekly summary only after someone approves the words

The workflow drafts the message and holds it. A named person reads the exact body that would go out, then releases it.

TriggerThe Friday summary workflow finishes writing its document

1
Aestus workflow
Drafts the message instead of sending it
The draft tool and the send tool are separate; only the draft runs unattended.
draft created · not sent
2
Aestus
Holds the send behind the approval gate
Recipients, subject and full body are shown to the approver before any decision.
held · 1 approver
3
Priya · Operations
Reads the body and releases the send
Editing the recipients means rejecting and re-running; the approved text is the text that goes.
approved · 09:41
4
Aestus workflow
Sends once and keeps the receipt
Message id, recipients, approver and run cost stay on the card that asked for it.
EXAMPLE-GM-01 · receipt kept

Example run

Runtime

Outcome

EXAMPLE-GM-01

Aestus workflow

aestus

Completed

$0.0172

18.4s

Questions teams ask

Can Aestus read our inbox?

Can a workflow send without asking anyone?

Only where a standing send grant exists for that workflow and those recipients. Without one, the send is held and a named person releases it.

Can the approver edit the wording first?

No. They approve or reject the body in front of them. Changing the words means rejecting it and running again, so the approved text is always the text that went out.

Aestus can send mail for you. It cannot read yours