Human-in-the-loop

A worker can plan and act on its own, but two mechanisms make sure a person is always in the decision path for anything that matters. A worker can pause mid-task to ask you something directly, and any risky action pauses for your approval before it runs.

​

The Ask-a-Human tool

Sometimes a worker hits a fork it can’t resolve alone — it’s missing a piece of information, or the next step depends on a judgment call only you can make. Rather than guessing, stalling silently, or asking you to babysit every step, the worker calls the Ask-a-Human tool: it pauses the task and asks its question right in the cowork chat. This is worker-initiated, not something you have to set up in advance. The worker decides, in the middle of its own reasoning, that it needs your input — the same way a colleague would knock on your door instead of guessing. Under the hood, an Ask-a-Human question rides the same pause-and-resume path as an approval (see below). The difference is what’s being asked: instead of a yes/no on an action, it’s an open question the worker needs answered before it can keep going. You reply in chat like you would to any message, and the task resumes with your answer folded straight back into its context — no need to re-explain what it was doing.

​

Approval gates for risky actions

Not every action a worker takes needs a rubber stamp. Reading a calendar, listing files, or looking up a record is safe to run immediately. But an action that reaches outside the task — sending an email, posting a message, deleting something, moving money — gets a checkpoint first. When an action needs a decision, the task pauses and an approval card appears inline in the chat, showing you what the worker wants to do. From there you can approve it, approve it and always allow that action going forward, or decline it — the task only proceeds once you respond.

​

The permission classifier: deciding what needs approval

Deciding “is this safe or risky” isn’t a simple keyword match — real actions like replying to an email thread, posting to social media, or capturing a payment don’t sort cleanly by name alone. CogniAgent uses two layers to make that call, so you’re asked exactly when it matters and not before.

• A fast, rule-based floor. A lightweight check looks at the shape of the action — is it a known safe read, or does it look like it sends, deletes, or pays? If it doesn’t recognize the action at all, it defaults to asking rather than guessing that it’s safe.
• A quick LLM check on top. A very fast model looks at the actual action’s description — not just its name — to judge whether it’s a read, a write, something destructive, financial, or irreversible. This catches cases the simple rule would miss, like an outbound action with an unfamiliar name, while also cutting down on unnecessary prompts for genuinely safe reads.

The two layers only ever make the gate smarter, never looser. If the fast check can’t reach a confident answer — an error, a timeout, low confidence — it falls back to the rule-based floor, which itself always defaults to asking rather than silently allowing.

​

Decision memory: don’t ask twice

Approving the same low-risk action over and over gets old fast. When you approve an action and choose to always allow it, CogniAgent remembers that decision so the worker doesn’t ask again for the same thing. A few things worth knowing about how that memory works:

• It’s scoped to you and that worker. An “always allow” you grant doesn’t hand blanket access to everyone in the workspace or apply to a different worker — it’s your standing decision for this one worker’s future calls.
• It’s granular by default. A remembered decision applies to the specific action you approved (like sending through a particular connected app), not a broad “allow everything” grant.
• It’s reviewable and revocable. Standing approvals live in the worker’s own files, so you can open them up and remove one at any time — nothing you approve is permanent by accident.
• Declining doesn’t create a standing block. Choosing not to approve something only applies to that one instance. A permanent “never allow this” rule is deliberately left as an explicit edit rather than a one-click button, so shutting off access is as intentional as granting it.

​

Pausing and resuming

Both an approval and an Ask-a-Human question suspend the task at the exact point it needed you — not just a generic “stopped” state. Whatever the worker was in the middle of doing is held, so nothing about the conversation or its progress needs to be reconstructed later. See Tasks for the full task lifecycle, including how a paused task is surfaced alongside everything else you own.

​

Control without babysitting

The goal of all of this isn’t to make you approve every step — that would defeat the point of having a worker act on your behalf. It’s to insert a checkpoint exactly where being wrong is costly: sending something externally, deleting or paying out, or making a call only a person should make. Everything reversible keeps moving without interrupting you. Over time, the interruptions get rarer, not more frequent. The classifier gets sharper about what’s genuinely safe, and decision memory means the approvals you’ve already made don’t come back around. You end up with a worker that’s autonomous by default and stops to check with you only when it should. This sits alongside, but is different from, Hooks: approvals decide whether an action is allowed to happen at all, while a hook can only add a further restriction on top of an action that’s already been approved. And if a worker is also reachable over Slack or email, see Channels for how those conversations connect back to a task. As workers take on more proactive, ambient work, these same checkpoints are what keep a person in the decision path — see Proactive workers.

​

Next steps