agent_manager has no way to surface or resolve human-in-the-loop approvals

[AmitAvital1]

Problem

docs/HUMAN_IN_THE_LOOP.md describes the approval gate added to the engine:
every tool call requires explicit approval unless the agent sets auto: true.
The bare engine HTTP API (agentctl serve, src/agent_engine/api/app.py)
fully supports this — /invoke and /stream return pending_approval in
their response, and GET /runs/{run_id} +
POST /runs/{run_id}/approvals/{approval_id}/decision (with /approve and
/reject shortcuts) let a caller resolve it.

agent_manager — the conversation-history + widget layer used by the
embeddable chat widget — has none of this:

• SendMessageResponse (src/agent_manager/api/schemas.py) has no
  pending_approval field at all.
• POST /conversations/{id}/messages
  (src/agent_manager/api/routes.py::send_message) just returns
  result.answer, result.visited, result.used_tools — when the engine
  pauses for approval, answer is simply empty. No error, no indication
  anything is pending.
• There is no endpoint anywhere in agent_manager to submit an approval
  decision.

Impact

Any agent served through agent-manager (i.e. through the embeddable
widget) that doesn't set auto: true silently breaks on its first tool
call: the widget shows an empty response with no explanation, and there is
no way to ever unblock it via the API. auto: true works around it by
skipping the approval gate entirely, but that's a workaround, not a fix —
it means "use the widget" and "use tool approval" are currently mutually
exclusive.

Suggested fix

Mirror what agent_engine/api/app.py already does, adapted to
agent_manager's conversation-oriented shape:

1. Add pending_approval to SendMessageResponse (and confirm/extend the
   streaming path — RunStreamEvent already has a pending_approval event
   type; check how much of this is already reachable via
   /conversations/{id}/messages/stream).
2. Add a decision endpoint, e.g.
   POST /conversations/{id}/approvals/{approval_id}/decision, calling into
   the engine's resume(...).
3. Update widget.js to render an approve/deny prompt when a response
   carries a pending approval, instead of showing an empty message.

Found while building a demo integration where the agent needed both tool
approval and the embeddable widget.

[AmitAvital1]

@Asaf-prog notice for you

[markolofsen]

I would treat this as a resumable approval state, not just another shape of SendMessageResponse.

A safe implementation boundary could be:

• agent_manager stores a message/run state like awaiting_approval, with the engine run id and approval id;
• normal send returns a typed pending-approval payload instead of an empty answer;
• streaming emits the same event and then stops cleanly until a decision arrives;
• the decision endpoint is idempotent: duplicate approve/deny returns the existing terminal decision;
• resume re-checks the tool payload, policy version, principal, conversation id, and expiry before execution;
• denial is returned to the model as a typed denial result, not as a transient tool error.

That last point matters because otherwise the model can accidentally retry around the approval gate. The widget then becomes a renderer for the same approval state the API already exposes, rather than a parallel approval path.

I build cmdop, so biased — the related boundary we use is that approvals are part of the permission/event model, not UI-only confirmation state: https://docs.cmdop.com/concepts/permissions

[rishu685]

hey is is this issue fixed or not,i would love to pick it up!