Standardizing the human-in-the-loop: a protocol for real-time OTP routing
Why 'human in the loop' is where most automation dies
Every serious automation platform eventually hits the same problem. Somewhere in the pipeline, a remote system needs a piece of information only a human being has. A bank sends an SMS code. A portal asks for a specific word from the applicant's passport. A customs endpoint wants a confirmation the traveller is still at this number. The moment that happens, your beautiful Kubernetes-scheduled workflow has to pause and wait for a person — and people are slow, unpredictable, and usually asleep.
Most engineering teams handle this the same wrong way. They bolt a notification system on top of their existing automation: "if OTP required, send an SMS to the user, then retry in 5 minutes." This works on the happy path. It fails on every real-world edge case — user doesn't see the SMS in time, user enters it 30 seconds after the retry runs, the portal's hold window expires, the whole run is wasted. The result is a system that books appointments 60% of the time and tells applicants "please try again later" for the other 40%.
A proper human-in-the-loop protocol is not a notification system. It's a bidirectional, latency-sensitive, state-preserving bridge between an automated worker and a live human.
The four non-negotiable properties
The first property is the one most systems get wrong. When the portal demands an OTP, the worker keeps its session open, the page loaded, and its process running. It doesn't "finish" and retry; it pauses in place and waits for a value. Miss this property and you will always lose the slot on OTP-required runs.
The protocol, end-to-end
The latency budget that keeps slots alive
Why this reads like a protocol, not a feature
"Feature" suggests a checkbox: "we support 2FA." "Protocol" suggests a contract: specific states, specific events, specific timing guarantees, specific failure modes. For any platform integrating Opaige, the protocol framing matters because it's what lets you reason about the behaviour without reading our source code.
For the engineering teams at EORs and relocation platforms: our HITL protocol is idempotent, observable, and explicit about its failure modes. You can wire it into your own state machine, build your own UI around the socket events, and know exactly how timing affects outcomes. That's the difference between integrating infrastructure and integrating a script.