What email address do I send tasks to?

agentplanners@agentmail.to — and it has to come from the address you sign in with, since the sender address is what links the task to your account and organization. There's nothing to configure first.

Can someone spoof my email address and run tasks in my account?

That's precisely why inbound mail never starts a task directly. It creates a pending intent and replies asking for confirmation, so a spoofed email produces an unsolicited confirmation request in the real owner's inbox rather than a running task. The one-click confirm link is HMAC-signed and expires, and any account change still needs in-app approval on top.

Does confirming an email task also approve the changes it makes?

No. Confirming starts the task. Every account change the task then proposes goes through the normal approval gate, exactly as it would for a task started in the app.

Can email from someone who isn't a member trigger a task?

Only through a standing rule you authored in-app — that authorship is the consent. Rule-fired tasks are owned by the rule's author, capped at 10 fires a day per rule, and don't reply into the triggering thread unless you opt in, so an outsider's mail can't pull your data back out.

How many tasks can I create by email?

10 per sending address per 24 hours. Beyond that the channel replies with a rate-limit notice and points you at the Workspace.

What happens if I never reply to the confirmation?

Nothing runs. The pending intent expires after 24 hours on its own.

Can I check task status by email?

Yes — reply "status" (or 状态 / 进度) and you'll get your organization's five most recent tasks with links. It's read-only.

Use it

Agent Mail: run and approve agent tasks from your inbox

TL;DR

Agent Mail is a second front door into the same agent: instead of opening the app, you email the task. Send it to the agent inbox from your sign-in address; it creates a pending intent and replies with a summary of what would run and where. Reply “confirm” (or 确认) — or click the signed link — and the task starts, reporting back into the same thread. An email address can be spoofed far more cheaply than a signed-in session, which is why the confirmation exists, and why account changes the task proposes still go through the normal in-app approval gate on top.

The address, and who can use it

Send to agentplanners@agentmail.to. There are no credentials to configure — the sender address *is* the identity, so the email must come from the address you sign in with. That address is resolved to your account and organization; mail from an address that isn't a member gets one polite pointer back and nothing else happens.

If you belong to several organizations, the task targets the one where you most recently created a task — and the confirmation reply names that organization explicitly, so you see the target before you approve rather than after.

The four-step flow

1Send the task. Subject and body are combined into the goal — write it the way you'd type it in the Workspace.
2Read the confirmation reply. The agent creates a *pending intent* and replies with what it would run and in which organization. Nothing has started at this point.
3Confirm. Reply `confirm` / `确认` / `yes` / `ok` / `approve` in-thread, or click the one-click link in the reply. Reply `cancel` / `取消` and the intent is dropped.
4Get the report. The task runs and replies into the same thread when it finishes. Any account change it proposes is queued behind the normal approval gate — the confirmation started the task, it did not pre-approve the writes.

A pending intent expires after 24 hours. Confirming is atomic, so a duplicated email delivery can't start the same task twice.

Four ways mail enters the channel

Entrance	What triggers it	Confirmation needed?
Thread reply	`confirm` / `cancel` in a thread with a pending intent	It is the confirmation
@mention	`@agentplanners <instruction>` anywhere in the body — the instruction is the task, the rest of the email is context	Yes — members only
Standing rule	An inbound mail matching a rule you authored in-app	No — the rule is the standing consent
Plain task email	Any other email from a member	Yes

Priority runs top to bottom: an explicit `@agentplanners` mention beats a standing rule, so a deliberate instruction always wins over an automation. Mentions and rules are both read from the *cleaned* body — quoted history and signatures are stripped, so a long reply chain can't re-fire a rule on every message.

Standing rules

A rule is conditions plus an instruction, authored on the Mail page by a signed-in member. That in-app authorship is the standing consent that lets matching mail run without the per-email confirmation — which is what makes it useful for mail from people who *aren't* members, like a client's weekly report or an alert from another system.

Behaviour	Rule
Matching within a condition group	Any term matches (case-insensitive substring)
Matching across groups	Every group you filled in must match
A rule with no conditions filled in	Matches nothing — a match-everything rule has to be written deliberately
Fires per rule, per day	10, then it's logged as capped and skipped
Rules applied per email	At most 3
Who owns a rule-fired task	The member who authored the rule
Replying into the triggering thread	Off unless you opt in per rule

That last row matters: the sender who trips a rule may be an outsider, so replying a report back into their thread would disclose your data to them. It's opt-in per rule for exactly that reason.

Checking on things by email

Reply `status` (or 状态 / 进度 / `progress`) and the agent replies with your organization's five most recent tasks and links to them. It's read-only and members-only — it starts nothing and changes nothing.

Limits and safeguards

Confirmation is mandatory for member-sent tasks — inbound mail never starts a task on its own.
Writes stay gated. Confirming an email task starts the run; every account change it proposes still needs in-app approval unless you've deliberately enabled auto-approve.
10 email tasks per address per 24 hours, then the channel replies with a rate-limit notice and points you at the app.
Pending intents expire after 24 hours and confirming is a one-shot atomic flip.
Loop and bulk protection — the channel ignores its own sends and anything from no-reply, mailer-daemon, postmaster or bounce addresses.
Webhook signatures are verified, and the message body is re-fetched from the mail API rather than trusted from the webhook payload.
Message bodies aren't stored — the Mail page's activity log records the event, and the body is re-fetched on demand and checked against your organization before it's returned.

Where to manage it

The Mail page in the app holds the activity log, the org-scoped inbox view and the rule editor. Approvals raised by an email-started task appear in the normal places — see Approvals & workflow. To have a task run on a cron instead of on an email, use Schedules; you can also just say the cadence in the email ("every day at 9am") and the agent will set the schedule up.

Frequently asked questions

What email address do I send tasks to?: agentplanners@agentmail.to — and it has to come from the address you sign in with, since the sender address is what links the task to your account and organization. There's nothing to configure first.
Can someone spoof my email address and run tasks in my account?: That's precisely why inbound mail never starts a task directly. It creates a pending intent and replies asking for confirmation, so a spoofed email produces an unsolicited confirmation request in the real owner's inbox rather than a running task. The one-click confirm link is HMAC-signed and expires, and any account change still needs in-app approval on top.
Does confirming an email task also approve the changes it makes?: No. Confirming starts the task. Every account change the task then proposes goes through the normal approval gate, exactly as it would for a task started in the app.
Can email from someone who isn't a member trigger a task?: Only through a standing rule you authored in-app — that authorship is the consent. Rule-fired tasks are owned by the rule's author, capped at 10 fires a day per rule, and don't reply into the triggering thread unless you opt in, so an outsider's mail can't pull your data back out.
How many tasks can I create by email?: 10 per sending address per 24 hours. Beyond that the channel replies with a rate-limit notice and points you at the Workspace.
What happens if I never reply to the confirmation?: Nothing runs. The pending intent expires after 24 hours on its own.
Can I check task status by email?: Yes — reply "status" (or 状态 / 进度) and you'll get your organization's five most recent tasks with links. It's read-only.