Automations

How Agent A runs work for you on a schedule. Two kinds: one runs a small program the agent built for you; the other wakes the agent up and lets it do the work itself.

You describe what you want done and when. The agent writes the automation, picks a schedule, asks once for approval, and runs it from then on. Every run's output (stdout, stderr, exit code) is stored so you can review it later.

Two kinds of automations

1. Scripted automation

The agent writes a small program once, then runs it for you on a schedule. Fast, cheap, and predictable: the steps don't change between runs. Use it when the task is mechanical and the output looks the same every week.

Example asks:

• "Every Monday at 9, pull last week's keyword deltas and DM me on Slack."
• "On the first of each month, archive last month's data into the report archive."
• "Every hour, refresh the Brand Radar cache so the dashboard loads instantly."

2. Agent automation

Instead of running a saved program, the schedule wakes the agent up with a written instruction (the prompt). The agent reads it fresh each time, looks at whatever is in your workspace right now, and decides how to act, the same way it would in a chat with you.

Use it when the work needs judgment, when the situation changes between runs, or when you want the agent to make a small improvement every cycle and have those improvements add up over time.

Example asks:

• "Every day at 9 UTC, look at what changed in the workspace and update the team wiki." (This is the Wiki sync automation in the list above, covered in the next section.)
• "Every Friday afternoon, look at the week's competitor data and tell me what's worth my attention on Monday."
• "Every Monday, look at this draft landing page, find the single biggest improvement, and apply it." Run it for a few weeks and the page rewrites itself: see what happens after many cycles.

Managed automations (preinstalled by Letaido)

Some automations ship preinstalled in every workspace and stay up to date as Letaido improves them. The first managed automation is Wiki sync, an Agent automation that runs daily and keeps your workspace's long-term memory at ~/workspace/wiki/ up to date by distilling new chat sessions, file edits, and uploads.

The wiki/ folder is a proof of concept for workspace long-term memory: a place where the agent records decisions, named entities, conventions, and recent work so future chats can pick up where past ones left off. Wiki sync is what keeps it current without you having to remember to update it.

Managed automations are marked as preinstalled in the Automations tab and are read-only by default. If you want to customize one, click Customize to fork it into an editable copy. Your fork stays in your workspace; the original keeps running with Letaido's updates.

Triggers (coming soon)

Today all automations are triggered by cron. The next wave will add event-driven triggers so an automation can fire when something happens in a connected app: a new GitHub PR opened, a HubSpot deal moved to Closed-Won, a Slack message posted in a specific channel.

This unlocks patterns like:

• "Whenever a new PR is opened in our main repo, launch Claude Code and Codex to do a security review, then post the joint summary in #engineering."
• "Whenever someone posts in #incoming-leads on Slack, look the company up in Ahrefs and reply with a 4-line context summary."

Until then, you can already act on third-party events today by combining a Scripted automation that polls the webhook queue with the subscriptions described in Webhooks & triggers. Slack, GitHub, HubSpot, Linear, Notion, Webflow, and a dozen other providers already deliver events into that queue; the cron-scheduled script just picks them up and acts.

When to ask for an automation vs a one-off

The shape of the ask tells you which one you want.

• If you say "every Monday," "each quarter," "whenever X happens": automation.
• If you say "this Monday," "right now," "for this one URL": one-off chat run.

A one-off, by contrast, is anything you only want done once right now:

• "Pull last week's data and give me the summary."
• "Check this list of 100 URLs and tell me which ones return 404."

What approval looks like

The first time an automation is registered, you see an approval card with:

• The name and one-line description.
• The schedule (cron expression).
• The kind (Scripted or Agent).
• The model and context cap (for Agent automations).
• The script body or the prompt body.

Owner or admin clicks once. After that, the automation runs on schedule. You can pause, resume, manually trigger (Run now), customize, or delete it from the Automations tab.

Common schedules

Cron times are UTC on this host. If you need a local timezone, the agent will either pick a UTC time that maps to your local time year-round, or add an in-script zoneinfo guard that only acts when local time is in the right window. DST is annoying; the agent tells you when it bites.

Dependencies

If an automation needs a Python package or a connector that is not yet approved, the agent will:

1. Check whether the dependency exists.
2. If not, request the install or the connector approval through the standard approval flow.
3. Wait for owner/admin to approve.
4. Then register the automation.

You can see one approval card for the dependency, one for the automation. The agent typically batches related requests so you click once for the whole flow rather than three times.

What automations are running in this workspace

You can list them from the Automations tab in your workspace. The docs site you are reading is maintained by three of them:

• Wiki sync (daily, managed by Letaido): an Agent automation that reads new chat sessions, file edits, and uploads, and distills them into the workspace wiki at ~/workspace/wiki/. This is the long-term memory the next two automations rely on.
• Docs sync (every 30 min): a Scripted automation that reads markdown from ~/workspace/docs/, renders it to HTML, and pushes it into the public site so visitors see the latest version within half an hour.
• Docs auto-update suggestions (Mondays at 10:00 Europe/Bucharest): an Agent automation that reads the wiki, lists what changed in the workspace in the past week, and proposes specific edits per chapter for Andrei to review. Suggestions only; no auto-publish.

Limits

• An automation run times out after 1 hour. Longer work should split into stages and write intermediate state to the database.
• stdout and stderr are capped at 50 KB per run. Anything bigger should go to a file or database row.
• Schedules are managed by the platform after approval. To change a schedule, the agent registers a new automation and removes the old one; it does not silently edit cron.

Under the hood. Each automation is a row in the platform's automations table plus a crontab entry. The runner shells the script (Scripted) or spawns a fresh agent chat with the saved prompt (Agent) with stdin/stdout/stderr captured, sets a run ID env var, and writes the run record back. If a script imports anything not installed system-wide, the run fails fast with a clear error in the run history.