Back to blog
Engineering

Why we built human-in-the-loop into every step (not as an afterthought)

Most workflow tools treat human tasks as a gap-filler between automations. We think that gets it backwards.

SV

Saeed Vaali

Founder

15 March 20267 min read

The conventional model

Most workflow automation platforms were built with a clear mental model: automation is the goal, humans are the exception. You build your automated happy path, and when automation can't handle something, you drop in a "human task" as a fallback.

This model made sense in 2015. Automation was expensive to build and hard to change, so you designed around it. Humans filled the gaps.

We think this model is backwards — and it's why so many workflow tools feel wrong for operations work.

The operations reality

In operations, the default is human judgment. Not because technology isn't capable, but because:

  • Business rules change constantly — your approval thresholds, escalation policies, and compliance requirements shift quarterly. Encoding all of that in rules logic is fragile.
  • Edge cases are the point — the value of an operations workflow isn't handling the normal case (that's easy). It's handling the 5% of cases that are unusual. Those almost always need a human.
  • Accountability matters — "the system approved it" is not a satisfying answer when an auditor asks why a $200,000 payment was made. Human approval creates a named, timestamped decision point.

    • How we designed Atomic Work differently

    Every step in Atomic Work has an explicit execution type: AUTO (system runs it) or HUMAN (a person acts on it). Neither is a fallback — both are first-class citizens.

    The APPROVAL step isn't a gap-filler. It's where the business makes a decision. We built it with:

  • Named approver with fallback — not "someone in finance", but "Alice, with escalation to Bob after 24 hours"
  • Context attachment — all input data from previous steps is available inline, no hunting through emails
  • Rejection paths — a rejection isn't an error state. It's a valid workflow outcome with its own path
  • Audit log — every decision, by whom, at what time, with what context, is permanently recorded

    • Why this matters for AI-assisted workflows

    As we add AI steps (the AI_PARSE action, the upcoming AI_DECIDE step), the human-in-the-loop question becomes more important, not less.

    An AI step can extract data, classify a document, or suggest a next action. But when the AI's output affects a real-world decision with real consequences — approve a payment, onboard a new hire, close an account — a human needs to be in the loop.

    We build AI steps as preparation for human decisions, not replacement of them. The AI does the legwork; the human makes the call.

    The product implication

    If you design your workflow with human-in-the-loop as a first-class concept, you get:

  • Clearer accountability
  • Better audit trails
  • Easier compliance
  • Workflows that actually work for edge cases

    • If you design around it as an afterthought, you get workflows that handle 80% of cases smoothly and fail noisily on the other 20%.

    We'll take the former.

    #Architecture#Human-in-the-loop#Design Decisions

    Ready to automate your operations?

    Build your first workflow in under 10 minutes. No engineers required.

    Atomic Work - The Atomic Engine | B2B Workflow Automation