DEV Community: Piotr Paradiuk

Scaling Local Automations Without Losing Control

Piotr Paradiuk — Thu, 07 Aug 2025 11:51:39 +0000

TL;DR

Automation systems must choose a mutability and control model.
Loose models are fast and flexible, but can override user intent and burn compute quickly under load.
There are semi-controlled alternatives that maintain intent and respect platform boundaries.

Intro

In this post, I explore the design of an automation engine — specifically one focused on operating on local entities.

The goal is to examine how different architectural choices affect user control, execution integrity, and system performance —especially under scale.

The Automation Gold Rush

We’re in the middle of an automation gold rush—or as I called it in Automation at Scale: Why ‘One Item at a Time’ Is Breaking Down, the automation computation race.

Platforms like Zapier, Make, Monday.com, and others are battling it out to win users with the promise of ever more automation tokens—executions per month. The result? An escalating optimization race, where new players must offer tens of thousands of automations per plan just to be competitive.

Some platforms are already falling behind. Take ClickUp, for example—its non-enterprise plans offer under 1-5k automation runs per month, while Monday.com offers 25,000 at a similar price point.

That’s great for customers — scale has never been more accessible.

For developers and platform architects, it means rising pressure to build smarter engines, more efficient schedulers, and cost-aware infrastructure.

Scope and Framing Matter

When designing systems, there’s a trap we all fall into:

Trying to solve everything at once — retries, APIs, audit logs, cross-region state, failovers.

Those all matter — but not at the start.

Think of the system like a massive whiteboard that doesn’t fit on one screen. To make progress, you need a minimap—a way to zoom in on the part that matters right now, without getting distracted by everything else.

In this post, we’ll focus on one specific layer of the system:

A self-contained, local-only automation engine.
Built to resolve conflicts between users and automations.
Designed to scale up cleanly — not get tangled in global queues.
External triggers? Future work. We're zoomed in for now.

Fast Track vs. Slow Track

From the start, we’ve drawn a clear line between local and external executions.

This distinction isn't just technical—it's philosophical.

External executions come with significant overhead: failover policies, authentication layers, networking dependencies, rate limiting, retries, monitoring, and more. Designing them well requires a different focus.

In contrast, local executions are where the platform has full control: integrity is managed by the domain model itself, latency is minimal, and automation can provide immediate feedback to the user. These are the "fast track" paths — our focus.

Even if we later support external actions, the kernel should still operate independently — as a self-contained engine inside the platform.

Designing the Kernel

Let’s zoom in on the kernel — the beating heart of the system.
It listens for changes, matches relevant automations, and applies them safely.

It assumes that:

Both users and automations can mutate the same item.
These mutations may overlap or conflict.
Our job is to resolve that gracefully, without external queues.

Let's sketch a conceptual draft:

The highlighted section (in red) shows the primary “blood flow” of our automation engine.

Execution starts with a change — from the UI or an automation. A trigger listener catches it and hands it to the engine.

The engine finds matching automations and creates intents — lightweight plans for what will happen. These don't run right away. A scheduler steps in to merge, deduplicate, and throttle them in a short time window. This smooths out bursts and avoids waste.

Once ready, each intent goes through a state manager, which compares it to the current state. If the change is valid, it’s committed to local storage.

This is our execution core.

Here’s how this flow looks in action, using a CodePen demo:

Three Control Models

To further ground this discussion, let’s use the example of Monday.com, a task management system where automations revolve around “items” (essentially structured tasks). Think of items as interactive graph nodes for users: they carry state, history, and serve as the control points of the system.

We can imagine three models for how Monday-like automation might behave:

1. High-control – A strict, deterministic model where automation executions are immutable once started. Think: banking transactions. If a transfer begins, its execution path is locked—even if the automation definition changes later. The old run follows the old logic.

2. Loose-control – Automations simply mimic user actions. Everything is mutable. If two automations change the same item at the same time, the system doesn’t enforce order or consistency. Power and responsibility lie entirely with the user.

3. Semi-control – A hybrid. Some operations compete and override each other. Others are locked or atomic. The user can choose which logic to enforce where.

It's worth considering: which of these models best fits real-world use? And how would the answer change if we scoped it to only local, fast-path operations?

What Monday.com Actually Does

Monday.com today leans toward Loose-control.

You get:

Automations (available on all plans)
Workflow Builder(available only in Enterprise plan)

These tools look similar conceptually, but they differ in execution design. I’ve written a deeper breakdown in The Product Tension Between Automations and Workflows in Monday.com.

Key difference:

Automations run per-item, with an execution delay of ~1–2 seconds - as documented in Infinite Cycles in Monday.com Automations.
Workflow Builder executes broader item flows from start to finish.

Why the Delay Exists?

Because the system is highly mutable — like a shared task list where multiple agents can reorder or change the status of any item at any time.

Each agent (automation or user) is allowed to queue an action. Automation actions are throttled and delayed, typically executing after ~1-2 seconds.

Some changes overwrite previous ones (e.g. setting status to “Done” replaces “Stuck”). Other changes add up, like moving a task repeatedly.

As a consequence, no one has absolute control — all changes are respected, just not immediately.

This makes the system intuitive for users — changes feel like they’re "live".

In this model, in case of conflict resolution - last action wins. That’s reasonable when all actions represent clear intent.

A Real-World Conflict Example

Let’s say we've got an automated scenario with the following flow:

If status is New, change it to Working on it
If status is Working on it, change it to Testing
If status is Testing, change it to Stuck

But what if someone marks it “Done” manually during step 2?

It gets overridden. That creates confusion, especially when automation volume increases.

This is where loose-control systems show their limits.

You can see the override clearly in the activity log:

Key takeaway: once an automation starts, the trigger cascade finishes even if you try to step in.

Where Loose Control Breaks Down

The loose model breaks down in two key cases:

1. Control workflows

Think of something like user onboarding. Once a task starts, you don’t want updates to interfere with it. The flow must be protected—locked or isolated—until it completes.

2. Execution caps

Let’s say our plan includes only 1,000 automation runs per month. If the automations fire instantly—reacting to every user action — they can burn through that quota surprisingly fast.

In highly mutable systems, where both users and automations can update the same entity rapidly, it’s worth considering scheduling - as a way to preserve intent and avoid waste.

Toward a Semi-Control Model

Let’s evolve the kernel. In a semi-control model:

We add an isLocked flag to key automations.
When triggered, the item becomes read-only to users.
A lock icon appears to explain why.
Once automation completes, the lock is lifted.

The semi-control scenario allows us to go further:

Not all automations need to run immediately. Locking intentionally can help us optimize performance.

For example, if we're 90% into our quota, we can slow execution, delay triggers, or group updates into a batch — as explored in Automation at Scale: Why ‘One Item at a Time’ Is Breaking Down.

In such cases, we can intentionally slow down execution — stretching it from 1–2 seconds to longer intervals — or even allow users to choose between real-time and scheduled execution.

This saves compute without breaking logic.

Wrapping Up

I hope this was a fun and hands-on way to explore the automation design.

Takeaway: We don’t need to solve for every edge case on day one.

Start with fast, local flows. Pick the right control model. Respect user intent.

Imagine if RFCs for platforms came with playful, interactive design snippets like these—not just showing what the system should do, but why it behaves the way it does.

Who knows - Maybe the next gen of RFCs won’t just explain systems — they’ll let us experience them.

What We Learned

Local-first kernels keep systems responsive and predictable.
Semi-control gives us both speed and safety.
Intent-driven scheduling reduces wasted work.
The right control model is a balance — not too rigid, and not too loose.

The Product Tension Between Automations and Workflows in Monday.com

Piotr Paradiuk — Thu, 07 Aug 2025 11:44:04 +0000

TL;DR

Monday.com Automations are perfect for simple tasks, but not built for full logic. As users push their limits, the need for a middle-ground between Automations and full Workflows is arising.

Key takeaways:

Automations are fast, simple robotic arms for A→B tasks.
They override manual edits if triggers are already queued.
Workflow Builder handles complex, multi-step logic (available on higher tiers).
Pro user feedback suggests demand for more: a simplified workflow tool could bridge the gap, reduce confusion, and drive product growth.

The story

Automations are a fun and helpful tool in your Monday.com toolkit. But as your needs grow — especially when you want to add more trigger conditions—you may find yourself duplicating nearly identical automations, which can feel repetitive.

A popular Community Hub post with over 10K views and 336 upvotes highlights this friction: the Pro plan automation builder lacks logical operators like OR and NOT.

The answer to this challenge isn’t that Monday is deliberately withholding this functionality. The reason lies in the design of Automations — they were originally not intended to be full logic engines.

Automation ≠ Workflow Engine

Let’s clear up the core idea:

Monday.com Automations and Workflows may sound similar to Users at first glance — but they are designed for very different jobs. And so is their nature.

When you look at Automations — you should think of them as simple robotic action triggers — let's call them robotic arms. They perform programmed tasks at a ratio of ~1-2 seconds as shown in Infinite Cycles in Monday.com Automations. At any time you can pull the plug and halt any of your automations and it will come to a stop.

What Happens During Conflicts?

Let’s say you have three automations:

If status is New, change it to Working on it
If status is Working on it, change it to Testing
If status is Testing, change it to Stuck

If you manually change the status to Done between steps 1 and 2, your change won’t stick. The automation will override it. Why? Because another trigger was already queued.

You can see this clearly in the activity log:

Key takeaway: once an automation starts, the trigger cascade finishes even if you try to step in.

I hope by this practical example above, you are beginning to see how automations are simple and differ from a classic workflow or control graph.

When You Need More Power: Workflow Builder

Now imagine a complex client onboarding flow, with conditions, approvals, and branching logic. Automations alone won’t cut it. That’s where the Workflow Builder shines.

It lets you build connected, conditional logic flows — something automations simply aren't built to do. Think of Automations as A→B, while Workflows are A→Z, with logic gates in between.

A Thought for the Roadmap

Monday.com’s automation builder is delightful—clean, visual, and beginner-friendly. And the enterprise Workflow Builder covers advanced needs beautifully.

But community feedback suggests Pro users are already trying to stretch Automations into workflow territory. That’s a strong signal that users are ready for more.

Luckily, there may be a sweet spot in offering a simplified Workflow Builder for Pro users — perhaps scoped to a board, or with limited conditions. This would:

Reduce user confusion around logic limits
Showcase the potential of workflows early
Build upgrade interest through hands-on experience

Final Thoughts

Automations are great. But they’re not workflows — and that’s okay. As platforms like Zapier and Make.com expand, the hunger for advanced automation will only grow.

Monday.com has a unique opportunity here: evolve automation into mini Workflows gently, without losing the simplicity that users love.

Thanks for reading—and kudos to the Monday team for creating such a flexible platform. I hope this adds to the conversation!

Toward Cycle Detection in AI automation workflows

Piotr Paradiuk — Thu, 07 Aug 2025 11:38:31 +0000

TL;DR

Cycle detection in no-code/automation tools is often neglected — even though it's critical for user safety. This post explains:

Why non-tech users are vulnerable to loop errors
How AI (and LLMs) fail at graph-level reasoning
How to detect cycles in JavaScript using Graphlib
What's missing in today's tooling — and how we can fix it
Why visual loop safety is a UX problem, not just a backend concern

The Story

Automation is now table stakes in AI-enabled platforms. Prompt-chain editors, workflow builders, and logic engines are popping up in nearly every product category — from marketing to dev tools.

Despite the competition, few platforms have proper implementation of cycle detection.

Side note: Notably some tools have n-loops (aka repeaters) in their workflow, but it doesn't cover loop detection rather it actually allows for a certain amount of repeats.

The human factor

Humans get overwhelmed quickly when working with large graphs. Managing an 80–90 node decision tree? It’s easy to accidentally create an infinite loop — especially for non-developers, who make up a large share of users on workflow platforms

These systems are meant to let humans focus on intent, not technical structure. But let’s be honest — today’s AI-powered workflows are starting to look like miniature neural networks:

Why cycle isn't just a fancy dev word

In production, unnoticed cycles can trigger unnecessary API calls, data duplication, or even billing nightmares — especially in pay-per-execution platforms.

It's rarely a good idea or user intent to spawn a flow that just keeps repeating itself. The UI should clearly notify users when their graph contains a loop that prevents execution.

This isn’t just a technical safeguard — it’s a UX imperative. If a user can’t see that they’ve built a loop, or doesn’t understand why their automation breaks, the failure becomes a design problem, not a logic one. Visual loop safety is about clarity, not just correctness.

It's harder to detect infinite loops when data travels back and forth different integrations and comes back to the target platform, but it's surely a job we can do when designing data flows in the platform itself.

Real world scenario

In Infinite Cycles in Monday.com Automations, I've described how Monday.com automation allow infinite loop in their automations (and also smartly protects itself from negative consequences).

Side note about AI

If you pondered whether AI could help you find infinite cycles in your workflow, recent studies show that graph analysis — especially dynamic semantics like control flow or AST traversal — is one of the weak points for large language models (LLMs).

“Our study highlights that while LLMs have a talent for understanding code syntax, they struggle with comprehending code semantics, particularly dynamic semantics… which include abstract syntax trees (AST), control flow graphs (CFG), and call graphs (CG).”
— LMs: Understanding Code Syntax and Semantics for Code Analysis, Ma et al. (2023) https://arxiv.org/abs/2305.12138

Looks like a job for a human

So what can we use in the JavaScript ecosystem — the world’s most popular frontend stack — to detect loops directly in the browser?

We'd need a multigraph edge-aware ability to find cycles. Each edge could be an entirely different automation trigger, and we don't always merge all processes together. Process are often quite independent recipes.

Well, in JS world, there is Graphlib

Graphlib does support multigraphs ({ multigraph: true }).

But: its alg.findCycles() does not differentiate between parallel edges (i.e., multiple edges between the same pair of nodes).

That means it will properly recognise cycles, but it will not distinguish whether it was edge e1 or e2 from A → B that formed the cycle.

In complex automations, where multiple rules connect the same steps under different conditions, this limitation can make it hard to trace which specific rule or edge is creating a loop — frustrating users who just want to fix the problem.

Another library graphology also doesn't natively track edge-aware cycles in multigraphs.

While there's clearly a gap in the JavaScript ecosystem for formally enumerating edge-specific cycle paths, I'll stick to a simple detection for now using graphlib to demonstrate how using graph lookup we can prevent cycle loops.

Data structure

As mentioned before, many tools allow customers to create infinite cycles. In example below you can see a cycle between 'Working on it' and 'Stuck' Statuses.

Here is how the above data is represented in Monday.com automation data -- while it's not a graph, we can use this format to detect nodes that have similar trigger and statusColumnValue.

{
  "automations": [
    {
      "id": 133547104,
      "config": {
        "0": {
          "statusColumnValue": {
            "index": 0
          }
        },
        "1": {
          "statusColumnValue": {
            "index": 2
          }
        }
      }
    }
  ]
}

Now let's convert this into graph, and analyse the cycles with Graphlib.

Side note: Graphlib uses Tarjan algorithm, see: https://github.com/dagrejs/graphlib/blob/master/lib/alg/find-cycles.js

After streaming the automation json format from Monday.com into graphlib, it properly detects cycles:

import graphlib from 'graphlib';
const { Graph, alg } = graphlib;

/**
 * Builds a directed graph using integer status indices as nodes.
 * @param {Array} automations - Array of automation config objects
 * @returns {{ activeGraph: Graph, fullGraph: Graph }}
 */
export function buildGraphs(automations) {
    const activeGraph = new Graph({ directed: true });
    const fullGraph = new Graph({ directed: true });
    automations.forEach(auto => {
        const from = auto.config["0"].statusColumnValue.index;
        const to = auto.config["1"].statusColumnValue.index;

        fullGraph.setEdge(String(from), String(to), `automation #${auto.id}`);
        if (auto.active) {
            activeGraph.setEdge(String(from), String(to), `automation #${auto.id}`);
        }
    });

    return { activeGraph, fullGraph };
}

/**
 * Finds all cycles in a graph where a path loops back to the same node.
 * @param {Graph} graph
 * @returns {Array<Array<string>>} - Array of node paths forming cycles
 */
export function detectCycles(graph) {
    return alg.findCycles(graph);
}

Combine this with a simple test..
source: https://github.com/piotrdiuk/graphoman/blob/main/test/graphDetection.test.js

...and we'll get:

Nodes: [ '0', '2' ]
Edges: [ { v: '0', w: '2' }, { v: '2', w: '0' } ]
Cycles detected: [ [ '2', '0' ] ]

This confirms that Graphlib detects the cycle properly — but not the edge-level detail.

While this basic approach works for flagging loops, a more robust solution should:

Track which edge (or automation) causes the cycle
Prioritise flagging the recipe that breaks most connections,
Allow per-recipe cycle isolation,
Offer actionable feedback to users.

Toward Better Workflow Safety

The next step is designing a universal, edge-aware graph format that can represent automations with full traceability: not just "there's a loop" — but "this specific automation causes a loop from A to B to A".

That format should be:

Easy to generate from automation data,
Friendly to visualisation tools,
Ready for plug-in cycle-checkers or debuggers.

Because in the end, automation should empower non-technical users — not trap them in invisible accidental loops.

Cycle safety isn’t just a backend concern — it’s a product experience issue. If loops confuse or block users, that’s on the tool, not them. Every invisible loop puts the user at risk of frustration, wasted time, and broken trust. Smarter graph tooling, even something as lightweight as Graphlib with custom edge tracking, brings us one step closer to reliable, human-friendly automation.

Let me know if you know or are building something similar to help tackle this challange in JS!

Infinite cycles in monday.com automations

Piotr Paradiuk — Thu, 07 Aug 2025 11:35:48 +0000

Tl;DR

As of 2025, Monday.com runs on a rock-solid tech stack — Redux, Pusher.js, and more — enabling real-time automatic updates. But one key thing is still missing from its automation engine: cycle detection.

Key take-aways:

Users can accidentally sabotage themselves with loops and burn their 25k+ executions
Monday protects itself with throttling, but users are still exposed
A simple (A → B + B → A) check could solve this

A Peek at the Technical Solution

I’ve published a deeper technical post on how to detect cycles in JS-based multigraphs using Graphlib in Toward Cycle Detection in AI Automation Workflows.

Spoiler: as of 2025, there's still no native JS library that handles edge-aware cycle detection for multigraphs.

The story

The villain of the story resides in automations (available in the free plan) - where it's possible to create something that every developer loves - an infinite loop ∞.

Fortunately, Monday uses a time-based throttling mechanism. Each automation tick executes with a delay (~1–2s between updates). This prevents instant overload, but still means that a board with 1,000 items could experience severe lag if each item is being mutated continuously by an automation loop.

As seen in the execution history, each automation runs with a ~1–2 second interval. That is a good indication that it likely doesn't hit a complex server-side event bus — but executes the mutations locally, much like user actions.

That's something that Monday does very well - board items are extremely mutable, and merges of user actions happen instantly.

Yet, I think it's a safe bet to say that creating 1k items and making them tick individually for infinite time is definitely gonna have a negative effect - considering the changes are streamed per item and not in batch.

That's one of the system design decisions made in Monday, that seems to make sense when you look at the platform on a high level. It'd hard to batch items for execution when each can have transitive states.

That said, under the right conditions, a form of conditional batching becomes not only safe — but strategically valuable. I explore this in more detail in Automation at Scale: Why One Item at a Time Is Breaking Down, including how platforms can batch intelligently without sacrificing correctness.

Fortunately Monday.com comes with a simple power plug here - after 25k automation runs on Pro Plan - it's game over. No more runs.

It’s generous — Monday’s Pro plan allows up to 25,000 automation runs — far more than ClickUp’s 1k–5k limit or Zapier’s pricing tier for 20k Zaps (~$160/month). Still - this rate is vulnerable if users unknowingly burn through it with a loop.

Zapier’s pricing gets expensive fast — 20k Zaps costs over $160/month.

As demonstrated, there is a real 'war' for computing power in the automation builder platform world.

Implications for Customers

We established that Monday does a pretty good job in offering high automation execution rates, and limiting the interval in which they are fired which protects customers from instant execution depletion.

Yet, there is still a scenario where customers may unwillingly sabotage their own account.

Imagine a case where you have 30-50 automations (which actually happens according to Community blogs)

Say you delete one automation — thinking you’re cleaning up. But that deletion breaks a subtle dependency, and now 1,000 items on your board start ticking in a self-referencing loop. Your 25k monthly automation limit? Gone in minutes. 😬

A Simple UX Proposal: Detecting Cycles Visually

From UX/UI perspective it sounds simple:

when (A → B) + (B → A) ⇒ show warning / prevent save.

Monday already uses toast messages to warn users — so surfacing loop conflicts visually would fit their existing UI patterns. You could even highlight conflicting automations and gray out the "Save" button until resolved.

Here this may just not be enough - you might want to highlight the conflicting automations and find the last conflicting cycle and freeze the recipe that is causing it:

(Slightly more verbose sketch of loop prevention)

Now, this isn't to say that Monday has to explicitly block infinite loops - but they can at least warn User of the risk involved.

In fact some companies went as far as to block repetitive cycles upon hitting certain execution threshold, but that's a scenario that should usually be avoided (it can interrupt a crucial user network).

Potential Trial-Based Synthetic Load Attack

Let’s take this a step further: imagine someone spins up trial accounts and sets up infinite loops across thousands of items. Since automations are server-side operations, no active user input is needed — just a ticking time bomb that eats through 25k executions, spiking load.

As Monday scales and raises rate limits to stay competitive, it may also become more vulnerable to synthetic load attacks — especially from trial users exploiting infinite loops.

When analysing logs it may also be relatively hard to find actors who have crossed a certain threshold of operations if items would be removed occasionally.

Obviously for this kind of stress test that would mean an enormous inflation of per item logs (I generated around 120 ticks in 1-2 minutes):

As mentioned on monday.com technical blog - there is occasionally an issue with noisy customers stressing the shared traffic bandwidth. Silent infinite loops like this are one of the things that may be harder to detect in the huge lake of customer data, and can silently generate traffic costs.

So at this scale we occasionally observed individual users generating 20-30% of the overall system load! We needed a way to quickly (in a matter of minutes) discover such individuals and take some precautions. This phenomenon is often called noisy neighbor and it doesn’t only apply to cloud hardware being overutilized by other tenants. For the time being, we simply ban problematic user accounts for a few minutes.

Conclusion

Monday.com does a great job balancing speed — but invisible automation loops remain a real risk. Execution throttling and quota caps help protect the system, but users are still vulnerable to accidental sabotage.

A simple cycle detector — even just a UI warning — could go a long way in protecting both users and the platform from runaway automations.

Automation at Scale: Why ‘One Item at a Time’ Is Breaking Down

Piotr Paradiuk — Thu, 07 Aug 2025 11:29:49 +0000

TL;DR

Automation platforms are turning into CPUs — they just don’t realize it yet.

Like early processors, most automation systems still execute every trigger in isolation. But as scale, cost, and latency pressures rise, this model breaks down.

The next leap is to treat automation like compilers or LLM engines: detect shared logic, batch similar work (aka hot path), optimize the graph — not just react to every trigger individually.

Batching is often avoided due to fear of side effects from transitive state changes. But under the right conditions — when items share state, logic, and no dependencies — conditional batching becomes both safe and performance-critical. It’s a latent superpower waiting to be unlocked in platforms already strained by their own flexibility.

The Computation Race Is On

Thanks to AI, we’ve entered a new era in workflow automations — one defined by compute budgets, latency races, and infrastructure constraints. Let's call it what it is: the computation race.

Every modern automation engine is locked in a quiet arms race to:

Cut compute cost per automation.
Increase throughput under load.
Reduce lag without compromising correctness.

Why? Because compute cost shapes pricing. The more efficiently automations run, the more generously a platform can structure its plans.

Just look at Make.com’s pricing — the “Ops” selector is one of the first decisions a customer makes:

As users create more workflows and expect real-time responsiveness, the old model — process each item one at a time — starts to break down.

Two sides of the story

There are two angles to automation optimization:

1. User-side: How users structure and trigger automations

2. Platform-side: How the system processes those automations under the hood

Let’s explore both.

User-Side: Real-Time vs. Batch-Aware

Consider this common workflow:

1. Real-Time Per-Item Automation

Trigger: When a project is marked "Complete"
Action: Call external invoicing API to create invoice

If 100 projects are completed in a day, the system fires 100 API calls. Each one carries overhead — auth, retries, latency. It feels immediate, but it’s noisy and costly at scale.

2. Batch-Aware Automation

Trigger: When a project is marked "Complete" → Add to 'Ready to Invoice' queue
Scheduled Automation: Every day, send a single API request with a batch of all pending projects

Same business logic — 100 invoices are created. But now: 1 automation run, 1 API call, fewer retries, less noise, better scaling.

Suggest It in the Builder

Platforms could detect high-volume, per-item trigger patterns and suggest batch-aware upgrades. This is where AI-assisted automation building comes in.

"Looks like you're creating an invoice every time a project is completed. Want to switch to hourly batch invoicing instead?"

The outcome is the same. The performance cost isn’t.

What we can learn from JVM and LLM

I'd go as far as to say that I'd let my automation runtime suggest such "hot path" optimisations as explained above.

In the JVM, HotSpot profiling identifies "hot" paths (frequently executed code), and rewrites bytecode on the fly with faster native instructions. It inlines methods, eliminates dead branches, and reorganizes memory based on real workload characteristics.

In LLM, PyTorch tracks frequently-used computation graphs. It also uses JIT (just in time) compilation (via TorchScript) to trace and compile hot subgraphs.
Operator fusion combines layers into a single fused operations.

Platform-side (computation race)

Let’s switch to the platform's challenge fully: offering efficient automation runs while keeping infrastructure costs low.

Every "when X then Y" hides a chain of processes: queuing, state validation, dependency resolution, retries, failure handling, side-effect isolation. Multiply that by millions of users triggering millions of events, and the difference between linear and batched execution becomes existential.

Batching or ("Hot Pathing") enables:

Dependency flattening — Resolve shared lookups once, not per item
State scoping — Compute shared logic across similar items
Throughput scaling — Use batch APIs, optimize reads, amortize costs

Platforms that lean into batching win — not just in performance, but in pricing, latency, and developer ergonomics. They aren’t stuck paying the per-item tax.

Isolation Is Safe — But Expensive

On the surface isolation makes sense: when each item can have transitive states and trigger cascading actions, batching introduces uncertainty. If updating item A causes item B to change state, then grouping items A and B in a batch could lead to race conditions or misordered side effects.

In other words, individual execution ensures isolation — and isolation ensures safety. That's valuable.

Here is how we can observe per-item-isolation in Monday.com automations where I created a simple trigger of status change from 'Working on it' to 'Stuck'.

GIF

In the example above, web socket brings the mutation of each record in a seperate request. This safety comes at a cost: reduced throughput, increased infrastructure usage, and higher latency when dealing with large volumes of items that are eligible for automation at the same time.

So the question becomes:

Can we batch some items conditionally, without sacrificing correctness?

No-brainer batch cases

Some cases are obviously batch-safe:

“Change status of 250 items to ‘Done’”
“Assign 10 items to John”
“Delete 80 items”
“Archive 12 items”
“Duplicate 15 items”
“import item collection”

These can be easily triggered in batch on backend, and still be sequentially replayed on the frontend if needed: (e.g., “Running Automation on items 1…2…3…”) - or updated in one shot (depending on the scenario).

Other cases are trickier. Consider known cascade zones — like a status → status → webhook chain. Detecting and batching those safely takes design foresight.

What Makes Transitions 'Batchable'?

To be safely batchable, a group of items should:

Be in the same state
Trigger the same logic
Have no direct or indirect dependencies

But enabling this isn’t just about checking flags. It requires the automation engine to develop a degree of self-awareness — the ability to reason about:

Is this automation pure or mutative?
Does this action cause side effects?
Is this rule idempotent and order-independent?

In other words, the platform needs to understand what kind of work it's doing — not just execute logic in a blind, item-by-item loop.

This shift — from reactive ticking to introspective execution — is what unlocks batching as a safe, composable primitive in large-scale automation systems.

Why It’s Rare — But Strategically Valuable

Most automation platforms don’t support conditional batching — not because it’s a bad idea, but because it’s hard to retrofit into flexible, trigger-based architectures.

Users can define complex logic, create circular dependencies, or rely on item-specific side effects — all of which make batching risky.

But in many cases — stateless rules, disjoint segments, simple state transitions — batching is not just safe, but better.

Some enterprise tools already expose batch-aware options like:

“Run once per group”
“Run once per hour on matching items”

These unlock intelligent scheduling and reduce system load without breaking correctness.

Toward Batching-Aware Automation Models

Implementing conditional batching requires a rethink of automation internals. Options include:

Static analysis of automation rules to determine side-effect scope
Dependency graphs between items to detect safe partitions
Execution labeling, tagging automations as batchable or not
Explicit batching hints from users or templates

This isn’t trivial. But as automation scales from hundreds to millions of events per hour, platforms will need to get smarter about execution, not just faster at running one-off jobs.

Conditional batching is one such smart move.

Conclusion

Conditional batching and hot pathing is a quiet superpower.

Not a shortcut, but an evolution — from reactive ticking to shared understanding.

It’s how automation platforms can win in the computation race.

Think of this: Platforms like OpenAI or Anthropic couldn’t survive if they treated every token as an isolated compute unit. They batch, compress, and share as much as possible — and that’s exactly what modern automation platforms must do as user workflows scale and become more complex.