Hey HN,
I'm building EchoStack — a voice AI platform with a different abstraction layer than existing solutions.
The Technical Approach:
Most voice AI platforms are "tool providers":
EchoStack is "outcome provider": We ship manifest-driven playbooks that handle the entire voice AI stack.
Architecture:
Playbook = Manifest containing:
- AI prompts (outcome-optimized)
- KPI definitions (business metrics)
- Connector specs (CRM, calendar, knowledge base)
- Event mappings (what happens when X occurs)
- Action rules (escalation, handoff, completion)
Under the hood:
Unified namespaced event bus (playbooks communicate via events)
Pluggable pipelines (STT, LLM, TTS, CRM connectors)
Session state management (automatic)
Telemetry engine (tracks business KPIs, not just call metrics)
Playbooks are stackable: You can chain "Lead Qualification → Support Troubleshooting → Meeting Booking" with zero glue code. They just pass context via the event bus.
Why This Design:
Most businesses don't want to:
They want to deploy an outcome (qualified leads, booked meetings, resolved support calls) and measure ROI.
The manifest approach gives them:
Instant deployment (pick → configure → launch)
Structured flexibility (customize prompts, connectors, KPIs within a fixed structure)
Composability (stack playbooks for complex flows)
Business-native telemetry (tracks outcomes, not just system metrics)
Pricing Model:
Instead of per-minute or per-API-call, we charge for outcomes:
Qualified leads captured
Meetings booked
Support issues resolved
This aligns incentives: better playbooks = more value for customers = more revenue for us.
Questions for HN:
Abstraction level: Is this too opinionated? Or is "deploy outcomes, not tools" the right level for mainstream adoption?
Composability: Does the event bus + stackable playbooks approach make sense? Or is this over-engineered?
Technical concerns: What breaks at scale with this architecture? (We're planning for high-concurrency, multi-tenant deployment.)
Market fit: Would you use this? Or would you rather build custom with existing APIs?
Would love technical feedback, especially around the event-driven architecture and manifest design.
GitHub (coming soon) | Early access: https://getechostack.com/playbooks
solomonayoola•2mo ago
Voiceflow: Visual flow builder Retell: Agent SDK + runtime Bland.ai: API-first orchestration LiveKit: WebRTC infrastructure
EchoStack is "outcome provider": We ship manifest-driven playbooks that handle the entire voice AI stack. Architecture: Playbook = Manifest containing: - AI prompts (outcome-optimized) - KPI definitions (business metrics) - Connector specs (CRM, calendar, knowledge base) - Event mappings (what happens when X occurs) - Action rules (escalation, handoff, completion) Under the hood:
Unified namespaced event bus (playbooks communicate via events) Pluggable pipelines (STT, LLM, TTS, CRM connectors) Session state management (automatic) Telemetry engine (tracks business KPIs, not just call metrics)
Playbooks are stackable: You can chain "Lead Qualification → Support Troubleshooting → Meeting Booking" with zero glue code. They just pass context via the event bus. Why This Design: Most businesses don't want to:
Design conversation flows Write integration logic Build KPI tracking Maintain orchestration code
They want to deploy an outcome (qualified leads, booked meetings, resolved support calls) and measure ROI. The manifest approach gives them:
Instant deployment (pick → configure → launch) Structured flexibility (customize prompts, connectors, KPIs within a fixed structure) Composability (stack playbooks for complex flows) Business-native telemetry (tracks outcomes, not just system metrics)
Pricing Model: Instead of per-minute or per-API-call, we charge for outcomes:
Qualified leads captured Meetings booked Support issues resolved
This aligns incentives: better playbooks = more value for customers = more revenue for us. Questions for HN:
Abstraction level: Is this too opinionated? Or is "deploy outcomes, not tools" the right level for mainstream adoption? Composability: Does the event bus + stackable playbooks approach make sense? Or is this over-engineered? Technical concerns: What breaks at scale with this architecture? (We're planning for high-concurrency, multi-tenant deployment.) Market fit: Would you use this? Or would you rather build custom with existing APIs?
Would love technical feedback, especially around the event-driven architecture and manifest design. GitHub (coming soon) | Early access: https://getechostack.com/playbooks