Change log

Technical Research: Architecture & Technology Landscape for Quorum

1. Multi-Agent Orchestration Frameworks

Quorum's core is a named AI team (John/PO, Winston/Dev Lead, Mary/UX Researcher, Kinsley/Product Designer, Luca/Motion Designer, Jaymes/Frontend, Damien/Backend when needed, Quinn/QA, Cipher/Security, Bob/Scrum Master; plus Amelia for BMAD story execution) that collaborate with the human conductor. The orchestration framework is the most critical architectural decision.

Framework Landscape (April 2026)

Three dominant frameworks, each with a fundamentally different philosophy:

Performance Benchmarks (GPT-4o, identical infrastructure)

Framework Analysis for Quorum

LangGraph — Best Fit - Native state persistence and checkpointing — critical for long-running product sessions that span hours/days - Human-in-the-loop is a first-class primitive — maps directly to Quorum's conductor model where humans approve decisions - Cyclic graph support — agents can debate in loops (PO proposes → Dev Lead challenges → PO adjusts → human decides) - LangSmith observability — can expose agent reasoning to users ("show your work") - Durable execution — sessions survive server restarts, network interruptions - Lowest token overhead and cost per task - Steeper learning curve (~55 min to first setup vs. 25 min for CrewAI) — acceptable for a platform team

CrewAI — Interesting but Risky - Role-based agent design maps perfectly to Quorum's team model (assign roles, define collaboration patterns) - Fastest to prototype and most intuitive API - Breaks down in complex, long-running workflows — Quorum sessions are exactly this - Limited checkpointing — can't reliably pause/resume multi-hour sessions - Higher token overhead than LangGraph

AutoGen — Poor Fit - Conversational model accumulates context across multi-turn interactions → expensive (+31% overhead) - Dynamic emergent collaboration is interesting but unpredictable — Quorum needs reliable, repeatable agent behavior - Microsoft-backed but less mature in production deployments

OpenAI Agents SDK — Worth Watching

OpenAI's Agents SDK (upgraded from Swarm) uses five primitives: agents, tools, handoffs, guardrails, and tracing. Two key patterns: - Agents as tools: Manager agent calls specialists and combines outputs — maps to Quorum's John (PO) coordinating the team - Handoffs: Triage agent routes to specialists who speak directly to the user — maps to Quorum's routing model

Available in both Python and TypeScript (2026). Simpler than LangGraph but less mature for complex multi-agent choreography. Could be a future migration target if the SDK matures.

Four Production Orchestration Patterns

1. Triage/Router — One agent classifies and routes to specialists (cheapest, uses small model for routing)
2. Fan-out/Fan-in — Multiple agents work simultaneously, results merged (good for parallel pillar analysis)
3. Supervisor/Hierarchical — Central agent delegates and reviews (maps to Quorum's agent hierarchy)
4. Pipeline/Sequential — Agents execute in fixed order (good for vision → filter → prioritize flow)

Quorum likely needs a hybrid: supervisor pattern for the team (John / PO as team lead), fan-out for three-pillar analysis (Desirability/Feasibility/Viability evaluated in parallel), and triage for feedback loop routing.

Recommendation

LangGraph as primary orchestration framework. It's the only framework with native state persistence, human-in-the-loop, and durable execution — all non-negotiable for Quorum. CrewAI's role-based design is more intuitive, but its production fragility is disqualifying for a platform where sessions last hours and span days.

2. LLM Selection & Cost Modeling

Current Pricing (April 2026)

Cost Modeling for Quorum

Key insight: Output tokens are 3–8x more expensive than input tokens. Quorum's agents generate substantial output (analysis, recommendations, debate), so output cost dominates.

Tiered model strategy (use the right model for each task):

Estimated cost per user session (1-hour active session with full named team — adjust for which agents are active):

Assumptions: ~50K input tokens (context, history, documents), ~20K output tokens (agent responses, debates, recommendations), tiered model usage.

At 20 sessions/month per user: $1.80–$6.60/month in LLM costs per user. This is sustainable at a $20–30/mo solo tier price point with healthy margins.

Cost reduction strategies: - Aggressive caching of common agent patterns (complexity scans, ceremony templates) - Prompt compression for repeated context across sessions - Summary-based context management (don't replay full history, summarize) - Model routing: cheap models for 60–70% of tasks, expensive models only for judgment-heavy work

3. Web Platform Architecture

Frontend Framework

For Quorum's team room GUI: The interface is primarily conversational with streaming agent responses, drag-and-drop for findings/boards, and real-time multi-user collaboration (enterprise). This is a highly interactive, real-time-heavy application.

Recommendation: Next.js for ecosystem breadth, streaming support via React Server Components, and hiring pool. Remix is a strong alternative if vendor independence is prioritized.

Real-Time Architecture

The team room requires real-time updates: agent responses streaming, board state syncing, finding status changes.

Architecture pattern: - WebSocket connections for active sessions (agent conversations, real-time board) - Redis Pub/Sub as message broker for horizontal scaling (multiple server instances) - SSE for background notifications (feedback digest ready, finding status changes) - Optimistic UI updates on client, confirmed by server

Conversational UI Frameworks

Several React frameworks support building chat interfaces for AI agents:

• OpenAI ChatKit — batteries-included, streaming, tool display, rich widgets, source annotations
• Tambo AI — generative UI where agents can dynamically render registered React components (useful for agents presenting data visualizations, boards, grids)
• Hexos — pre-built components (ChatWindow, MessageList, StreamingIndicator), multi-agent support, theming
• AGNO Agent UI — streaming-enabled, integrates with orchestration libraries

For Quorum's team room: The UI is more than chat — it's a spatial team room where agents have presence, boards are visible, and findings can be dragged between agents. This likely requires a custom UI layer built on top of a streaming chat primitive (ChatKit or Tambo for the conversational parts, custom components for boards/grids/spatial elements).

4. Data Architecture

Core Data Model

Quorum manages several interconnected data types:

Event Sourcing for Findings & Decisions

The finding lifecycle (Detected → Triaged → Batched → Ceremony-Ready → Approved/Deferred/Killed) and decision records are natural fits for event sourcing:

• Append-only event log: every state transition logged with who/why/when — full audit trail
• Projections: materialized views for current state (sprint board, backlog, hospital, morgue)
• Time-travel: replay decision history ("when you evaluated in Sprint 12, cost was X")
• Deterministic replay: debug agent behavior by replaying events

PostgreSQL supports this natively via JSONB payloads, table partitioning, LISTEN/NOTIFY for pub/sub, and partial indexes — no specialized event store needed.

Agent Memory & Context Management

Agents need to remember across sessions — Winston (Dev Lead) learns estimation patterns, Mary remembers user segments, John knows stakeholder preferences.

Layered memory architecture: - Working memory: current session context (conversation history, active findings) — in-memory + Redis - Episodic memory: timestamped interaction history — PostgreSQL with efficient retrieval - Semantic memory: learned facts, preferences, patterns — PostgreSQL + pgvector for similarity search - Procedural memory: learned behaviors (estimation calibration, user proficiency models) — structured storage

pgvector enables semantic search within PostgreSQL itself, eliminating the need for a separate vector database. "What did Winston (Dev Lead) say about payment service complexity last sprint?" becomes a vector similarity query.

Token budgeting is critical: agents can't load all memory into context. The system must intelligently select relevant memories, compress/summarize old context, and respect token limits per model.

Recommendation

PostgreSQL as the primary database with pgvector extension for semantic search. Event sourcing for findings/decisions (append-only tables with JSONB). Standard relational tables for features, sprints, boards, users. Redis for real-time state and pub/sub.

5. External Integration Architecture

JIRA / Linear Bidirectional Sync

Linear already has native Jira Sync (two-way sync of issues, assignees, status, labels, priority, comments). This validates the pattern and provides a reference implementation.

Architecture for Quorum's enterprise integration:

Key design decisions: - Webhook processing must be idempotent (JIRA/Linear may retry) - Queue-based processing (don't process webhooks synchronously — buffer in a job queue) - Conflict detection before overwrite — never silently lose data - Per-tenant API credentials stored encrypted, scoped to specific JIRA/Linear projects

MCP (Model Context Protocol) Integration

MCP is emerging as the standard for AI agent tool integration. Quorum's agents could expose tools via MCP for extensibility — allowing third-party agents or tools to interact with Quorum's data.

6. Multi-Tenant SaaS Architecture

Tenant Isolation Patterns

Recommended: Hybrid namespace as the default, with tenant-specific deployment available for enterprise customers who require it.

Critical Multi-Tenant Challenges

1. Data leakage prevention: 68% of organizations have experienced AI-related data leaks. Every RAG index, vector store query, file access, and agent memory must be scoped to a tenant workspace ID. This is non-negotiable.

2. Noisy neighbor: One tenant's heavy AI workload (e.g., running full three-pillar analysis on 50 features) can saturate LLM API rate limits and degrade others. Requires per-tenant quotas and rate limiting.

3. Unbounded agent work: Agents can loop through tool calls or accumulate unbounded token counts. Explicit per-session and per-tenant cost caps required.

4. Access control complexity: AI agents need five identity layers — trigger identity (who started it), execution identity (what credentials it uses), authorization identity (what it's allowed to do), tenant identity (whose data it accesses), and channel identity (where results go).

Microservice Decomposition

Decompose the agent lifecycle into distinct services:

7. Infrastructure & Deployment

Recommended Stack Summary

Scaling Considerations

• Stateless frontend on edge (Vercel) — scales horizontally automatically
• Orchestrator is the bottleneck — scales by tenant partitioning and agent pool sizing
• LLM API rate limits are the ceiling — multi-provider strategy with failover
• Database scales vertically first (PostgreSQL handles significant load), then read replicas
• WebSocket connections scale via Redis Pub/Sub (any server can serve any user)

8. Key Technical Risks & Open Questions

Open Technical Questions

1. Agent personality persistence — How to maintain consistent agent personalities across sessions without consuming excessive context? Personality as system prompt vs. fine-tuned model vs. few-shot examples?
2. Debate protocol design — How structured should agent-to-agent debates be? Fully scripted turns vs. emergent conversation? How to prevent infinite loops or repetitive arguments?
3. Estimation learning — How does Winston (Dev Lead)'s estimate accuracy tracking feed back into future estimates? Online learning vs. batch recalibration?
4. Feedback loop data sources — What analytics events constitute "passive signals"? Integration with Mixpanel/Amplitude/PostHog, or build-in analytics?
5. Offline/async agent work — Can agents do background work (research, synthesis) between user sessions? Implications for cost and notification design.
6. Three-pillar filter execution — What specific data sources and methods power each pillar? Desirability: user interviews + analytics? Feasibility: codebase analysis + complexity heuristics? Viability: market data + financial modeling?