When Team Members Need Approval

A member of a Team agent works under its own tool policy. When one of its tool calls needs a person's approval, that member pauses on its own, and the rest of the team keeps working.

Answering a member

The question appears in the member's line: which tool it wants to run, and with what. Allow once runs that call, with those arguments only; Refuse declines it, with an optional reason (Why not?). The answer resumes only that member, and approving runs the call as that member, never as the lead.

A message never approves anything: writing "go ahead" to a member or the lead is not an approval.

The turn reads paused only when every member still working is waiting for an answer or done. Then it holds a list of questions, one per member, and each is answered on its own: answering one resumes that member and leaves the others' questions in place.

Where the questions reach you

• In the chat or on the run's page, in the member's own line: answer where you read it.
• In the bell, one item per question.
• On Cloud, by email as any approval is, except that a tool call's question has no answer link in the email: open it in the app.

In the API and over MCP

A paused team carries questions, one per waiting member, each with its own id. Pass that id as question_id when you answer, so the answer reaches the member that asked:

• the v1 chat API's answer, and a run's resume on v1 and v2;
• the MCP server's answer_run.

Without a question_id, an answer goes to the only question, or the first one waiting. An id the turn is not asking is refused.

A client on the OpenAI-compatible endpoint gets the team's final answer only; when a member waits for approval, the client is told the answer waits for a person, and the question is in the bell.