Does Coda Remember Between Runs?

No. A Coda automation holds no memory of its own between runs. Each run starts from the doc as it stands at that moment: the rows in the tables, the values in the columns, and the trigger that fired it. Anything a previous run learned, decided, or worked out survives only if that run wrote it into a table, a page, or a column first.

That distinction is easy to miss because a Coda doc feels continuous. The same tables, buttons, and rules are still there tomorrow, and a daily rule still fires at the same time. The continuity lives in the doc structure and in the data stored in rows. It does not live in a memory that one run hands to the next.

What does a Coda doc actually hold?

A doc holds structured data. Tables hold rows, rows hold column values, and pages hold text and embedded views of those tables. A task table can hold the task name, the owner, the status, the due date, and any notes typed into a details column. A tracker can hold every entry added to it, in order, for as long as the rows stay in the table.

That stored data is real persistence, and automations can read it. A formula can count rows, look up a related row, or check whether a status changed. A rule can filter a table and act on the rows that match right now.

The scope is the table. What persists is what was deliberately saved as a row or a value. The reasoning behind a change, the options a run considered and rejected, and the thread of an earlier discussion are not in the table unless someone typed them into a column. A new run reads values. It does not recover the conversation that produced them.

What do automations remember?

Automations in Coda are rules with two parts: When and Then. The When is a trigger, such as a row being changed, a time on a schedule, a button press, or an incoming webhook. The Then is one or more actions, such as adding or editing a row, sending a Slack or email notification, pressing a button, or running a formula or a Pack action.

Every run of a rule is a fresh execution of that definition. A scheduled rule that sends a morning summary reads the current rows, builds the summary from the values it finds, sends it, and ends. Tomorrow's run builds a new summary from tomorrow's rows. The rule does not retain yesterday's summary, the list of items it already reported, or a note about what changed since then, unless the doc stores that state explicitly, for example in a helper table that each run updates.

Buttons follow the same model. A button runs its actions against the row and the doc in front of it. Pressing the same button twice runs the same actions twice, from the current values each time. Packs extend what a run can reach, pulling data from connected tools or pushing updates out to them, and the result of a Pack action persists only where it lands: a synced table, a written value, or the other tool.

What about formulas and Coda AI?

Formulas are calculated from current data. A formula column shows the result for the row it sits on, based on the values referenced at that moment. Change an input and the result updates. The formula keeps the result, not a history of earlier results or the reasons behind them.

Coda AI works the same way, from the doc in front of it. An AI column generates text for a row from a prompt and the columns referenced for that row, and the generated text is stored in the column. The assistant can answer questions and help draft content based on the doc it can see. Neither feature carries a running thread from one automation run, one day, or one working session to the next. Each use starts from the stored data, not from a remembered conversation.

Where this leaves agents working from Coda

A common pattern is to use Coda as the control room for automated work: a table tracks leads, tickets, content, or tasks, and automations or AI agents act on the rows. Each run receives rows. Rows are good at status and bad at context.

So an agent working from a Coda table wakes up with the current status and nothing else. It can see that a lead is marked contacted, a ticket is marked waiting, or a draft is marked approved. It cannot see what the last run promised, what the customer already explained, which approach was tried and dropped, or why a status was set. Teams fill the gap by adding more columns and longer notes fields, and by re-briefing the agent on every run. The table grows wider while the actual thread stays scattered across messages, calls, and earlier runs.

Give every run one shared memory

The fix is to put the memory outside any single doc, in a layer every run reads before it acts and writes to after it finishes. That is what Vilix AI provides for agents and automations.

Vilix AI is cloud-hosted, so there is zero infrastructure to run or maintain. Connect it once over MCP and the same memory is available everywhere the work happens: inside Coda-driven automations, in n8n, Make, or Zapier flows that read the same tables, and in the chat tools used between runs. The memory holds full conversation history, not just extracted facts, so a run can recover what was actually said, decided, and promised, in context, instead of reconstructing it from status columns.

In practice, a run starts by retrieving the history behind the rows it is about to touch: prior decisions, open questions, and what the last run already did. It acts with that context, then saves its own outcome back to the same place. The next run, whether it fires in an hour or next week, starts from that accumulated state. Coda keeps doing what it does well, holding the tables and firing the rules, while the agents around it stop starting over.

Getting started takes one connection, not a rebuild. Get Started for Free

Free forever, no credit card. The free plan stays free, the 7-day Pro trial needs no card, and your memory stays yours: export everything or delete it anytime.