A respectful look at how a three-person YC team built an AI-native process discovery engine in four months, and the architectural tensions every company in this space will face at scale.
The Setup: Why This Matters
Most enterprise AI demos are PowerPoint fiction. You see a slick interface, a few mocked-up charts, and a founder who says "we're using GPT-4" like that's a product.
Then I watched Ontora's product demo. Not the YC pitch. The actual UI walkthrough. And I saw something different: what appears to be a real architecture with six distinct layers, a fixed ontology, and a feedback loop that is either brilliant or dangerous — depending on how well they solved a problem they never talk about in marketing.
Ontora is a YC P26 company. Three founders. ~$700K raised. Five enterprise design partners. Their pitch is simple: deploy AI agents to interview every employee in a company, then synthesize the transcripts into process maps, bottleneck analysis, and an automation roadmap. Four hours instead of four months of consulting.
I spent a week reverse-engineering their public signals — product demo frames, founder backgrounds, GitHub repos, and YC directory data. What follows is my best reconstruction of how the system likely works, where the engineering appears to get genuinely hard, and why the companies that solve the hard parts will own this category.
This is not a teardown. It is a technical study of an ambitious architecture built under extreme constraints. Every builder will recognize the tradeoffs. And I may be wrong about any of it — corrections welcome.
Layer 1: Campaign Orchestration — The Brain Above the Interview
The first thing the demo reveals is that Ontora does not "interview everyone" in one blast. It runs campaigns.
You open a "Create Interview" modal. You pick a goal template: AI Transformation Discovery, Employee Engagement, Change Management, or Process Optimization. You scope it to a department. You set a duration — 20 minutes, 30 minutes, whatever the topic demands. You choose a voice persona ("Blake — Helpful Agent"). You decide whether to upload your own participant list or let Ontora discover employees via directory integration.
Then you hit go.
This is not a survey tool. This is a campaign orchestration engine. And it changes everything about how you think about the architecture.
Why This Layer Is Hard
From what I can see in the UI, my best guess is that each campaign is a scoped, stateful workflow with its own:
- Prompt template (the LLM system prompt is constructed from the goal + department + topic)
- Participant cohort (resolved from HRIS/SCIM or CSV upload)
- Lifecycle state machine (Draft → Scheduled → In Progress → Paused → Completed)
- Progress aggregation (real-time counters: 526 of 547 completed)
- Output schema (what insights, maps, and metrics this campaign should produce)
Building this at 10-person scale is straightforward. Building it when you have 50 concurrent campaigns across 5 customers, each with different org structures, languages, and compliance requirements — that looks like a distributed systems problem dressed as a UX problem.
The demo shows 17+ campaigns in the sidebar. Some are active. Some are drafts. Some are paused. That sidebar appears to be a control plane for what I suspect is a multi-tenant orchestration layer that has to schedule, retry, timeout, and aggregate across hundreds of concurrent interview sessions without losing state.
That looks like real engineering.
Layer 2: The Interview Interface — Text-First, Voice-Optional
Here is where my original hypothesis died.
I assumed "100 parallel calls" meant telephony. Twilio. Bland AI. Retell. Real-time voice infrastructure with all the cost and complexity that implies.
The demo shows something else entirely: a web-based chat interface.
The employee opens a link. They see a chat window. The agent introduces itself: "Hello David, this chat is about finding high-ROI automation chances in Pilot Group's finance department. We'll talk for about 20 minutes, and it's all confidential. Ready when you are."
The employee types back. Or they hold the spacebar and speak. The transcript appears as text bubbles. They can pause and resume later. Their progress is saved.
Why This Is Smart
Telephony voice AI costs ~$0.05-0.10 per minute at scale. A 20-minute interview is $1-2 in pure infrastructure before you pay for the LLM, storage, or compute.
A web-based text interview costs ~$0.05-0.10 total for the same duration. The LLM tokens are the dominant cost, not the transport layer. Add optional push-to-talk voice (STT + TTS) and you get the richness of voice without the telephony bill.
At 500 interviews per month, the difference is $500 vs. $5,000. At 5,000 interviews, it is $5,000 vs. $50,000. For a pre-seed startup selling at ~$50K per engagement, that margin matters.
Why This Is Hard
The UX problem is subtle. A phone call has social gravity — you answer, you focus, you finish. A web chat is asynchronous. The employee might pause for an hour. They might multitask. They might drop off entirely.
Ontora appears to solve this with session state persistence: progress is saved, context is reloaded, the agent resumes exactly where it left off. But session state for long-running LLM conversations is non-trivial. You need:
- A session store (Redis, DynamoDB, Firestore) that can hold conversation context
- A context window management strategy (you cannot feed 20 minutes of transcript into the LLM prompt every turn — you need summarization or RAG)
- A re-engagement system (email nudges, Slack reminders) for employees who pause and never return
The demo shows all of this appearing to work. That is not trivial for a three-person team.
Layer 3: Extraction & Linking — From Chat to Structured Knowledge
Once the interview is done, the raw transcript is just noise. The hard work is turning natural language into a structured knowledge graph.
From the demo, I can infer at least four extraction pipelines that are likely running:
3.1 Entity Extraction
Who is mentioned? What tools? What processes? The demo shows the agent asking: "Which records, documents, and conversations did you need to check?" The employee answers: "Outlook, NetSuite, SharePoint, and Teams." Those tool names are extracted, normalized, and linked to the company's system connector inventory.
3.2 Sentiment & Intent
The demo does not show this explicitly, but it is implied by the output. The insight card for Anna Keller reads: "Anna represents the high-impact finance operator: the work is structured enough to automate, but exceptions still require context scattered across documents, email, and chat."
That sentence is not a transcript quote. It is a synthesized persona archetype generated by an LLM that has classified the employee's role, described their work pattern, and assessed automation readiness. That likely requires sentiment analysis, role classification, and process maturity scoring — all running in a post-interview batch job.
3.3 Process Extraction
This is the crown jewel. The demo shows a swimlane diagram: Manual invoice mismatch review: current-state swimlane. It has lanes for Vendor, Finance/AP, Operations, and Procurement/Buyer. It has stages: Invoice Intake → 3-Way Match → Evidence Search → Exception Decision → Approval Routing.
This was extracted from multiple employee interviews and rendered as a visual process map. For this to work, the LLM would have had to:
- Identify sequential steps from unstructured narrative
- Map each step to an organizational role (swimlane)
- Detect decision points and loops
- Calculate quantitative metrics ($27,310/yr, 10.1h/week)
3.4 System Mention Linking
The demo explicitly shows system names being extracted and linked: NetSuite, SharePoint, Outlook, Teams. This is not just keyword matching. The agent asks follow-up questions about specific systems because it knows the company uses them (from connector integrations). This is a context-aware dialogue system — the agent's questions are dynamically constructed from the company's existing tool inventory.
Layer 4: The Ontology — The Hidden Architecture
This is the most important discovery from the demo, and Ontora never mentions it in marketing.
Frame 11 of the demo reveals the Knowledge Chat / Wiki view. The left sidebar shows a hierarchy:
Company
├── Departments
│ ├── Finance Department
│ ├── Product Department
│ └── ...
├── Products
├── Employees
├── Customer Accounts
├── Operating Processes
├── Connected Systems
└── Current Automation Work
This is not a document folder. This appears to be an ontology — or at least a formal taxonomy of how the company is structured. It seems every interview is parsed into this hierarchy. Every insight is tagged with its place in the ontology.
Why This Matters
Most AI knowledge tools use a flat vector store. You dump documents in. You query with semantic search. You get relevant chunks back. It is powerful and dumb.
Ontora uses a structured knowledge base with a fixed hierarchy. When the system extracts "Anna Keller handles invoice exceptions in NetSuite," it does not just store that as text. It stores it as:
- Entity: Anna Keller
- Type: Employee
- Department: Finance
- Process: Invoice Exception Handling
- System: NetSuite
- Role: Accounts Payable Lead
- Insight: High automation potential
This is the difference between a search engine and a knowledge graph. Search engines find relevant text. Knowledge graphs answer structured questions: "Which finance processes touch NetSuite and have high automation potential?"
Why This Is Hard
The ontology is fixed. What happens when a company does not fit?
- Matrix organizations have employees who belong to multiple departments.
- Platform teams own cross-cutting capabilities, not products.
- Freelancers and contractors are not "employees."
- Non-profits do not have "customer accounts."
If the ontology is rigid, the system forces every company into the same structural mold. If it is flexible, the engineering complexity explodes — you need dynamic schema evolution, user-defined entity types, and ontology merging across customers.
The demo shows a clean, fixed hierarchy. I suspect this is v1. Of course, I could be wrong — the real test is whether it bends without breaking.
Layer 5: Output & Visualization — From Graph to Decision
The demo shows three output modes:
5.1 The Executive Dashboard
A table view with interview counts, completion rates, and participant metadata. This is the "are we done yet?" view for project managers.
5.2 The Report View
Structured insights with severity tags, quotes, and system references. The demo shows a "Key Finding" card: "Invoice exceptions force Finance to reconstruct one decision packet across NetSuite, SharePoint, Outlook, Teams, and a vendor tracker before payment can move."
This is synthesized from multiple interviews, not transcribed from one. It represents a cross-functional pattern that no single employee described in full. The system connected the dots.
5.3 The Process Map
The swimlane diagram with quantified metrics. This is the "show this to the board" artifact. It looks like a McKinsey slide generated by software.
The Metrics Question
Here is where the architecture gets philosophically interesting.
The swimlane displays: $27,310/yr direct AP effort. $43,025/yr duplicate cost addressed. 10.1h/week manual effort. 247/year deferred instances.
I have no way of knowing how these were calculated, but my guess is they are either:
- LLM-estimated from interview text ("takes me about 2 hours per week" → 2h × 52 × $26/hr = $2,704)
- Connected to actual system data via the NetSuite/SharePoint integrations
- A blend of both
If my guess is right and they are LLM-estimated, they risk being perception dressed as precision. If they are system-derived, Ontora has built something much deeper than interviews — they have built a bridge between subjective narrative and objective system data.
I do not know which it is. But it is the most important question in the architecture.
Layer 6: Human-in-the-Loop — The Governance Layer
The demo shows version history. Entries like:
- "Automatic Update" (system-generated from new interviews)
- "Manual Update by David Korn" (human edit)
This suggests executives may be able to edit the knowledge base. They can override insights. They can sanitize findings.
Why This Is Necessary
No AI system should have unilateral authority over organizational truth. If the LLM hallucinates a handoff that does not exist, someone needs to delete it. If a finding is politically sensitive, someone needs to decide whether to include it.
Why This Is Dangerous
When humans edit AI-generated knowledge, the provenance chain breaks. The knowledge base becomes a mix of:
- Auto-extracted facts (from interviews)
- Executive wishful thinking (manual edits)
- Political sanitization (deleted findings)
I did not see a visible "confidence score" or "source attribution" on the wiki pages in the demo. If I am a PE firm using Ontora for due diligence, and the portfolio company CEO can edit the process map before I see it, in that scenario, the tool could become expensive theater.
The fix is simple in concept, hard in execution: every piece of knowledge needs provenance metadata — who said it, when, in which interview, with what confidence. And manual edits need to be flagged, not hidden.
The Architectural Tensions at Scale
Every system in this category faces the same five tensions. Ontora is not unique in encountering them. They may be unique in how early they have to solve them.
Tension 1: The Feedback Loop
The demo shows a "Show in sessions" toggle on knowledge base entries. This means past insights can be fed back into future interview prompts.
This is powerful. If the system knows the company uses Jira, it can ask better questions about Jira workflows. But it is also an echo chamber. If the knowledge base contains a hallucinated tool or process, subsequent interviews will validate it. Confidence increases. Error compounds.
One possible fix would be a consensus engine that flags contradictions instead of averaging them. I do not see evidence of this in the demo. It may exist behind the scenes. It may not exist yet.
Tension 2: The Ontology Rigidity
The fixed hierarchy works for traditional companies. It struggles with modern organizational designs. The question is not whether v1 is rigid — every v1 is rigid. The question is whether the schema can evolve without breaking every customer's knowledge graph.
Tension 3: The Quantification Gap
Process maps are valuable. Quantified process maps are irresistible. But quantification without validation is fiction with decimal points.
If Ontora can bridge interview data to system event logs (the Celonis approach), they become unstoppable. If they stay in the interview-only lane, their metrics will always be estimates. The demo hints at system connectors (NetSuite, SharePoint). Whether those connectors read event logs or just document metadata is the critical unknown.
Tension 4: Campaign Fatigue
The demo shows 17+ campaigns. A single employee (Anna Keller, Finance) might be interviewed for: Finance Operations, AI Transformation, Change Management, and Employee Engagement. That is 4 campaigns × 20-30 minutes = 80-120 minutes of employee time per quarter.
For 1,000 employees across 5 campaigns each, that is 1,667 hours of employee time per quarter — the equivalent of one full-time employee doing nothing but talking to Ontora. At some point, the organization pushes back.
The fix is intelligent scheduling (do not interview the same person twice in 30 days) and cross-campaign synthesis (reuse interview data across related campaigns). Both are hard.
Tension 5: The Moat Question
If the core IP is:
- Prompt templates for campaign creation
- A fixed ontology
- Voice personas
- Swimlane visualization
Then the barrier to entry is prompt engineering + frontend engineering. Microsoft, ServiceNow, or Celonis could replicate this in 6-12 months with superior distribution.
The real moat is:
- Customer-specific fine-tuned models that improve with longitudinal data
- Proprietary process ontologies built from 10,000+ interviews across industries
- Bidirectional system integration (not just reading documents, but writing automation configs back to RPA tools)
None of these are visible in the demo. That does not mean they do not exist. It means they are the next 12 months of engineering.
What I Would Watch Next
If I were evaluating Ontora as a CTO or an investor, I would ask three questions:
-
"How do you validate the $27,310/yr metric? Is it estimated from interview text, or connected to our NetSuite transaction data?"
- If it is estimated: the ROI analysis is perception-based. Useful for discovery, dangerous for decisions.
- If it is system-derived: they have built something much deeper than interviews.
-
"Can your ontology represent a platform-team structure where one team owns infrastructure across five products?"
- If yes: the schema is flexible enough for modern orgs.
- If no: they serve traditional hierarchies well and struggle with tech companies.
-
"If I delete a finding from the knowledge base, is it marked as 'executive override' or does it disappear entirely?"
- If marked: they understand audit trails and data integrity.
- If it disappears: the knowledge base is editable fiction.
Closing: The Respectful Take
Ontora built a real architecture in four months with three brilliant people. Campaign orchestration. Session state management. Multi-pipeline extraction. A fixed ontology. Swimlane visualization. Versioned knowledge base. Optional voice. Directory integration.
That does not look like vaporware. That is a genuine technical achievement under extreme constraints.
But the category they are entering — AI-native process discovery — is littered with companies that built beautiful demos and collapsed at scale. The ones that survive will be the ones that solve the hard problems: ground-truth validation, flexible ontologies, feedback loop hygiene, and quantification integrity.
Ontora has built the plane. Now they have to fly it through turbulence.
And I hope they do — I'd love to see this category succeed.
If the founders read this: I would love to be wrong about the quantification gap. Show me a validated metric that survived a six-month reality check, and I will write the follow-up.
If you're building in the agentic workforce or process intelligence space, I would love to hear how you're handling these same tensions. Drop me a note or find me on GitHub.
Sources
- Ontora Website
- YC Company Page
- YC Launch Page
- Product demo UI frames (publicly visible on ontora.com)
- Founder backgrounds (LinkedIn, GitHub, personal sites)
Methodology
Public-signal intelligence (OSINT) — all sources publicly available. No insider access. Architecture reconstructed from UI evidence, industry patterns, and first principles. I may have gotten details wrong — corrections welcome.
Published: August 2026 | Author: Sanuj Krishnan``
Top comments (0)