Human-in-the-loop: how ModuleX asks before it acts

Teams looking at an assistant that can actually do things tend to arrive at the same hesitation, and it's a fair one. Fine — but what stops it sending the wrong message to a customer, or deleting the wrong record?

The answer isn't that it's very careful. It's that it stops and asks you.

That distinction carries more weight than it sounds like it does. Recent work suggests asking a model to be careful is a weak control: a July 2026 preprint by Maiorano isolated safety fine-tuning on a live endpoint and found it blocked none of the adversarial probes across the five OWASP LLM Top-10 categories tested, and a Stanford, UC San Diego and University of Washington preprint found that adding "only intervene if truly necessary" to a system prompt left the behaviour it named unchanged. Both are narrow single-model results and neither measures action gating — but instruction-level care is a different kind of thing from a stop.

Human-in-the-loop is the assistant pausing partway through a task to ask you something, then carrying on once you've answered. An approval is one shape of that pause — the shape that matters most, raised before an action that changes something. Here's what that actually looks like in ModuleX.

What the assistant can ask

A pause is always a question, and the question is one of five kinds: pick one option, pick several, answer yes or no, type something, or connect an account.

That last one is worth separating from the others, because it isn't a guardrail — it's the assistant telling you it can't get any further without access to a service. Not every pause means are you sure. Some just mean I need the keys, which is a smaller version of a problem we've written about before.

The rest are how the assistant resolves genuine uncertainty instead of guessing at it. And crucially, it raises them itself, when it needs them. You don't place checkpoints in the conversation ahead of time.

What an approval actually is

An approval is a question raised ahead of a risky action, and the action runs only once you've answered affirmatively. Reading things generally runs without a gate; writing or destroying something is gated. The documentation's own examples are the obvious ones — before sending an email, before deleting a record.

The word generally is doing real work in that sentence, and we'd rather leave it in than round it off. The boundary is defined by ModuleX's documentation, not by this post.

There is no approvals settings page

This is the part that surprises people, so it's worth stating plainly: which actions are gated is governed by ModuleX. It isn't configured per chat. There's no panel where you tune approvals tool by tool.

That's a trade, and a deliberate one — so, labelled as opinion: we think a gate you can't misconfigure is worth more than a gate you can tune. A permission screen that has drifted out of date isn't neutral. It reads as safety while quietly not being any, and the failure stays invisible until the moment it matters. Removing the knob removes that whole failure mode.

The failure is not hypothetical. Dan Musetoiu of Romania's Agency for Financing Rural Investments reported that a single unset configuration parameter caused a live assistant's runtime to silently truncate the head of every over-long prompt — cutting the behavioural rules and every guard out of the request, without an error, for weeks — with the symptoms misattributed to the model being weak rather than to a setting nobody had set. And where a knob does exist, picking a value is not the same as picking a safe one: a July 2026 preprint on binding drift found the intuitive "resolve once and carry it forward" safeguard trades one failure mode for another, removing drift while making an initially wrong choice worse, so no single setting is right for both.

The cost is real too. If your team wants a specific action gated that ModuleX doesn't gate, you can't add it yourself. We'd rather be straightforward about that than pretend the trade is free.

What is true while it waits

While the assistant is waiting on you, four things are true, and together they're most of the reason a pause is worth something rather than merely polite.

Nothing else runs. A paused turn is suspended, and no further action happens until you respond. It isn't proceeding optimistically in the background and hoping you agree.

There's exactly one open question. A chat holds one at a time, so you're never triaging a queue of half-finished decisions in the same conversation.

Only you can answer it. The person who triggered the question is the person who answers it, approvals included. A colleague can't clear your pending decision, and the assistant won't accept an answer from them. The documentation describes no way to hand a pending question to someone else either — worth checking against the docs if you were hoping to route approvals to a manager.

You have a week. The question stays answerable for seven days. That's the real window, not a UI countdown, and it means stepping away from your desk doesn't silently discard the work. After it closes, the answer is refused rather than assumed.

There's one more thing worth knowing, and it's a small relief: answering doesn't cost another run credit. A turn is charged one credit when it starts, and answering picks that same turn back up instead of beginning a new one. Token usage is still metered separately and keeps accumulating on the continued turn, so a long pause-and-resume isn't free in total — but you aren't billed twice for having been consulted.

The point

An assistant that never asks isn't trustworthy, it's just quick. An assistant that asks about everything isn't trustworthy either — it has handed the work back to you and kept the credit.

What we're aiming for is narrower and more useful than either: an assistant you can leave running on the ordinary work, that knows to come and find you before the parts you'd want to see for yourself. That balance is the whole idea behind putting a fully-authorized assistant in everyone's hands — the pause isn't an apology for the automation. It's the part that makes the automation something you can hand real access to.

If you want the mechanics — every question kind, how a paused run resumes, and what happens at each step — the human-in-the-loop documentation is the place to go.

---

This describes ModuleX as documented in July 2026. Behaviour is documented at docs.modulex.dev, which is canonical if this post and the documentation ever disagree.