Answering Sessions

After an Issue Session scans your codebase and produces a list of issues, it also records the questions it could not answer from the code alone and the assumptions it made when proceeding without explicit guidance. An Answering Session is the next step: an AI-powered session where an Answering Agent reviews those questions, refines them, and produces structured assumptions with confidence scores that you review and approve before implementation begins.

The result is a set of approved, human-reviewed answers that are injected as context into workflow runs when the resulting issues are executed - ensuring the implementing agent has the right understanding of requirements, scope, and architecture from the start.

Why Answering Sessions Matter

Issue Sessions are deliberately broad - the scanning agent surfaces everything it finds without necessarily having full context about intent, constraints, or priorities. This produces rich issue lists but also leaves open questions:

• “Should this security fix be applied to all environments or only production?”
• “Is the N+1 query pattern intentional here due to caching at a higher layer?”
• “Does this refactor need to maintain backward compatibility with the v1 API?”

Without answers to these questions, the implementing agent must make its own assumptions - which may be wrong. The Answering Session gives you a structured way to resolve these uncertainties before implementation, dramatically reducing the risk of AI agents implementing fixes that are technically correct but contextually wrong.

Configuring the Answering Agent

Before starting an Answering Session, configure the Answering Agent from the Answering Setup page at /p/{projectId}/answering-setup. This configuration is shared across all Answering Sessions in the project:

Starting an Answering Session

Answering Session Statuses

Session Question Categories

The Answering Agent classifies each question into one of six categories to help you prioritize your review:

You can filter the review list by category to tackle the most critical questions first. Architecture and requirements questions typically have the highest impact on implementation quality.

Session Question Review Statuses

Each session question has a reviewStatus that tracks where it is in the human review flow:

Data Model

Answering Sessions are represented by two table types in the database: answeringSessions and sessionQuestions.

answeringSessions: {
  userId: Id<"users">;
  projectId: Id<"projects">;
  issueSessionId: Id<"issueSessions">;
  sandboxId?: string;

  // Lifecycle
  status: "active" | "completed" | "reviewing" | "archived" | "killed" | "cancelled";

  // Agent outputs
  questionsJson?: string;     // Raw questions JSON from the Issue Session, passed as input
  assumptionsJson?: string;   // Raw assumptions JSON from the Issue Session, passed as input
  prompt?: string;            // The prompt used for the Answering Agent
  error?: string;             // Error message if the session failed or was killed
}

How Approved Assumptions Improve Implementation

When a workflow run executes an issue that has an associated Answering Session, the approved and corrected assumptions are formatted as structured context and prepended to the run prompt. The implementing agent receives not just “fix this bug” but also:

• Clarified requirements: what behavior is expected and what edge cases are in scope.
• Architectural guidance: which patterns to follow, which abstractions to use, and which boundaries not to cross.
• Priority context: which aspects of the fix are most critical and which are optional.
• Dependency awareness: which other systems or libraries are involved and what constraints they impose.

This additional context reduces the likelihood of the implementing agent making incorrect assumptions of its own, which is one of the most common sources of low-quality AI implementation.

Learnings from Answering Sessions

Session questions that are declined (and corrected) are particularly valuable as learning inputs. When the Answering Agent made a wrong assumption and you corrected it, that correction teaches the system about your project’s constraints, preferences, or patterns that weren’t obvious from the codebase alone.

If a session question is linked to a learningId, it means the correction has been compiled into a learning record that will be injected into future sessions - so the Answering Agent (and other agents bound to learnings) will be less likely to make the same incorrect assumption in the future.

Next Steps