Does Trello Butler Remember Between Runs?

No. A Butler automation carries no memory from one execution to the next. Each rule, button, calendar command, and due date command runs against the board as it stands at that moment, uses the values attached to its trigger, and finishes. The next execution starts from a new trigger, with no record of what the previous execution reasoned, decided, or computed.

The board can feel continuous. The same rules fire every morning and the same cards move through the same lists. That continuity lives in the board and in the rule definitions, not in anything Butler itself remembers.

What does one Butler execution actually hold?

Inside a single execution, Butler has working context. A trigger supplies the starting facts: which card moved, which label was added, or which due date is approaching. Automation variables stand in for current values at the moment the automation runs, such as the card name or the member who triggered it, and actions can pass results forward through the steps of that one command.

That context is scoped to the execution. When the command finishes, its variables are gone. No later rule can ask what an earlier rule calculated, because Butler offers no variable store that survives between executions. A variable is a placeholder resolved fresh each time, never a saved note from last time.

What does the next execution start with?

A new execution starts with its trigger and the board in front of it. It does not know that the same card was escalated yesterday and then quietly moved back, or that an AI step summarised a card last time and reached a conclusion about it. Each trigger is handled as an isolated event.

Take a calendar command that creates a weekly review card and posts a summary comment. Monday's execution can note that two items are blocked on a client reply. Next Monday's execution builds a new card from its template and rebuilds the picture from the board's current cards. It can easily present the same two items as newly discovered.

The old comment still exists for a person to read. Existence is not inheritance: a new execution does not search old cards or load earlier comments as its starting context.

Where does information actually persist in Trello?

Three things hold information after an execution ends, and each holds it in a different shape:

1. The board itself. Cards, lists, labels, checklists, and due dates that an automation creates or changes stay on the board, as state for people and future triggers to act on, rather than as memory an execution loads at startup.
2. Custom fields. A rule can write a value into a custom field on a card, and that value stays there. A later rule can read the field and branch on it, which makes fields the closest thing Butler has to stored state.
3. The automation definitions. Rules, buttons, and scheduled commands persist as configuration. The board remembers how it is set up, even though each execution remembers nothing.

What survives is a card, a field value, or a setting that an execution deliberately wrote, in a structure defined in advance. None of the three gives the next execution the previous execution's reasoning, and none loads automatically when a run begins.

What about custom fields as memory?

Custom fields are the strongest memory inside Trello's own platform, and their boundaries show what board state is for. A field belongs to one board and holds one typed value per card: a number, a date, a checkbox, a dropdown choice, or a short text value. Rules can set and test a field, so a workflow can count escalations or stamp the last review date.

A field can hold that a card was escalated twice. It does not hold the thread that explains why the second escalation used different wording, or what was decided in email or chat in between. Richer knowledge has to be flattened into a single value, written card by card, and read back by rules that already know which field to check.

How do operators carry knowledge between runs today?

Working patterns move knowledge onto the board, in a form the next trigger can be pointed at: a structured comment at the end of each run, one status card per project updated after every scheduled command, counters and stage flags in custom fields, or state handed to an external automation or agent that owns the history.

These patterns share a shape: memory stays inside one board or one tool, in a format designed in advance, holding values and comments rather than the full context behind them.

What kind of memory does a scheduled AI agent actually need?

An AI step changes what the next run needs. The valuable output is rarely a count or a date. It is a judgement: this client already answered and asked for pricing next quarter. The next run needs that judgement with its full context, available to the other tools doing related work, not only to one board.

How does Vilix AI give a scheduled agent a memory outside the board?

Vilix AI is a cloud-hosted memory layer that sits outside any single automation tool, so there is no infrastructure to run alongside your boards. A scheduled agent connects to Vilix AI over MCP. At the start of a run it retrieves the relevant saved context, and at the end it saves what it did and decided.

Vilix AI stores full conversation history, not just extracted facts and field values, so the next run can revisit what was actually said and decided. Because the memory belongs to your Vilix AI account rather than to one board, the same memory is available everywhere: the scheduled agent, a session in another AI tool, and the next automation on a different platform. The plan is free forever, with a 7-day Pro trial that needs no credit card. You can export or delete your data at any time.

Butler gives one execution a clean path from trigger to action. Give the agent a memory that spans runs and tools, and each run starts from what earlier runs learned.

Frequently asked questions

Do Butler variables persist between runs?

No. Variables are replaced by a current value when an automation executes. Nothing stores them for the next execution.

Does a scheduled Butler command remember what it did last week?

No. A calendar command starts a fresh execution on its schedule. Last week's cards and comments remain on the board for people to read, and the new execution does not load them as context on its own.

Can a custom field remember state between runs?

Yes, within limits. A custom field value written by one rule stays on the card until something changes it, so a later rule can read it. The field holds a single value, not the reasoning or conversation behind it.

Can two boards share what Butler learned?

No. Rules, fields, and board state belong to the board where they were created. An execution on a second board starts from that board's cards and fields alone.