Design Hub: team discovery as a platform with AI agents
I turned the team discovery method into a platform that extracts requirements, processes interviews, generates stories, syncs with Jira and answers with sources.
- Client
- Ferramenta interna
- Year
- 2026
- Categories
- AI Solution
A software house runs on many projects at once, each with its own client, stage and set of decisions. Confluence and Notion stored the documents, but not the process: the approved scope sat in one folder, the interview transcript in another, the requirements in a spreadsheet and the user stories in Jira. Anyone joining later rebuilt the reasoning by asking whoever had been there from the start.
The symptom that made me build the platform was the lost trail between evidence and decision. A story reached engineering with nobody able to say which interview originated it, which requirement it covered, or which acceptance criteria had been agreed with the client.
The problem: discovery lived in people, not in the system
The design team did not lack a method. It lacked a place where the method happened. The steps lived in each designer's head and came out different on every project, which made them impossible to compare, audit or hand over. Rework surfaced during refinement, when the information had already cost a meeting.
The decision was to turn the playbook into software. Instead of writing a guide on how to do discovery and hoping for adherence, every step became a screen with fields, states and validation.
The thesis: every step is an artifact with an agent and a prompt
The platform is not a document repository with a chatbot in the corner. Each step has an input type, an AI processing step with its own prompt, and an output artifact that feeds the next step.
I upload the raw interview transcript and the system extracts the highlights. I upload the requirements document and the system extracts the functional requirements, with acceptance criteria written as testable statements. The approved PRD yields modules and functionalities, and those yield user stories. Every prompt is versioned and editable in settings, with character count and token estimate, because agent behavior changes with the text it receives.
The human gate sits at every handover: the agent proposes, the designer reviews, corrects, and only then does the artifact move forward. Nothing is approved by machine inference.
The pipeline
Scope, requirements and PRD
The contract PDF enters the platform and the processing button triggers an external n8n flow that returns the structured scope. From there the team keeps the Product Requirements Document in a WYSIWYG editor with a Markdown toggle, next to the functional requirements list with coverage status and acceptance criteria on the same screen.
Interviews and synthesis
Each interview records stakeholder, goal, recording and transcript. Processing applies the synthesis prompt and returns organized findings, and that summary is what enters the knowledge base, not the raw text. The interview list shows the status of each one, which gives the team a read on how much of discovery has been processed.
Modules and user stories
The project is organized into modules and functionalities, which allows stories to be generated against a product structure instead of a loose list. Each story carries categorized acceptance criteria, technical requirements, associated technical debt and a link to the Figma file.
Jira synchronization
The integration creates the epic when it does not exist, stores the mapping to avoid duplicates, and checks whether the epic is still valid before reusing the link. Status is tracked per story, with isolated errors so one failure does not break the whole batch, plus bulk resync and issue deletion when a story is dropped.
The project agent
Each project has an agent that talks about its own content. The knowledge base is indexed in PostgreSQL with pgvector and Portuguese full text search, and answers stream with the sources cited at the end: the interview, the story or the requirement behind each claim. When a question cites a code such as US-01, a code lookup path runs as well, because relevant content does not always rank in the first similarity results.
The system prompt is global and editable, with token estimate and retrieval parameters, which lets the behavior and the model change without touching the front end.
Public story link
Stories can be shared through a public tokenized link with view counting, which solved the conversation with stakeholders who have no account in the tool. The stakeholder reads the story and the acceptance criteria without entering the project.
Architecture and product decisions
The front end is React with TypeScript, Vite, Tailwind and shadcn/ui, with async state in TanStack Query. The back end is Supabase, with authentication, Row Level Security and storage. The intelligence layer never sits in the client: 14 Deno Edge Functions isolate keys, orchestrate providers and persist results. The schema has 30 tables and 82 migrations.
Three decisions shaped the rest:
Hybrid search instead of vector only. The agent queries vector and text at the same time, with a deterministic code fallback. A specific technical question does not always embed close to the right document.
Indexing in visible steps. The base syncs in seven steps, with progress, cancellation and stuck detection. A confident answer over stale data is worse than an error.
AI keys never in the client. Every model call goes through an authenticated Edge Function, with the system prompt centralized.
What changes in the process
Discovery stops being a phase that happens and becomes a consultable state of the project. When the question is where this story came from, the answer exists, and it arrives with the interview cited. That is the difference between a team that documents to check a box and a team that documents because the system returns the document at the moment it is needed.