Skip to main content
When dotbot cannot proceed with a task without human input, for example a missing requirement or an ambiguous design decision, it marks that task as needs-input and routes the question to the appropriate stakeholder. Rather than blocking the entire queue, dotbot sends the question out-of-band via Microsoft Teams, email, or Jira, waits for a reply, and then resumes the task automatically once an answer arrives. This keeps pipelines moving without requiring the team to monitor the dashboard in real time. This page covers the client side: the mothership settings block and how dotbot routes a question to Teams. The server that delivers questions and collects answers is documented separately in Question delivery service.

​
Why human-in-the-loop matters

AI models can resolve most questions by reading the codebase, product documents, and task context. But some decisions require human judgment — a stakeholder who knows the business constraint, the architect who owns the design, or the product owner who decides between competing priorities. Without a structured way to ask those questions, the AI either guesses (introducing risk) or halts the pipeline entirely. The needs-input mechanism gives the AI a safe escape hatch: pause the task, ask the right person, and continue when the answer arrives — without blocking any other tasks that do not depend on this one.

​
How the flow works

1

Task reaches needs-input

The AI determines it cannot proceed without more information and calls the task_set_status MCP tool to move the task to needs-input. dotbot records the question on the task as a pending_question and pauses it, removing it from the active execution queue.
2

Question is sent to the stakeholder

dotbot’s notification client reads the mothership settings block and sends the question to the configured channel (teams, email, or jira) along with the available choices.
3

Stakeholder answers

The stakeholder replies directly in Teams via an Adaptive Card, by email, or via a Jira comment. The question delivery service stores the answer in Azure Blob Storage.
4

dotbot resumes the task

dotbot polls the server on the configured poll_interval_seconds interval. When an answer arrives, it attaches the answer to the paused task and promotes it back to the active queue.

​
Configuring Microsoft Teams integration

Add the mothership block to your settings.default.json and set channel to teams:
settings.default.json

​
Setting up the server_url and api_key

To use Teams (or any other notification channel), you need a deployed mothership server. Once your server is running, set its URL and API key in settings.default.json:
settings.default.json
Store the api_key in your local .bot/.control/settings.json rather than in the version-controlled settings.default.json to avoid accidentally committing credentials to your repository.

​
What stakeholders see

When a question is routed to Teams, the recipient receives an Adaptive Card that includes the project name, the question text, and a set of choices to select from. Clicking a choice submits the answer directly — no separate login or dashboard access is required. The architecture is:

​
Question types

The question delivery service supports five question types. A needs-input task picks the type that fits the decision it needs: When a stakeholder responds, the service stores the answer in Azure Blob Storage. dotbot reads it during the next poll cycle and attaches it to the paused task before resuming. For the answer record format and the server side of this flow, see Question delivery service.

​
Other routing options

Set channel to email and populate recipients with email addresses. dotbot sends a formatted message with answer choices and resumes when a reply is received.
Set poll_interval_seconds to 60 or higher in long-running pipelines to reduce noise in the server logs. For time-sensitive interactive workflows, 15–30 seconds gives a responsive feel without excessive polling.