Automations

Automations are standing work Avi sets up for you. Each one is a prompt plus an optional schedule or event trigger: it runs on its own, without tying up your chat, and reports progress as it works. They're how Avi does anything recurring, long-running, deferred, or reactive.

Two words carry the whole model:

An automation is the standing work: its instructions, tools, triggers, budget — and its own conversation, working state, and status. It's active, it needs you, it succeeded, it failed, or you stopped it.
A session is one sitting — a single execution. Sessions are mechanical: one finishes, errors, times out, hits a limit, or is stopped; the automation's verdict never hangs on a single sitting.

When one piece of work should fan out into several — one per customer, per repo, per email thread — each is its own automation, with its own thread and its own verdict. One piece of work, one automation, one story. Work like that belongs in an agent: a project the org owns, where "onboard Acme" sets up Acme's automation and an automation that finds new customers sets up each one's.

Creating one

You don't build automations by hand — you ask for them in chat:

"Every morning at 7am, email me a summary of new GitHub issues."
"Check if our homepage is up every 15 minutes; page me if not."
"Keep an eye on these five competitors and tell me whenever one changes its pricing."

Avi creates an automation only when you ask for one or the work is ongoing: later, on a schedule, whenever something happens, or until other people reply. A one-off question or document never becomes an automation. Avi answers it in the conversation or runs it as a job in the background, whose answer comes back in the chat.

The result finds you — without cluttering the chat. An automation never posts into your conversation. The card Avi put in the chat when it started the automation keeps itself current: the automation's name, where things stand, and — when it finishes — how it ended and what came of it. The full result lands in Updates, and the automation's own page has everything. You can follow up in chat directly ("ok, fix the second one") — Avi knows where each automation it started stands. In a voice session Avi tells you in one sentence when it finishes — it waits for a quiet moment and never talks over you — and "tell me more" gets you the rest. Automations that run on a schedule or a trigger report to Updates as they go. When a result is worth seeing — photos, pages it compared, a side-by-side table — the automation shows it on its update in your feed, not just describes it.

"Whenever a PR comes in on my repo, triage it — if it needs my review, make a task for it."
"Whenever my grandmother emails me, draft a warm reply."
"Ask everyone on the team for their shirt size today, then nudge whoever hasn't replied each morning until they all have."

The agent decides whether to answer you right away or hand the work to an automation, sets the schedule, and confirms — and the chat stays free while the automation works: progress lands in Updates, and you can ask for a status check any time. There's deliberately no form to fill in: describe what you want and when, and adjust it the same way ("make that weekly instead", "stop the issue digest").

From chat, Avi picks the tools the automation's work needs and switches them on when it sets it up, so it starts working on its first session (see Tool access). From the panel, New creates a draft — a dormant automation that opens on its Setup tab, where you fill in its name, when it runs, its instructions and tools, then press Start. Nothing runs and no trigger fires until you start it.

Pre-made automations

Some work is common enough that you shouldn't have to write it from a blank page. New in the Automations panel opens a picker: start from scratch, or pick a pre-made automation. It is added at once and opens on its Setup: its stages in the chart, its instructions a tab away. Change what you like, or nothing. Its triggers are live from the moment it exists.

A pre-made automation is an ordinary automation that arrives already written, and nothing more. Its General instructions and each stage's instructions come filled in with short, plain guidelines in your words, and what you read on the Instructions tab is everything it follows: there is no hidden playbook underneath, and no questions to answer. Edit a line and that is what it does. It also arrives with the tools its work needs switched on, such as your email, Drive and calendar, as far as your project has them. They show on its Tools tab like any other. The list offers:

Client onboarding — welcome a new client, set up their folder and contacts, get the engagement letter e-signed, take in what you need and book the kickoff, and hand them over ready to work with. The folder exists before the letter, and nothing is collected until the letter is signed.
Document collection — ask people for files, chase them, review what arrives, and file it in Drive.

Each is written for one client or one collection: add one per client, in the agent that looks after them, and tell it who they are — their email address or domain, and what is known so far.

Stages

Work that moves through steps shows them. Document collection goes Ask → Collect → Review → File; client onboarding goes Welcome → Agreement → Set up → Intake → Hand off (the agreement is signed before anything is collected, and the folder exists before anything lands in it). Wherever a stage is named it wears the same small stage icon.

On the Activity tab, the stages are the page: one row per stage. A finished stage carries a green check after its name, under it what it came to in a sentence, and on the right when it was completed. The current stage shows where things stand, and when it is waiting on you the question and its answer buttons sit right inside that stage. Stages still ahead show what will happen in them.

Colour is kept for what matters: orange when something needs you, green when it succeeded, a quiet red when it was unsuccessful, and the full red for an error. Work that is simply under way stays in plain ink.

Stages are the path to success. Work moves through them one at a time, and a stage is only marked finished when its work was done. When the work cannot go on — an address bounced and there is no other, they declined, nobody answered — the automation ends as Unsuccessful right then and stays in the stage where it stopped: that stage is not marked finished, and nothing after it is. Succeeded is only reached from the last stage. So do not add a stage for things not working out ("No response", "Lost"); such a stage is refused. Say in the instructions when to give up instead.

Your own stages. Tell Avi the steps when you describe the automation ("stages should be Introduction, Contract, Hand-off; the contract must be reviewed before it goes out") and it declares them, with your approval required where you said, and writes each stage's own instructions — what happens in it — which you can read and change on the Instructions tab under the stage's name. Renaming or reordering stages keeps what you wrote for each. You can also add, rename, reorder (the up and down arrows on a row) or remove them on the automation's Setup tab with Add stages or Edit stages, or ask in chat. Work already under way stays in its stage when the edited list still has it. A pre-made automation's stages are fixed and each comes with its own instructions, which you can read on the Instructions tab under the stage's name. Their approval switches, and anything you change under a stage, are yours and stay through every update of the automation.

Only automations that have stages show them. An automation without stages shows a plain timeline of what it did, and no stage display anywhere.

Needs my approval

Each stage has one switch on the Setup tab: Needs my approval. When it is on, Avi prepares that stage's work, then asks you to sign off before it moves on. This switch is the only place approval lives: when an automation has stages, it asks for your approval in a stage you switched on and nowhere else, so turning a switch off stops the asking even if its instructions still mention checking with you first, and Avi puts an approval you ask for on the stage's switch rather than in the instructions. The question arrives like any other (see When an automation needs you), with one-tap choices that include approving everything at once.

This is enforced, not just requested: until you answer, the automation cannot move to the next stage or finish as succeeded. Document collection needs your approval in Ask (the first emails) and Review by default; client onboarding in Welcome, before the first email goes out. Switch a gate off when you trust the work, or on when you want a look.

An older automation with a Coding Sandbox

Coding work runs in the Code app, never in an automation. An automation made before that may still have a Coding Sandbox. It keeps it and runs exactly as before: its Setup shows the sandbox read-only, and it can't be duplicated.

Automations and Word documents

An automation brings the same Word know-how Avi uses in chat. If its instructions involve documents ("every Friday, draft the status memo as a Word document"), or you message it a document task, it works on the document itself with the same care: one tracked change per edit, totals worked out, no PDF unless asked. Nothing needs to be turned on.

Jobs

A job is one piece of work Avi does in the background and reports back on. It is not an automation: it is one request, done once, and its answer returns to the conversation you asked in.

Ask in chat and Avi starts one. "What does Feed.fm allow in a screen recording?" becomes a Research job. "Go through the contracts folder and summarize each one" becomes a job too. Avi replies in one line and the chat stays free.
Each job is a card in the chat. The card carries a bot icon, the job's name, and the step it is on. When the job finishes, the answer follows: the short version first, Show more for the specifics and sources, and a tile for each file the job created or changed. In voice mode you hear the short version, and a file the job made opens on screen.
Jobs stay in the conversation. They never appear in your Automations list or your home feed.
A job opens in its own tab. Click the card and the job opens in a tab of its own. Its top row names the job on the left and shows where it stands on the right; below is one conversation: everything the job did, in order, its replies labelled Avi, with a message box at the bottom. While a session runs, Stop sits in that box where Send does in the project chat.
You can keep talking to a job. Type into the message box in the job's tab. While the job is working, your message changes its course at its next step. After it has finished, your message continues the same job: it remembers everything above and picks up from there, and its result in the chat updates.
A job always reports. It ends by reporting its result or by asking you something, never by going quiet. If it stops without reporting, it is marked failed with what it last said, so the card in the chat tells you what happened and you can start it again.
A job asks whoever started it. A job Avi started from chat asks you when it needs a decision only you can make, as a Needs you question on its card. A job one of your automations started asks that automation, which answers from its instructions or asks you in its own name.
Your own automations can start jobs too. Tell an automation what to hand off and it starts a job, several at once, or one after another, and reacts when each is done ("research each vendor, then draft the comparison"). The Advanced section of the automation's Setup tab lists the jobs at work for it, and its Activity tab carries their timelines.

Work Avi knows how to do

Avi comes with know-how for particular kinds of work, maintained by the Avi team, and brings the right one to a request without being asked. Where the work runs depends on the work:

Word documents are done in the conversation (see Files).
Research runs as a job and reports back in the chat.
Meetings and Requests wait on other people for days, so each request becomes an automation of its own. It appears in the Automations list, named for what you asked, with Meetings or Requests beside its name, and it reports to your feed as it goes. Avi sets it up; there is nothing for you to configure.

Research, Meetings and Requests bring their own tools. They do not need those tools turned on in your project's Tools list. Their playbook and model are Avi's, so their Setup tab shows them without letting you rewrite them; you can still change when they run, message them, stop them, or archive them.

A request is one piece of work, however many meetings or items it holds. Settings such as a tone, a default meeting length, or additional guidance are filled in per request from what you asked and your project instructions; a note on one meeting ("keep the coffee more formal") overrides the setting for that meeting. Put standing preferences in your project instructions and every request honors them.

Research

Research answers a question that needs more than one quick search. It checks what your project already has first (an earlier note, a thread about it), searches the web several ways, and reads the pages that settle the question: the company's own terms, docs, pricing and help pages, not someone else's summary of them. Its answer leads with one sentence that stands on its own, then the specifics with links to where each came from, then what the sources leave open and who could settle it. It reads only: it never signs up, buys, sends, or contacts anyone. Each question has a max daily spend of $10.

Meetings

Meetings puts meetings on your calendar with the people you name: one request, however many meetings and people it holds. It reads your availability, writes to each person once by email covering everything you need from them, handles the back and forth in that one thread, and books each meeting with a Google Meet or Zoom link when a time is agreed. It uses your Calendar, Email, and Contacts apps and the web.

Starts every session by re-reading its email threads and anything the other people sent outside them, so nothing that arrived between sessions is missed.
Follows your project instructions (your name, company, signature, who to copy, hard rules) ahead of its own defaults.
Proposes two or three concrete times inside your working hours, with the timezone spelled out. Working hours belong in your project instructions; without them it assumes 9:00 to 17:00, Monday to Friday.
For an in-person meeting, checks the place on the web first: that it still exists, that it is open at the proposed time, and its exact address, which goes on the invitation. It never proposes or books a place it could not verify.
Writes as you: first person, your name, your signature from the project instructions, sent through your Email app. It presents itself as your assistant only if your project instructions or your request say so. You do not click Send; asking for the meeting is the instruction.
One thread per person, everything in it. Three meetings with the same person are one email with three sets of options, and every reply stays in that thread. It continues an open scheduling thread with that person rather than starting another.
Wakes up the moment a reply lands (it listens for mail from everyone named in the request from the start), checks your calendar again, and either books or offers new times.
Keeps to the meetings. If the other person raises anything else — a question for you, a request, an invoice, a personal matter — it does not answer for you: it brings it to you as a Needs you question with a suggested reply you can approve, change, or dismiss (through the automation that started it, when one of your automations did).
Books each meeting on your default calendar as it is agreed, with the attendees invited and the video link attached, nudges once after two quiet working days, asks you before giving up, and marks itself done when everything in the request is booked.

Per request, whoever starts it fills in its settings: Timezone, Default meeting length, Buffer between meetings, Video (Google Meet, Zoom — needs a Zoom account connected in the Calendar app's settings — or no link), Tone (friendly or formal), and Additional guidance (free text for that job). To steer a request already under way, message it (or the automation that started it): Meetings replies in the same email thread it started, never a second one. Each request has its own max daily spend of $60, a ceiling against runaway cost rather than a budget it tries to use up. The playbook itself is not editable; additional guidance is how you shape it.

Requests

Requests gets things sent in that other people owe you, and keeps after them until every item is in: documents (a signed form, last year's return, a countersigned contract), confirmations (an explicit yes or no), and details (an address, bank details, references). Chasing an overdue invoice, a late deliverable, or an unanswered approval is the same job. It uses your Email and Contacts apps, nothing else.

One request, one thread per set of people. Hand it everything at once — every item, who owes it, the exact wording, the deadlines. An item can be owed by one person or by several who can each provide it (a client and their advisor), and people you name together get one thread with all of them on it. It writes each set one email covering all they owe, grouped by due date with the soonest first, why, how to send it (an attachment, a link, or wherever you tell it people should upload), that they should send each thing as soon as they have it rather than waiting for the rest, and that anything which does not apply just needs saying — and keeps that one thread going. Items have their own deadlines when you give them: reminders lead with what is due soonest and always mention what comes later.
It keeps the checklist itself. Its own working state is the record of every item: asked, arrived, received, declined, or waived, with what came in and when. It never relies on a folder or a mailbox to know where things stand.
A reply from anyone counts, whoever sends it. People delegate: a colleague answers from their own address, an assistant or a financial advisor at another firm writes in, someone forwards the file from a personal account. Requests wakes on three things: mail from the people it asked and their organizations, anything continuing a conversation it started (from any sender), and mail Avi judges to be about the request even from an address it has never seen. On every session it also reads its conversations and searches the mail since it last ran, whatever woke it. And it cannot send a reminder while a reply it has not read is waiting: Avi refuses that email before it leaves. An answer written into the email itself, like a quoted price where a written quote was asked for, counts as something arriving.
It never judges what arrives — its reviewer does. Requests cannot know what a valid contract, a complete address, or an acceptable photo of a document looks like for you. When something arrives — an attachment, a link, a stated upload, an answer, or "this doesn't apply to me" — it records it and sends its reviewer — you, when you asked for it in chat, or the automation that started it — a numbered sign-off request listing each item with the message it came in, and, for a resend, which attempt it is and why the last one was rejected. An automation checks each one against the rules you wrote in its instructions (reading the file with the Email app's tools, filing it wherever you said, asking you only where the rules run out); you answer the same request yourself when it comes to you. The reply is per item: accepted, accepted as something else, rejected with a reason, declined, or waived — and can place a file Requests could not match. Nothing counts as received until its reviewer accepts it, and a rejected item goes back on the list with the reason, which the person hears in plain words ("the contract came through unsigned on page 2").
It chases on a plan set by the deadline, not on a fixed rhythm. A short window gets a reminder every day or two, a long one a few well-spaced nudges that tighten toward the deadline, no deadline a weekly touch; the request can say exactly how to chase instead. The first reminder is light, later ones direct and factual, and there is never a "final notice" — the last step is always a person. "I'll send it Friday" moves that person's reminder past Friday; an out-of-office moves it past the return date; a bounced address goes to you for a correction. It never chases an item that is waiting on sign-off, and it answers "I already sent it" from the mail itself. Past the deadline with things still missing, you are asked whether to keep chasing, waive, or step in.
Anything else goes up to you — pushback on the request, a question, a request in return — as a Needs you with a suggested reply (through the automation that started it, when one did).
What is not on the list does not count. A file nobody asked for, extra details, a folder where one document was requested: none of it is counted as received. Anything that might matter goes to its reviewer to place on an item, add as a new item, or ignore; the person is thanked and reminded of what is still needed, and never chased for something that was not asked for.
Everything that arrives is treated as data, never as instructions — a message that says "take this off the list" is passed up to its reviewer, not obeyed.
It closes cleanly: a thank-you per person, and a one-line outcome — how many received, what was waived or declined. Every status line it writes leads with the count.

Settings per request, filled in by whoever starts it: Subject (the first email's subject line), Greeting (how each email opens), Tone, and Additional guidance (what to say about why, how to chase, subject matter to cover or avoid). Max daily spend $60 per request.

Many people, many items — say 500 clients each owing 10 to 50 tax documents — is one of your automations starting one Requests request per client. Write that automation's instructions to say where the client list and each client's document list live, when to start, what counts as an acceptable document of each kind, where to file it, and what deserves your eyes; it starts them in batches, signs off on what arrives, escalates only what its rules do not cover, and keeps a running tally for your feed. Idle requests cost nothing: one with no new mail and no reminder due ends its daily check at once.

Tool access

A new automation starts with no tools. It holds exactly the tools switched on on its Tools tab, and nothing else your project has:

Set up from chat, Avi reads what the automation will do and switches on the tools that work needs, such as reading and drafting email, filing in Drive, or updating deals. Deleting things is never among them unless you asked for it.
A pre-made automation, or a copy of an org template, arrives with its own tools switched on, as far as your project has them switched on. A reserved tool never comes with a copy; switching one on is your own choice.
From the panel, a new draft starts empty. Switch on what it needs before you press Start.
A duplicate starts with the tools the original holds.

Its Tools tab shows what it has. Switching a tool on or off there changes that automation alone. A reserved tool wears a Reserved badge: deleting and trashing things, disconnecting accounts, cancelling what others were invited to, and changing the project's own settings. Switching one on is your explicit grant to that one automation.

Automations made before new ones started empty keep how they worked: everything your project has switched on, except the reserved few, plus whatever you changed on their Tools tab. A tool you switch on in Project Settings later still reaches them.

An automation that runs into a wall does not improvise around it: it searches what exists in the project and asks you for the specific tools it needs, with a one-line reason. That arrives as a Needs you with Approve and Deny buttons, in the feed and on the automation's Activity tab, each requested tool shown as a tool chip. Approving grants those tools to that automation only, and its next session has them. A single send is different: an automation without the send tool asks you to approve that one send, and Avi performs it as you (see When an automation needs you); the automation holds no new tool afterwards. A tool you have switched off in Project Settings → Tools reaches an automation only this way, by your own switch under Tools, or when Avi names it among the automation's tools in chat, while setting it up or when you ask.

You can also set the whole set in chat: "give this automation only the CRM and web search tools" sets exactly those switches on its Tools tab, everything else off, and the reply lists what it now holds. Ask what it holds first ("what tools does it have?") when you want to trim rather than rebuild the list.

Whatever the grant, an automation never manages other automations, and a Research, Meetings or Requests job it starts brings its own tools.

An automation holds one open question at a time. If what it needs changes before you answer — another tool, a different choice — it rewrites that same question in place, so you see one card that changes, never a pile of cards. A tool request that grows becomes one request for all the tools. When it no longer needs an answer, it withdraws the question.

The Automations panel

Open the Automations tile in a project's right sidebar. One list holds every automation (jobs you started from chat live in that chat instead), in three columns: Automation, Status, and Last ran. Under each name sits a one-line account of what it last did, and under that what starts it, one tag per trigger in plain words — "Weekdays at 7 AM", "Email from acme.com", "Replies to its emails". An automation that reacts to several things shows several tags; they wrap, and hovering one shows the detail behind it.

The list opens on Live: everything standing or in hand, ordered by what needs attention — Needs you first, then what is working, then what is paused, then the rest, most recent first. History, chosen under Filter → Show, holds what has finished: one-time work that succeeded or failed, and automations with nothing left to start them. An automation you stopped that still has a schedule or triggers stays in Live, one click from resuming. On a wide list each Live row ends with a Stop, Resume or Start button (stopping one that is mid-session asks first); the same actions are in the automation's ⋮ menu.

Search by name; filter by State and by Runs (One-time, On events, On a schedule); the headers sort. Archived automations are under History's State filter. When the list is narrow (on a phone, or beside an open automation) its header shows only Filter. New opens the picker for a pre-made automation or a blank draft. Open an automation and its tabs sit directly under the breadcrumb. An automation has Activity, Setup, Instructions, Tools and Session.

Activity — the automation's own account of its work. With stages, it is the stage table. Without them, it is a timeline of what changed, newest first: options sent, a reply received, booked, a question for you, a failed session. The automation writes these itself and only when something actually changed, so the timeline stays readable however many sessions ran. Each session's newest entry has a View session link to that session's transcript. When the automation finishes, its final entry carries the whole outcome, not a one-line summary. If it is waiting on you, the question appears inside its timeline entry and you answer it there. When the automation is tracking several things — each document it requested, each person it asked — it shows where each one stands as a short table inside the timeline entry that reported it: each item with its state above it (waiting, working, done, blocked, or needs you), and a link tile when it points to a file or record — the tile opens it inside Avi. The newest table is shown open; earlier ones open with Show what it looked like. That table is the current picture and says when it was last updated; earlier versions stay in the timeline behind Show what it looked like. The same table appears on the automation's row in Updates. A message box at the bottom lets you message the automation (see below); a draft that has never started doesn't show one. Each session is one point on the timeline: where it stands now, with the notes it wrote on the way folded behind earlier notes from this session. A session that finished without writing anything still leaves one line, what it did in a sentence, with its View session link. A question for you is answered at the top of its point, above anything it lists. Several links under one line show as one compact list.
Setup — everything that defines the automation. Setup, Instructions and Tools are tabs of the automation, beside the others; say any of them, or what sits on them ("the schedule", "the prompt", "tool list"), and the record opens there. Every label's description sits behind a small info mark to its right: press it to read, and close with the X.

Setup is the automation's fields, in this order:
- Name. Rename it here and save, or ask in chat ("rename the outreach automation to Email Avi deck to SMBs v1"). It stays the same automation, and its row in Updates follows.
- When it runs — every trigger as a tag, the same tags as the list ("Weekdays at 7 AM", "Email from acme.com"). An app's event is named in full ("CRM deal created or stage changed"); only a subscription to everything an app emits reads as activity, and says so ("Any CRM activity"). Hover a tag for the exact event names behind it. An automation with no trigger of its own shows When started and When messaged. When the automation has jobs at work for it, their triggers are listed too, each naming the job it belongs to.
- Stages — only on an automation that has them: each stage, its Needs my approval switch (see Stages), and an Instructions button that opens that stage's own instructions. A stage is its name and its instructions; there is no separate description to keep in step.
- Model and limits — the model, max daily spend, and spend so far. The daily spend ceiling is the one limit on how much an automation may use; there is no cap on sessions per hour. In an agent, up to 10 of its automations run at once and the rest wait their turn.
- Advanced — collapsed, and shown only when there's something in it: a legacy Coding Sandbox (read-only — see An older automation with a Coding Sandbox) and, when the automation has started jobs, its Jobs: each job's state and its one-line status. A job your automation started never asks you directly; its questions come to you from the automation itself.
Instructions is the standing brief, with the whole tab to write in. Edit it, save, and the next session uses it. When the automation has stages, a picker above the editor chooses whose instructions you are editing: General, or one stage by name, which has instructions of its own: what happens in that stage, in as much detail as you like. Each stage in the Setup chart is a link to its instructions. Automations you already had keep their instructions exactly as they were; a stage's own instructions start empty until you or Avi write them, and a pre-made automation's arrive filled in. Work of an expertise, like Meetings or Requests, shows What it does here instead: the request it was started with and your answers.

Tools is the table of tools it holds, each with a switch (see Tool access).

A job has no Setup: it opens as its own conversation (see Jobs).
Session — the automation as one conversation. A table it showed earlier in the conversation is a picture of that moment: a row that was still being worked on then wears a still mark, and only a table being shown in the session streaming right now has a turning one. Every time it wakes — a reply arrives, its schedule fires, you send a message — it continues the same conversation, so it knows what it already sent, created and asked. It reads exactly like a chat: every reply and tool call inline, streaming live while it works, with a stop button and a message box. A message sent while it is working changes its course at its next step; one sent while it is idle wakes it. Show earlier reaches further back.

Under the tabs, one status row shows the state badge and when the automation last ran — on every tab but Instructions and Tools, which have none. On the right sit Save (on Setup in that row, and on Instructions at the right end of the row that picks whose instructions you are editing, with the ⋮ menu beside it; Tools has none, since its switches apply as you flip them — the one Save for everything typed on that tab: name, instructions, spend, what each one is called, stages being edited, a pre-made automation's answers; switches and menus apply as you flip them), Start (on a draft), and the ⋮ menu. The ⋮ menu holds State (the automation's own working notes — see Working state), Stop automation… or Resume automation, Archive automation… (or Unarchive automation), and Delete automation… — permanent; the confirm says what is lost.

How an automation shows up in Updates

An automation's work reads as one story, and all of it is in one place: everything an automation does, and everything that comes back about it, lands on its row. Its row in Updates carries what it did, the records and files it created, the messages it sent, its questions to you and its outcome — not a separate row for each.

An automation has one row in Updates — in an agent, each customer's automation has a row of its own:

Everything it does is a line on that row. Routine progress stays quiet, and the newest line is rewritten as things move.
Questions count on the row ("Needs you (2)") and are answered on the automation's update page: open the row, and what is waiting on you is listed at the top, a line each, above the story. You are notified for each question. A question also appears on any other topic that carries that automation's work, so wherever you read the story, the question is there to answer.
Outcomes — the automation succeeding, or ending unsuccessful — and a run hitting an error are lines on the row that notify you.

Automations chain. Tell Avi "when onboarding finishes, start the kickoff automation" and the second starts on the first's conclusion, with the result and what it made as its first message. The tag on Setup reads After Client onboarding, and a chain can never loop back to itself.

One-off jobs share one row too. Every job you start — from chat or anywhere else — reports its result as a line on the project's single Jobs row, led by the job's name, so you can go back to it without a row per job. A job started from chat does not notify you there (its answer is already in the conversation); any other job does.

Avi decides which of these a development belongs on, the same way it curates the rest of the feed; if something is plainly part of another matter you follow, it goes there.

When an email bounces. If an email an automation sent cannot be delivered, the automation that sent it is told right away: which address failed and why. It does not have to notice the mail system's notice in your inbox, and no other automation is disturbed. This works the same whether the mail went out from your Avi address or a connected account such as Gmail. What it does next is up to its instructions (try another contact, stop, or ask you).

When a run fails. A run that stops on an error is never silent. It appears on the automation's row in Updates as "Error: …" and notifies you; on the Automations list the row says "Error in its last run" with the reason; the failure is the newest entry on its Activity tab (Run again is in its ⋮ menu). The automation stays active and runs again on its next trigger.

Results also reach you the normal ways: anything an automation produces (notes, emails, messages) lands where it was sent, and its activity is folded into the project's Updates feed.

Templates

A template gives someone their own copy of your automation. Publish an automation to the org and anyone here can copy it: the copy is theirs, runs as them, with their accounts, and starts dormant on its own Setup page — so a sales lead can design Client outreach once and every rep can run it on their own territory.

Publish from the automation's menu: Publish to the org…. Write the one line people see in the picker. Your triggers, model and spend are not part of the template; what people get is the name, the instructions, the stages with their instructions and approval switches, and the tools it holds, as far as their project has them switched on and never a reserved one.
Find and copy under New automation: pick Your org beside the search to see only what your org has published, or leave All for everything. Picking one makes a copy of your own in your project, which opens on Setup.
Edit a template by editing the automation you published. Your later edits reach every copy wherever its owner has not written their own: a stage's instructions someone rewrote stay theirs, a switch they flipped stays flipped, a list they reordered or added to keeps their shape. The listing's one line is edited from the automation's menu (Edit the template…).
Unpublish from the automation's menu (Edit the template… → Unpublish). The listing goes; copies people already made are theirs and stay.

Messaging an automation

A standing automation isn't fire-and-forget — you can talk to it. Open it in the panel and type into the message box at the bottom of its Session tab ("also include closed PRs", "why did you email Sam twice?"), or just tell the assistant in chat ("tell the issue-digest automation to also cover the docs repo"). Either way the message lands in that automation's own working conversation:

If it's working right now, your message reaches the session(s) in flight — they change course mid-session instead of starting something new. (Sandbox sessions are the exception: the message becomes the next session.)
Otherwise it runs once right away to act on it.
Future sessions remember it too — a tweak sticks without recreating the automation.
A message can even change what triggers the automation ("also run whenever Bob emails me", "stop watching that repo") — the automation updates its own event or feed subscription in response.

Messaging a concluded automation resumes it — the same automation picks back up in the same thread, with your message as its next input (see States). Adding a new question to finished work is exactly this: message the automation, don't start a copy.

When an automation needs you

Sometimes an automation hits a decision that's genuinely yours — "both Tuesday 2pm and Thursday 10am work for everyone; which do you prefer?", "this contact has two emails on file; which is current?" Instead of guessing or silently stalling, it asks:

The question lands in your Updates feed (and notifies you) as a "Needs you" mark on the automation's own row. Open the row: everything waiting on you is at the top of its page, above the story — the question, what the decision needs in the automation's own words, the draft or record it is about as a tile, the controls, and one line saying what happens if you never answer ("If unanswered in 3 days: I'll propose Tuesday 2pm"). Press Answer on a question to see its choices and type your own answer. The automation's Activity tab shows exactly the same thing inside its "Needs you" entry on the timeline — it is always the newest entry, because asking is the last thing a session does.
Approving a send. When what an automation needs is your go-ahead to send something — an email it drafted, a meeting it is booking, a message it is posting — the line says exactly that ("Send “Welcome aboard” to alex@drumsinc.com"), the draft sits under it as a tile that opens it in its app, and two controls follow: Approve sends it, Decline takes an optional reason the automation reads. The automation never sends it itself: on Approve, Avi performs that one send as you, and the line settles to Sent. If you open the draft and send it from the Email app instead, the line settles to Sent on its own and the automation carries on. Nothing goes out until you approve, and a request you leave unanswered expires without sending. To make this the only way out, switch the send tool off under the automation's Tools tab; the automation then asks for every send.
The automation shows Needs you in the panel until you answer.
Your answer resumes the work immediately — it picks back up in the same thread, with your answer in hand. Replying in plainer ways works too: messaging the automation (in the panel or via chat: "tell the scheduler Tuesday works") counts as the answer.
Every question comes with a deadline and a stated fallback — what the automation will do if you never answer ("if I don't hear back in 3 days, I'll propose Tuesday 2pm"). An unanswered question quietly becomes that plan, never a stuck automation. The feed shows how each question resolved: answered, expired into its fallback, or withdrawn (the automation finished or was stopped first). A one-off that asked a question waits for the answer (or the deadline) before it wraps up.

Automations are told to ask sparingly — routine judgment calls stay theirs; questions are for decisions only you can make.

When the decision is someone else's

An automation can put a question or an approval to another member of your org. Name them by their handle — the @name on their identity in the org — in its instructions: "escalate pricing to @matt" is enough. From one of your own automations, the row lands on their Updates feed, exactly as it would on yours: the deed, the reason, Approve and Decline. Only they can act on it; on your feed it shows who it is assigned to, with their name, until they act. From an agent, the question reaches them as a message from the agent instead. When they approve an action, Avi performs it from their account — an email goes out from their mailbox and sits in their Sent folder. If they decline, their words come back to the automation like yours would.

Reviewing many at once

When the same decision applies to many records — move each of these deals, send each of these drafts — you get a review list that fills as the automation works: one row per record, the reason it is on the list under it, a chevron for the full reasoning, Open to look at the record, and Approve or Decline (with an optional reason) for that row alone. Approve all and Decline all handle the rest in one go. A row you have reviewed leaves the list, as does one whose deadline passed; the header keeps the count ("2 of 5 reviewed · 1 unanswered") and "Show 3 rows" brings them back if you want to look. The header says how many are left and what happens to rows you never answer; rows you have handled stay in the list, dimmed, until the whole review is done. Avi performs each approved change for you the moment you approve it; nothing happens to a row you decline or leave. The automation keeps working while the list is open — it is a proposal, not a question — and hears back once, after its run has ended and every row is settled or past its deadline, with what was approved, what was declined and why, and what was left for its fallback.

Working state

Long-running automations keep private working notes — where they left off in long work, decisions they've made, and standing directives you've messaged them ("skip weekends from now on") — so nothing important is lost even as old conversation history is condensed over time. This state never touches your Tasks, Drive, or other apps; it belongs to the automation alone. You can inspect it any time: open the automation's ⋮ menu and choose State — useful for seeing exactly what a months-old automation believes it's doing next.

States

The status belongs to the automation. A session doesn't carry a verdict — it's one sitting, and a bad sitting doesn't sink the work. Every automation shows exactly one state, everywhere it appears — the list, its own page, and the Updates feed all use the same vocabulary:

Needs you — the automation asked you a question and is waiting on the answer (see When an automation needs you). This outranks every other state.
Working — a session is executing right now (you can watch it live).
Paused — the daily credit budget is spent; new sessions wait for tomorrow. Resumes on its own (or ask in chat to raise the budget).
Active — live: watching its triggers or waiting on its schedule, nothing running at this moment.
Not started — a draft: created with New and never started. Review its Setup, then press Start.
Succeeded — done for good. A one-off succeeds when its work does; a standing automation succeeds when it decides its work is complete ("watch for X, then report") or when you tell the assistant to mark it done.
Unsuccessful — done, and the goal was not reached: the automation decided for itself that it could not go on (the address bounced and there was no other, they declined, nobody answered after the last follow-up). It always says why. This is an ordinary outcome, shown in a quieter red.
Error — the automation broke and the platform ended it: a one-time run that crashed, or five failed sessions in a row. Shown in the full red, with the error. (A single session that hits an error is also marked Error on its Session and in Updates, but the automation stays active and runs again on its next trigger.)
Stopped — done because you chose to end it (Stop automation…, or ask in chat). Not a failure — just your call.
Archived — put away. Archive automation… ends it if it was running and keeps everything (sessions, working state, questions, its topic in the feed) while taking it out of the list, search, and the assistant's view. Pick Archived in the State filter to see archived automations; Unarchive automation brings one back with the state it had, and you can resume it from there.

Succeeded, Unsuccessful, Error, and Stopped mean the automation is dormant — its schedule and triggers stop firing, and nothing runs on its own again. But a concluded automation isn't sealed: you can resume it, and the same automation continues — same thread, same working state, same topic in your feed. Message it (the message box works on concluded automations: sending resumes it with your message), choose Resume automation in its ⋮ menu, or ask in chat. Resuming clears a failure and starts the reliability clock fresh; resuming an automation with a schedule arms the schedule again. This is deliberate: one piece of work should live in one automation — resuming keeps search, the Updates feed, and the assistant all pointing at the same story instead of a trail of near-duplicates. When you are done with an automation for good, archive it rather than deleting it: nothing is lost, and it can come back.

When an automation reaches a verdict — Succeeded or Unsuccessful — that always lands in the project's Updates feed too, under the automation's own topic, headed by a one-line account of the outcome: "Succeeded: what it accomplished", or "Failed: why". The full outcome sits beneath that line, in the Update and on the automation's Activity tab, so you can read what it found or did without opening a session. You never have to open the panel to learn that standing work finished or broke, or what it did. (Stopping an automation yourself doesn't post one — that's your choice, not news.)

Max daily spend

Every automation carries one ceiling — its max daily spend — so nothing can quietly run away. It is a guardrail, not a target:

As a session approaches the day's ceiling it's told to wind down: it finishes the item in hand, saves its progress, and ends cleanly.
Once the ceiling is reached, new sessions wait until the next day, the automation's Activity tab records the pause, and a Needs you lands on its row in Updates asking whether to raise the ceiling — pick a raise or type a number, and the automation picks its work back up within a couple of minutes; choose to wait and it resumes tomorrow. Two things are never lost to a pause: a one-time scheduled run and any message you send the automation — those run once the pause lifts.
A session that ignores the wind-down and crosses the ceiling anyway is simply stopped. That is not a failure: the automation stays active, nothing counts against its reliability, and it resumes the next day.

The default ceiling scales with the model the automation runs on: 2,500 credits/day on the standard models (Haiku, Sonnet), 7,500/day on Opus, 25,000/day on Fable. Name a number when you create the automation and that number is used instead; ask in chat to raise or lower it any time.

A one-off job starts with a ceiling of its own kind (1,500 credits/day for a plain job; Research, Meetings and the others carry theirs). That ceiling is yours to raise on the job itself, in chat ("raise this job's budget to 15,000") or on its Setup, without touching any other job of that kind. A paused job picks up its remaining work once the ceiling is raised. Sandbox sessions count toward the same ceiling.

Automations don't expire on a timer — an automation lives until it concludes or you stop it. Budgets and the panel's per-automation cost display are what keep a forgotten automation from becoming a surprise.

Scheduling

Automations support three kinds of schedule:

Recurring at a time of day — "every morning at 9am", "Mondays at 8". Runs on a cron schedule in your local timezone, so it stays correct across daylight-saving changes.
Recurring by interval — "every 2 hours". Minimum interval is one hour.
One-time — "tonight at 11pm", "in three hours". Runs once, then the automation is done.

Creating an automation never runs it. Whatever its instructions hold, nothing happens until its trigger fires, you press Start in its panel, or you ask for a run now. An automation with no schedule runs only on those last two.

Starting now and staying scheduled

A schedule doesn't have to mean waiting: for two-phase work — "message everyone today, then nudge stragglers each morning" — Avi arms the schedule (often with an event subscription too, so it reacts the moment each reply lands) and, because you asked for today's pass, starts that first run as a separate step with your words behind it. If you did not ask for a run now, the first run waits for the first tick, and you can say "kick it off now" at any time — it runs immediately without disturbing the schedule.

Feed subscriptions

Besides (or instead of) a schedule, an automation can subscribe to the project's Updates feed, so it runs the moment something newsworthy lands there — whatever the source (GitHub, email, Slack, AWS, an app):

"Triage every PR on my repo" — runs whenever a pull-request update appears or gains activity in the feed, with that update's headline and latest activity as its input.
"When anything new lands in the feed, summarize it to Slack" — runs on every new update.

Because the trigger is the curated feed — not raw source events — the automation reacts to the same deduped, living stories you see in the Updates sidebar. Subscriptions can be narrowed by source ("only GitHub activity"), by a specific thing ("only PRs from acme/api"), or by headline keywords, and combined with a schedule (a daily digest that also reacts to PRs). Housekeeping changes that don't add news never wake an automation. If updates land while sessions are in flight, they run in parallel up to the automation's concurrency limit (3 by default, adjustable per automation); beyond that they queue and run in order as slots free up. A per-automation hourly run cap keeps a noisy feed from running away.

One thing to know: the feed is curated. An editor decides what's newsworthy enough to appear there, so something low-key — a brief personal note, a routine notification — may never become a feed update at all, and a feed-subscribed automation won't run for it. When the automation must catch a specific occurrence every time, it uses an event subscription instead.

Event subscriptions

A trigger names the app its event comes from ("CRM deal created", "Calendar event"); one that would fire on that event from every app is refused, except messages, which many apps deliver. Changing an automation's schedule or triggers never runs it, and nothing runs unless you asked.

An automation can also subscribe directly to the project's event log — the raw record of everything Avi ingests (every email, chat message, calendar change, repo event, app event), before any curation:

"Whenever my grandmother emails me, draft a reply" — runs on every inbound email from her addresses, even a one-word hello.
"When Jane messages me, ping my phone" — runs per message from her handle, on any channel that carries it.
"When something lands in #deals, summarize it for me" — runs on posts in that chat channel.
"When a meeting with the Acme folks changes, re-check my prep doc" — runs on calendar activity involving those attendees.
"On every new support ticket, do a first-pass triage" — runs per ticket event, no editorial gate in between.

Event subscriptions match on the event's envelope, and the filters compose:

Type — what kind of event, with wildcards: inbound email, a chat message, a calendar change, repo activity.
From — the sender's email address(es) or chat handle(s), or a bare domain. This is deliberately per-sender, not per-thread: replies get knocked out of threads all the time, but mail from jane@acme.com is mail from Jane wherever it lands. List every address a person writes from. For an automated sender — a school's notification system, a bank, a service's alerts — use its domain (parentsquare.com): those systems often mint a different donotreply+…@ address for every message, and a domain matches all of them. A plus-tag never breaks a match either: donotreply@x.com matches donotreply+abc@x.com.
Involving — the person in any role: an email's to/cc, a calendar event's attendees.
Channel — the chat channel a message was posted in.
Provider — which service carried it ("avi", "slack", "google"). This matters for chat handles, which are only unique within a service: "jane" on Slack and "jane" on avi messages can be different people, so "when Jane messages me on Slack" pins both the handle and the provider. (Email addresses are globally unique, so they rarely need it.)

They're exact and predictable: if the matching event lands, the automation runs; if it doesn't, nothing runs and nothing is spent. That's also why narrow filters matter — every match is a run, and "every inbound email" includes the newsletters. When you name a person or a channel, the agent arms the filter to match just that; describe the trigger as precisely as you'd like the spend to be. Use event subscriptions whenever missing an occurrence isn't acceptable; use feed subscriptions when you want to react to the bigger, curated story. The same queueing applies, and an automation can never trigger itself: neither the platform's internal events nor the automation's own edits (a note it updates, a task it creates) will re-fire its own subscription.

Relationship to Tasks

Tasks are to-do items — they track work, they don't run it. Automations are the engine: when you ask for anything automated, the agent sets one up.

Good uses

Daily briefings ("every morning at 7am, email me a summary of new GitHub issues").
Monitoring ("every 15 minutes, check if our homepage is up; page me if not").
Reacting to activity ("triage every PR from my repo and make a task if it needs my review").
Coding work on a repo belongs to the Code app, not an automation.
Weekly reports.
"Work on this in the background" requests you explicitly want as their own automation.
Anything you'd otherwise have to remember to ask for again.