How Monad handles recurring work

Ask Monad to own something ongoing — "keep an eye on the #support channel and summarize anything urgent", "watch this space for uploaded invoices and log them", "post a release digest every Friday" — and it doesn't just handle the one request. It builds up standing know-how for that area: what "done" looks like, where to post, what to remember between runs.

We call one of these standing responsibilities an Automation. Most of the time you never think about them: you ask Monad in plain language and it sets one up, grows an existing one, or just answers. From where you sit it's still one teammate — you don't @mention or DM an Automation, and nothing about how you talk to Monad changes.

Why this matters for you#

• One name to remember. You never have to learn "who owns what" — you just ask Monad, and it routes the work internally.
• Monad gets better at the things you rely on it for. When you ask for something an existing Automation already covers, Monad grows that standing responsibility instead of starting over, so its know-how in that area keeps compounding.
• Nothing to configure up front. An Automation starts from the first request you make; you don't set up a new assistant before Monad can help.

Automations vs. scheduled tasks#

These sound similar but are different things:

• An Automation is a standing responsibility Monad owns on behalf of the workspace — it can post in shared channels, watch spaces, and act for everyone who can see that space. See Agents → Scheduled tasks for the personal version.
• A scheduled task is a personal, recurring instruction you set up for yourself — it runs as you, uses your connected apps, and always delivers privately to your DM with Monad. Nobody else sees it.

If you want Monad to check your own inbox every morning, that's a scheduled task. If you want Monad to keep an eye on a shared channel for the whole team, that's an Automation.

Managing Automations (workspace admins)#

Workspace admins get a full list at Settings → Monad → Automations, and can manage them directly rather than only by asking:

• Create one yourself with New automation — give it a name, a short description of what it's for and when Monad should use it, and its instructions. The description is what Monad matches your requests against, so keep it specific.
• Edit an Automation's name, description, or instructions at any time.
• Turn one off with the Enabled switch. While it's off, Monad never sends work to it, but nothing is lost — flip it back on and it picks up where it left off.
• Retire one you no longer want. Its past work and feedback stay attributed to it, and its name becomes free to reuse.
• Graduate one into a teammate with its own name and profile — see Agents → Giving an Automation its own identity.

Monad's own row is always in this list and is deliberately locked: you can't disable, retire, or graduate the workspace assistant itself.

A few things aren't editable here yet. Tool access is shown read-only — to change what an Automation can reach, ask Monad. The Sessions and Memory tabs are placeholders for now; an Automation's runs still show up in the workspace's run history, and its memory is still consulted on every run, just not browsable from this screen.

What Automations don't have#

Automations aren't separate identities. They have no profile page, no handle, no @mention, and no DM of their own, because everything they do, they do as Monad. That's the point — one face, however much know-how sits behind it. If you want one to have its own face, graduate it — see Agents → Giving an Automation its own identity.

Related reading#

• Agents → Agent concepts for how Monad works day to day.
• Agents → Giving an Automation its own identity for graduation and what happens when you reverse it.
• Agents → Scheduled tasks for the personal, per-user version of recurring work.
• Agents → How Monad improves for how feedback shapes an Automation's instructions over time.