Inbox

The Inbox is your human-in-the-loop control surface. When an AI agent encounters a decision that requires human judgment -- a design choice, an ambiguous requirement, a risk assessment, a trade-off between approaches -- it creates a decision request that appears in your Inbox. You review the context the agent provides, write your answer, and the agent continues with your guidance applied.

This is the core feedback mechanism in IAS. Agents do not guess when they are uncertain; they ask.

What is a Decision Request?

A decision request is a structured question from an agent to a human. Each request includes:

• Prompt -- the question the agent is asking, written in natural language.
• Context -- background information the agent gathered to frame the question: relevant code, constraints, trade-offs, or prior decisions.
• Options -- when applicable, suggested response choices that the agent has identified.
• Tier -- the attention level required. IAS uses a three-tier model:
  • Blocker -- work is paused until you answer. These are the most urgent.
  • Checkpoint -- important but not blocking. The agent may have made an assumption and is asking you to validate it.
  • Audit -- informational review. The agent is sharing its reasoning for your awareness.
• Confidence and impact indicators -- how confident the agent is and how significant the decision is, helping you prioritize.
• Source context -- the originating run, goal, agent role, and milestone, so you understand where in the workflow this question arose.

Decision Request Lifecycle

Every decision request moves through a clear lifecycle:

Answering a Decision Request

1. Open the Inbox from the Console sidebar.
2. Select a decision request from the list. Requests are sorted by urgency -- blockers appear first, grouped by priority level (Critical, Urgent, Blocking, Optional).
3. Read the question and review the context provided. For blocking items, an impact banner at the top shows exactly what is waiting on your answer (e.g., "Answering this unblocks 3 tasks").
4. Type your response in the answer field. If the agent provided options, you can select one or write a freeform response.
5. Click Respond to submit your answer.

For run-scoped decision requests, operators also have the option to Respond & Continue, which submits the answer and immediately creates an apply_decision job. This materializes your response as a Git commit in the repository. This is useful when your answer directly translates to a code or configuration change.

After submitting, the decision request status changes to Answered. Once applied, a commit SHA is displayed -- click it to see exactly what changed in Git.

Auto-advance

Enable Auto-advance to next item (toggle at the bottom of the detail panel) to automatically jump to the next open decision request after you submit a response. This keeps you in a flow state when triaging multiple requests.

Filtering and Search

The Inbox provides several ways to find what you need:

• Status filter -- toggle between Open, Responded, Resolved, and All views.
• Search -- press / to focus the search field and filter by keyword.
• Urgency grouping -- open items are grouped by urgency level, with the longest-waiting items first within each group.

Blocking vs. Non-Blocking Requests

The distinction between blocking and non-blocking is the most important prioritization signal in the Inbox:

• Blocking requests are stopping an agent from making progress. A job or run is literally paused, waiting for your answer. The Inbox highlights these prominently with a blocking badge and impact details showing what is stalled.
• Non-blocking requests are advisory. The agent has made an assumption or completed a step and is asking you to validate. These are still important -- an unreviewed assumption can compound into larger issues -- but they are less time-sensitive.

The Workboard's Needs You panel also surfaces blocking decision requests, so you can spot them without navigating to the Inbox.

Writing Effective Responses

The quality of your answers directly affects the quality of agent output. A few principles:

Be specific

Vague answers lead to vague implementations. Instead of "looks good," say "use the existing UserService class in src/services/user.ts and add the new method there." Instead of "make it fast," say "response time under 200ms for 95th percentile."

Reference files and paths

Agents work best with precise pointers. If your answer relates to existing code, mention file paths explicitly. The agent can then verify its understanding against the actual source.

State constraints explicitly

If there are things the agent should not do, say so directly. For example: "Do not modify the public API surface" or "Keep backward compatibility with v2 clients."

Provide reasoning

Explaining why helps the agent make better follow-up decisions without needing to ask again. "Use PostgreSQL because we already have it in production" is more useful than just "Use PostgreSQL."

Keep it concise

You do not need to write an essay. Agents will ask follow-up questions if they need more detail. A few clear sentences with specific guidance is better than a wall of text.

Forwarding to Shared

For workspaces that use Spaces, internal-only decision requests can be forwarded to the Shared space when client input is needed. This is available to internal operators and moves the request to a visibility tier where external collaborators can see and respond to it.

Response Templates

If you find yourself giving similar answers frequently, you can save response templates in workspace settings. Templates let you standardize common responses -- coding conventions, architectural guidelines, approval patterns -- and apply them with a single click, reducing time spent on repetitive decisions.

Analytics

The Inbox includes an analytics view at /inbox/analytics that shows metrics on your decision request activity:

• Volume of requests over time.
• Average response time.
• Breakdown by status and tier.

This helps you understand how much human input your agents require and where bottlenecks might exist. If response times are climbing, it may be a signal to adjust agent autonomy levels or add more response templates for common patterns.

Tips and Best Practices

• Check the Inbox regularly. Unanswered blocking requests stall agent work. A quick morning triage keeps everything moving.
• Use keyboard shortcuts -- press ? in the Inbox to see available shortcuts for faster navigation.
• Triage from the Workboard. The Workboard's Needs You panel surfaces blocking decision requests alongside other urgent items, giving you a single place to start.
• Respond, then verify. After an answer is applied, click the commit SHA to review the actual change. Git is always the source of truth -- if something looks wrong, you can make a follow-up commit.
• Batch similar decisions. If multiple requests relate to the same area, answer them in sequence so your guidance builds on itself consistently.