Automation patterns: how tables turn workflows into systems
Unlock statefulness, flexibility, and scalability by anchoring your workflows in tables
Introduction
When people talk about “AI agents” in the LinkedIn hype-o-sphere, they tend to describe fully autonomous digital workers—LLMs thinking, planning, and acting with a high degree of freedom.
In reality, most effective agentic systems I’ve seen don’t look like that at all.
The most common advice I’ve seen from people building resilient systems is:
Use AI as little as possible.
It sounds counterintuitive, but the same qualities that make LLMs powerful—flexibility, creativity, adaptability—also make them unpredictable and fragile.
The goal is to harness the power of an LLM in a tightly scoped role and wrap it in safe, boring automation.
With that in mind, this post kicks off an occasional series on automation design patterns I’ve found useful in the wild.
Note: I build mostly in Zapier right now, but the same ideas apply whether you're using Workato, N8N, Make, or other tool of choice.
Pattern #1: use a table as the memory of your workflow
Thanks to the huge popularity of Clay, the table has become a familiar UI for enrichment and research workflows. But tables unlock all sorts of useful capabilities for any automation system.
These days, almost every project I build has a table at its heart.
I’m a huge fan of Zapier tables—especially as table actions don’t count as tasks!—but the same logic applies when using a Google Sheet, Airtable, Postgres, or whatever.
Statefulness: giving your workflow a history
Statefulness means your workflow remembers what has happened before.
In a stateless system, each run is isolated—it doesn't know what came before or what comes next.
In a stateful system, you can track progress over time, coordinate steps across different workflows, and handle long-running processes more reliably, because there’s memory.
You’re no longer trying to execute an entire process inside a single workflow run. Each record becomes its own thread of execution.
Long processes can unfold asynchronously
Separate workflows can pick up where others left off
You get modularity, sequencing, and control
Statefulness transforms isolated workflows into systems that behave more like software.
Example: using a status field
When building a system to fetch outbound signals from a third-party API, I use a table to manage each record’s lifecycle.
Each row gets a status—Pending, Processing, Complete—so I can track track progress at a glance.
Scalability: handle volume without breaking the system
Working with larger volumes of data can become challenging in linear workflows.
Tables remove the need to handle all your processing in one big run.
A table unlocks patterns like:
Worker/Queue architecture: one process populates the table, another decoupled process consumes and acts on that data.
Retry mechanisms: failed items can be updated and retried by a safety net workflow without re-running the whole flow
Concurrency control: manage volume, rate limits, and third-party bottlenecks more gracefully
Example: worker/queue architecture
I was working with an enrichment API that provided very verbose results.
Even working well below Zapier’s looping rate limit of 500 iterations, I would quickly bump into their (as far as I know) undocumented data volume limits or 30 second processing limit on a code step.
By splitting my workflow into two main parts—a search Zap that identified records and logged redemption IDs into a queue, and a worker Zap that redeemed and processed each row individually—I bypassed all these limits easily. I also made the system much easier to monitor and debug.
Observability: easily monitor and debug your system
A table is a living snapshot of what your system is doing. That makes it:
Easier to debug
Easier to explain
Easier to trust
It’s easy to understand the “story” of a run without digging through logs. You can see what’s stuck, what ran successfully, and what needs review.
For AI-powered workflows especially, this is critical, because the outputs aren’t always predictable. Having a place to inspect them gives you a much tighter feedback loop and a much-needed sense of control.
Example: tracking multi-agent hand-offs
In a workflow of multiple Dust agents, Zapier controls the hand-offs between each step.
Using a table to log the outputs of each agent’s work with a date stamp makes it easy to trace where a process failed (the gaps in the table).
It also provides a place to store those outputs outside the workflow run so they can be easily consolidated at the end of the process.
Architectural flexibility: change parts without breaking the whole
Once you have a table in the middle, you gain options.
Retry only the rows that failed
Run downstream steps on a delay or schedule
Pause execution for human review
Swap components in and out without breaking the chain
The table becomes a buffer—a place where systems meet and async work can wait its turn.
Example: hot-swapping design patterns with no downstream impact
I was using a scheduled Zap with a code step to paginate through an API’s results, but the output was too big to process in a single run.
Since I was using a table to log intermediate results, I could easily modify the architecture to work around this restriction:
I changed the workflow calling the API to a webhook-triggered Zap.
I made the scheduled Zap call this webhook to kick off the process.
I restricted each API call to a single page of 100 records, logged them to a table, and then passed the token for the next page of results back into the same Zap, triggering it to run repeatedly.
The Zap runs end when there are no more results or when we reach a system-defined limit that I can control.
This approach bypassed platform restrictions and had no impact on downstream workflows, because they were loosely-coupled by the table.
In summary
This one pattern—adding a table—can completely change how you approach system design.
It makes your automation stateful, visible, and resilient. And once you have that foundation, incorporating AI effectively becomes a whole lot easier.
Good ol’ tables. Powers so much behind the scenes. Great breakdown here on why they are so useful