Why We Did Not Build an Automation Builder

A support ticket got auto-assigned to someone on leave. Nobody built that on purpose. Someone had set up a rule eight months earlier — if priority is high and tag is billing, assign to Dana — and then Dana moved teams, and the rule stayed, quietly reassigning billing fires to a person who wasn't checking her queue.

Nobody paged Dana. The automation did. That's the distinction that matters here: a rule doesn't get tired, doesn't get curious about whether it still makes sense, doesn't notice its own conditions have gone stale. It just fires.

The pitch for a builder is always the same

We get asked for this a lot. If X, then Y. If a task sits in Doing for three days, ping the manager. If a client replies, move the card. If a checklist item is checked, create a new task in another project. Every one of these requests is reasonable on its own. Taken individually, each rule saves someone thirty seconds of manual work.

The problem isn't any single rule. It's what a team looks like after eighteen months of individually reasonable rules, written by different people, at different times, for reasons that made sense in a meeting nobody else attended.

What configurability actually costs

An automation builder sells flexibility. What it delivers, over time, is a second, invisible process running underneath the one everyone thinks they're following. The visible process is the board — tasks, statuses, assignees. The invisible one is the net of conditional rules nobody fully holds in their head anymore.

Three costs show up every time we've watched this happen on other tools, including ones we built before this company:

• Debugging burden: when something happens that shouldn't have, someone has to go find which rule did it. There's no single place to look; there's a list of conditions that might have matched.
• Permissions complexity: a rule can move, assign, or notify things the person who wrote it could touch — but the rule keeps running after that person's access changes, or after they leave.
• Accidental process fragmentation: two people write overlapping rules without knowing about each other's, and now the team has two slightly different versions of "what happens when a task is marked urgent."

None of this is a failure of the people building the rules. It's what happens when a team's process lives in configuration instead of in shared understanding. The rules are individually sensible. Together, they're a system nobody designed and nobody can fully explain.

The question we actually asked

Before we wrote a line of code for this, the question wasn't "can we build a rules engine." We can. The question was: does this make the team more understandable, or less? A workflow builder makes a team more capable and less legible at the same time. We weren't willing to trade legibility for capability, because legibility is the thing that lets a team without a dedicated tool owner keep functioning.

That's the actual audience here. Not a company with an ops person whose job is administering the automation layer. A three-person agency. A distributed team where everyone already has a full-time job that isn't "maintain the rules." For that team, a rules engine isn't leverage. It's a second product they now have to learn, audit, and eventually inherit from whoever wrote it.

What we built instead

TAI follows up without being asked, but only in three cases: a deadline is close, a deadline has passed, or a task is still sitting as a Draft. That's it. There's no rule to write, no condition to configure, no second process to audit. You don't build this behavior — it's just what the product does, the same way every time, for everyone.

The tradeoff is real and we're not going to pretend otherwise. You cannot teach it a custom condition. You cannot make it assign tasks based on a tag you invented last Tuesday. If you want "when client replies, do X," we don't have that, and we're not planning to build it as a general capability. What you get instead is a follow-up behavior every person on the team can predict without reading documentation, because there was never anything to configure in the first place.

We'd rather ship fewer things a team has to understand than more things a team could theoretically customize. A rule a team can't explain to a new hire in one sentence is a rule that's already costing more than it's saving.

What this isn't

This isn't an argument against automation as a category, and it isn't an argument that rigid software is virtuous. It's narrower than that. It's that a general-purpose rules engine, handed to a team with no dedicated administrator, tends to produce a second process that outlives the person who understood it. The fix isn't a better builder. It's not building one, and being honest about what that costs you instead.

The ticket that went to Dana wasn't a bug in the automation software. It worked exactly as configured. That's the part worth sitting with.