Interactive Project Interviews

A streaming AI interview that captures project requirements and feeds the research→backlog pipeline.

Interactive Project Interviews are the first streaming, non-technical end-user surface on the Rensei platform. They let a product manager, founder, or any non-technical stakeholder have a structured conversation with an AI agent and produce a research/backlog-grade User-Spec - without writing a single line of code or opening a workflow editor.

The interview runs inside the platform's capacity-pool sandbox (the same infrastructure that powers code-authoring agents), which means it inherits all auth modes including host-session. The output feeds directly into the research → backlog-writer chain so the spec becomes actionable work the moment the participant clicks Send to Rensei.

What an interview produces

At the end of a six-phase conversation the platform emits a User-Spec: a structured document that contains everything a backlog-writer agent needs to produce well-formed, sized, acceptance-criteria-complete work items. The spec covers:

Context

What the project does today and what has changed to prompt this work.

Users

Who the target users are, their goals, and their pain points.

Core Problem

The precise problem being solved, stated in non-technical terms.

Features (MoSCoW)

Must-have, Should-have, Could-have, and Won't-have requirements, scored by the participant.

Constraints

Budget, timeline, platform, compliance, and integration constraints.

Success Criteria

Measurable outcomes that define done for this work.

The six-phase structure

Every interview follows the same six phases in order. The agent adapts its depth and follow-up questions based on the participant's answers, but the phase sequence is fixed - this ensures the spec is always complete and predictable for downstream processing.

At the end of each phase the agent writes a phase summary card visible in the live spec panel on the right side of the screen, so the participant always sees exactly what has been captured so far.

How it fits in the pipeline

An interview is not a session in the code-authoring sense - no repository access, no tool calls against a codebase. It is a focused, sandboxed conversation whose sole output is a User-Spec document.

Interview (streaming chat)
    ↓
User-Spec (structured document)
    ↓
research agent
    ↓
backlog-writer agent
    ↓
development → qa → acceptance (standard SDLC)

The Send to Rensei action at the end of the interview creates a new issue in the project's connected tracker (Linear or GitHub Issues), attaches the User-Spec as the issue body, and sets the issue to the Icebox state - triggering the research agent automatically if the default SDLC template is active.

Why it matters

Before Interactive Interviews, getting a non-technical stakeholder's requirements into the SDLC pipeline required a developer to translate them into a Linear issue. That translation step introduced delay and information loss. Interviews eliminate the translation by letting the stakeholder drive the conversation directly, with the AI agent asking the right questions to extract everything the pipeline needs.

Interviews are plan-gated (screen_interview) and require an org admin to enable the feature and select a model profile. See Configuration.

Running an Interview - the participant experience, phase by phase
Configuration - enabling interviews and selecting a model profile
Access Control - granting per-project interview access to org members
Interview Template - the interview-v1 workflow template that wires interviews into the SDLC
Architecture - how the streaming sandbox, relay, and gate handoff work