PRD-001: AI Chat Hero — Employer’s First Conversation
Problem Statement
Hiring tools are CRUD forms with an AI sidebar bolted on. The employer’s mental load is “what form do I need next?” — not “what hire am I trying to make?” Flux’s competitive thesis is that an AI agent IS the interface: every action is a conversation, every artifact (job description, candidate Kanban, interview schedule) is rendered inside the chat as agent tool output. PRD-001 is the foundational PRD that establishes this stance — every other PRD inherits its conversational-first defaults.Success Criteria
- An employer with no prior Flux exposure can complete the 6-step thread (sign up → create a job → post → manage candidates → schedule interview → make hire) entirely through chat, with no form fills outside the conversation
- Generative UI artifacts (Kanban board, candidate list, interview slot picker) render inside the chat thread as tool output, not as separate pages the user must navigate to
- First meaningful agent response (after sign-up) ≤ 1 second on production
- Streaming via SSE feels instant — first token visible ≤ 300 ms
- The chat is the audit trail — every action the agent took is visible in conversation history and replayable
User Stories
Story 1: First-time employer — Sign up and create a job
As a small-business owner who just signed up for Flux, I want to describe the role I’m hiring for in plain English, so that I get a polished job description, posted to the right channels, without filling out a form. Acceptance Criteria:- Given the employer has just completed Clerk sign-up, when they land on the chat, then the agent greets them and asks one focused question (e.g., “What role are you hiring for?”)
- Given the employer types
"I need a CDL driver in Tampa, full-time, ~$25/hr", when they send, then the agent callsgenerate_job_descriptionand renders the JD inside the chat for the employer to review/approve - Given the employer says
"looks good, post it", when they send, then the agent callsselect_distribution_channels(reasoning over role type + budget) and renders a channel/cost preview - Given the employer approves, when they send, then the agent calls
post_jobto each selected channel and confirms with channel-specific deep links
Story 2: Returning employer — Manage active hiring
As a returning employer with active jobs, I want to ask about candidates and take action conversationally, so that I never have to navigate menus or click into separate pages. Acceptance Criteria:- Given the employer says
"who applied to my driver job today?", when the agent responds, then a Kanban-style candidate list renders inside the chat thread - Given the employer says
"set up an interview with the top candidate Tuesday", when the agent responds, then a slot-picker renders with the candidate’s stated availability + employer’s calendar - Given the employer picks a slot, when they confirm, then the agent calls
schedule_interview, sends the candidate notification, and confirms in the chat with the calendar link
Story 3: Hiring decision — Hire-package collection
As an employer who has decided to hire a candidate, I want to give the hire-package details (start date, salary, etc.) by answering questions in chat, so that my downstream HRIS / payroll integration receives a complete record without me filling out a payroll form. Acceptance Criteria:- Given the employer says
"hire Maria", when the agent responds, then it asks the missing hire-package fields one at a time (start date → comp → benefits) - Given all fields collected, when the agent confirms, then it renders a HirePackage summary card and asks for final approval
- Given the employer approves, when the agent commits, then HirePackage is persisted and any HRIS integration is triggered via Temporal workflow
Functional Requirements
FR-1: Persistent SSE chat endpoint
Description: The employer chat is a single SSE-streamed endpoint backed by the LangGraph ReAct agent. Priority: Must-have Acceptance Criteria:-
/chatendpoint streams agent tokens + tool calls + tool results - Reconnect resumes the active turn without dropping context
- Backend stores conversation in Postgres with full tool-call history
FR-2: ReAct agent with hiring tool registry
Description: The agent invokes domain tools using the ReAct pattern (observe → reason → act). Priority: Must-have Acceptance Criteria:- All 12 hiring tools (job creation, JD generation, channel selection, posting, candidate retrieval, scheduling, hire-package, etc.) are wired and callable
- Tool selection is agent-driven, not pattern-matched in code
- Specialist delegation works (e.g., scheduling specialist invoked via parent agent)
FR-3: Generative UI in-thread
Description: Tool outputs render as React components inside the chat thread, not as separate pages. Priority: Must-have Acceptance Criteria:- JD renders as an editable preview card
- Candidate list renders as a Kanban / table inside the message
- Interview slot picker renders inline
- Each generative artifact has a stable
tool_call_idfor replay
FR-4: First-token latency budget
Description: First streamed token from the agent appears within 300 ms of the user pressing send (production). Priority: Should-have Acceptance Criteria:- p95 time-to-first-token measured in OpenTelemetry; alert if > 500 ms
- Cold-start path warmed via Cerebe SDK pre-init
UX Requirements
- Chat surface is the primary route after sign-in — no dashboard landing page above it
- Generative UI uses shadcn/ui components, theme-matched to Flux palette
- Mobile chat parity from day one (Flux’s pilot customers operate on phones in the field)
- Voice input as a stretch goal (mobile mic → STT → chat)
Out of Scope
- Candidate-facing chat — separate PRD (the candidate portal has a distinct conversational surface)
- Multi-tenant org switcher in chat — handled outside chat by Clerk
- Voice output / TTS — future iteration
- Email composition surface — agent composes email via tool, but the employer doesn’t open a separate “compose” panel
Open Questions
| # | Question | Owner | Target Date | Resolution |
|---|---|---|---|---|
| 1 | Does the employer ever bypass chat for power-user actions? | @pj | 2026-05-15 | Default: no — every action remains conversational. Re-evaluate after pilot. |
Dependencies
- Clerk auth (employer Bearer JWT)
- Cerebe SDK (memory fabric for conversation grounding)
- Temporal namespace
flux(for workflows triggered by tool calls) - Hiring domain models (Cycle 202)
Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Pilot users distrust chat for high-stakes actions (e.g., hire) | Medium | High | Always confirm before mutations; render structured summaries; allow undo via chat for time-bounded reversible actions |
| Tool selection latency dominates user-perceived response time | Medium | Medium | Pre-warm specialists; streaming tool metadata before tool result; UX shows “calling X tool…” indicator |
| Generative UI components proliferate without design coherence | Medium | Medium | All generative artifacts use shadcn/ui base; Cycle 380 UI design skill enforces research + screenshot review for any new artifact type |
This PRD established Flux’s conversational-first product stance. All subsequent PRDs inherit this default — propose a non-conversational interface only with explicit RFC justification.