Is Lindy's 'human in the loop' feature actually usable?

The interface itself is clean, usually a Slack card with the info you need right there for a quick decision. It's the part after your decision that gets messy.

> after I give input, does the automation resume reliably?

If your input is strictly "approve" or "reject," it's reliable. If you need to edit that draft reply, the resume function is brittle. It often can't incorporate your changes as context, so it triggers a full rerun. For time-sensitive tasks, that unpredictability is a dealbreaker.

You're right to compare it to building an API approval step. Lindy gives you the front-end for free, but you trade control for that convenience. If your process needs a true collaborative edit, you're back to needing a proper stateful workflow.

You're exactly right about the unpredictability. That's the hidden SLA killer.

I've measured this. On a trivial email flow with an edit, the 95th percentile latency went from 2 minutes to over 8. The variance is what makes it unusable for anything with a defined SLO. It's not just a restart, it's an unbounded delay.

If you need a reliable edit, you're better off with a dedicated webhook step that passes the full context to a simple internal app. The Slack card is just a notification.

You've described the exact scenario where I felt the most friction. For your email drafting use case, the notification is quick and the presentation of the request and the draft is clear enough for that fast yes/no.

But the core issue you're hinting at - the reliability of the resume - is the real blocker for anything complex. I tried using it to draft personalized follow-ups based on CRM activity. If I just approved, it was fine. But if I needed to adjust the tone or add a specific reference, that's when it fell apart. Half the time it would restart the entire drafting process from scratch, losing my edit and the specific CRM context it had pulled.

So, if your safety net is truly just catching mistakes, it works. If your safety net involves any guidance or nuanced correction, the promise doesn't hold up. It's built for veto power, not collaboration.

You've got the right instinct comparing it to building a custom API step. The notification is clean and fast, presenting the original and the draft in a single view, so that context switch is minimal.

But you asked about reliable resumption, and that's where the promise falls short for your use case. If your approval is a pure binary gate, it's fine. The moment your input becomes an edit, even a minor one, the reliability plummets. For time-sensitive tasks like drafting client replies, that variance is unacceptable.

It essentially forces you to design your process around its brittle resume function, rather than letting the human provide the nuance you'd actually want. You end up back at square one, needing a more stateful system.

The notification's speed and presentation aren't the problem for your email drafting case. It's the cost of that unreliability on resume.

You're thinking about front-end dev time saved, which is real. But you need to factor in the latency tax when it fails. If an edit-triggered restart adds even five minutes to a client reply, that's an operational cost that can outweigh the build savings. For time-sensitive tasks, you're trading development complexity for unpredictable execution time.

The feature works only if your human input has zero entropy: a pure approve/reject. The moment you need to correct a nuance, you introduce variance that breaks any service level expectation.

It's a fair question, and I think you've hit the exact right test case with the draft reply workflow. The interface for that initial pause is indeed clean, and the information is well presented to make a quick decision.

But the devil, as they say, is in the resume. Your suspicion about it being an afterthought isn't quite right, but it leads you to the correct concern. The feature is designed for a clear binary checkpoint, not for collaborative editing. When you step outside that narrow lane, like tweaking a draft, the resume becomes unreliable. It's less of a smooth continuation and more of a coin flip between it incorporating your edit or restarting the entire task.

So, if your client reply process is "draft and approve, no edits," it's smooth. If your process requires any human nuance to the draft itself, you'll find the latency and unpredictability frustrating. In that case, you'd be better served by the custom API approach you mentioned, despite the front-end work.

You're right that the binary checkpoint is the intended design. The challenge is that in practice, very few real-world approvals are truly binary. Even a "good draft, just fix this one thing" introduces the restart risk.

I think the bigger cost than latency is the context loss you mentioned. A restart doesn't just add minutes - it forces the automation to re-derive the initial logic, which can subtly change the outcome. That's a silent quality risk that's hard to audit.