YC Root AccessParahelp: The End-to-End AI Support Agent
CHAPTERS
- 0:05 – 3:14
From Denmark to startups: early builder DNA and founder backstory
The founders trace their roots in Denmark and how limited local startup culture pushed them to learn by doing. They describe meeting in high school, pairing engineering with design/marketing, and shipping lots of consumer projects to hone product instincts.
- •Growing up near Copenhagen and learning to code early
- •Meeting through a youth entrepreneurship organization
- •Complementary skill split: Anker coding, Mads product/design/marketing
- •Building multiple consumer apps as practice (playlists, events, etc.)
- 3:14 – 4:38
The NFT investing app: first venture, Stripe partnership, and market collapse lessons
They recount building a Robinhood-like app to buy NFTs via Apple Pay, including hard-earned regulatory and partnership wins. After launch, the NFT market crashed and user needs didn’t match what they built, forcing a reset.
- •Raised first round and moved into a tiny Copenhagen office
- •Partnered with Stripe in Europe to enable Apple Pay NFT purchases
- •Realized too late that remaining NFT users only cared about price movement
- •Key lesson: talk to users early; product quality can’t beat a dead market
- 4:38 – 5:23
Pivot discipline: three-week sprints, postmortems, and falling in love with SF
After the NFT idea failed, they adopted a rigorous pivot process: short build/sell sprints followed by written postmortems. Visiting hacker houses in the Bay Area helped them commit to a Silicon Valley-style pace and ambition.
- •Inspired by Slope’s pivot story and adopted 3-week idea sprints
- •Postmortems to prevent sunk-cost bias and enforce learning
- •First trips to SF/Berkeley hacker houses shaped their trajectory
- •Prepared them to explore B2B seriously
- 5:23 – 6:04
YC entry and the initial B2B co-pilot that wasn’t painful enough
In Berkeley they met founders who nudged them to apply to YC, and they entered with a support co-pilot concept. Early customer interest existed, but the pain wasn’t acute and sales cycles were long, signaling the need for a sharper wedge.
- •Moved into a Berkeley hacker house and applied to YC
- •Started with a customer support co-pilot concept
- •At retreat: customers were 'happy but not really happy'
- •Diagnosis: insufficiently acute pain and long sales cycles
- 6:04 – 8:04
Mid-batch pivot: betting on end-to-end ticket resolution + cold emailing at scale
Triggered by model improvements (Sonnet 3.5), they pivoted mid-batch to full end-to-end support resolution. With few network connections, Mads sent 700 personalized cold emails to land early customers and refine the software-startup focus.
- •Sonnet 3.5 made semi-reliable agentic tool use feasible with sampling
- •Pivoted to resolving tickets end-to-end instead of assisting humans
- •Sent 700 personalized cold emails in one week to find customers
- •Narrowed ICP to fast-moving software startups; prioritized deep integrations
- 8:04 – 8:54
What Parahelp is: an AI support agent for fast-moving software companies
They define Parahelp as an AI agent that resolves customer support tickets end-to-end, including taking actions in third-party systems. The product is tailored to software companies with rapidly changing internal knowledge and tooling.
- •AI support agent focused on full resolution, not just replies
- •Targets fast-moving software companies (many AI-native)
- •Integrates with core systems (billing, internal tools, knowledge sources)
- •Designed to keep up with rapidly changing policies and product context
- 8:54 – 13:05
Real actions in production: refunds, approvals, and safe tool execution
A concrete example is handling refund requests by evaluating eligibility and executing refunds in Stripe. They explain guardrails like Slack approval flows for sensitive actions while keeping customer conversations moving in parallel.
- •Refund workflow: interpret policy criteria, verify, then execute in Stripe
- •Sensitive actions can require Slack-based human approval
- •Agent continues customer communication while awaiting approval
- •Emphasis on reliability and policy adherence for money-moving tools
- 13:05 – 14:52
Why AI-native companies buy (instead of build): knowledge management + evals as moat
They explain why 'built-in AI' in Intercom/Zendesk and many internal builds fail over time: knowledge goes stale and tool calling lacks robust guardrails. Parahelp’s differentiator is continuous evaluation/monitoring to prevent regressions at scale.
- •Default helpdesk AIs work only for no-tool, simple tickets
- •Hard part is continuously connecting/updating knowledge across Linear/Notion/Slack/etc.
- •Tool calling requires guardrails, validation, and always-on monitoring
- •Heavy investment in automated evaluations to prevent regressions
- 14:52 – 17:46
Scaling outcomes: thousands of tickets closed daily and moving upmarket in responsibility
They discuss reaching a level where manual monitoring isn’t possible, requiring automated systems. Trust increases over time—some customers allow Parahelp to handle large enterprise accounts, and Slack-based B2B support becomes a key channel.
- •Parahelp helps close thousands of tickets per day
- •Early days: manual observation; later: automation required
- •Progression to handling enterprise accounts (e.g., 1,000-seat customers)
- •Growing demand to support customers directly inside Slack
- 17:46 – 19:25
Memory files and proactive knowledge upkeep: making the core agent 'simple'
They describe a ‘memory’ system where the assistant maintains structured knowledge files and edits them as products change. This allows the runtime agent to stay general while still handling deep, tool-heavy troubleshooting and long-horizon reasoning.
- •Assistant builds/maintains a file-system-like knowledge base (memory files)
- •Proactive updates triggered by new features, tickets, and internal signals
- •One agent can answer quickly or reason for minutes with many custom tools
- •Handles complex debugging (Datadog, SSO policies, screenshots, etc.)
- 19:25 – 24:00
Next-gen architecture pivot: from forward-deployed engineers to an AI that generates evals
To avoid scaling via manual onboarding work, they paused growth to rebuild architecture once a stronger model (Opus 4) enabled dynamic eval generation. The result is an ‘AI forward-deployed engineer’ that configures, tests, and improves deployments without bespoke human prompt work.
- •Earlier approach required custom prompt optimization per customer
- •Growth bottleneck: forward-deployed engineering doesn’t scale with demand
- •Opus 4 enabled on-the-fly generation of evaluation sets
- •Now: no custom eval sets written manually; agent does it during onboarding
- 24:00 – 28:15
Research agent flywheel: analyzing up to 20k tickets to propose improvements and ship releases
They introduce a research system that searches large ticket corpora, analyzes representative samples, and produces actionable reports. Support managers can convert findings into policies/tools inside the same workflow, creating a continuous improvement loop that measurably lifts resolution rates.
- •Searches semantically + grep-like across up to 20,000 tickets
- •Sub-agent context management to deeply analyze 50–500 tickets
- •Produces reports with sources + suggested policy/tool changes
- •Observed 12–15 point end-to-end resolution gains at Perplexity after launch
- 28:15 – 35:03
Beyond support: mass follow-up, revenue actions, churn prevention, and org-wide knowledge utility
They expand the vision from closing tickets to proactively following up on backlogs, re-engaging feature-requesters, and enabling upsells/discounts with policies. Parahelp also becomes an internal knowledge hub used by sales, engineering, product, and leadership for analytics and feedback loops.
- •Mass follow-up to clear backlogs (e.g., 700 tickets) via agent swarms
- •Support-to-revenue: upsell links, discounts to prevent churn, outreach to churned users
- •Operational scaling challenges and orchestration tooling for bursts
- •Company-wide usage: internal Q&A channels, sentiment/refund analytics, feature request mining
- 35:03 – 42:36
Product walkthrough: the Parahelp Assistant UI, modes, policy diffs, and automated testing
They demo the Assistant as the control plane for configuring policies/tools and running tests before publishing. The system uses distinct ‘modes’ (ask/configure/test/research) with separate prompts/tools, produces diff-style edits, and runs YAML-based scenario tests with mock context (including outages).
- •Assistant lives in Slack and an app; agent lives in the ticket system
- •Mode-based multi-agent workflow: Ask → Configure → Test → Deep Research
- •Diff-based policy/knowledge updates with conflict resolution across files
- •Automated scenario testing (YAML, mock context, status-page outage simulation)
- 42:36 – 44:48
Series A: why they chose Jack Altman/Alt Capital and board-level partnership fit
They share that the Series A was led by Jack Altman (Alt/Old Capital) with additional participation and strong insider support. Their choice emphasized close working relationship and alignment—especially important because it’s their first board-add round.
- •Round led by Jack Altman; Hanabi participated; insiders also joined
- •Met Jack post–Demo Day; built conviction through repeated interactions
- •Valued hands-on partnership over large-platform VC services
- •Board seat made alignment and trust the deciding factor
- 44:48 – 47:40
Founder advice: absorb SV history, act fast, and embrace failure to play offense
They close with advice for aspiring founders—especially in places where startup culture is thinner. The message: learn from Silicon Valley history, jump into building, and treat failure as the cost of moving aggressively rather than playing defense.
- •Read deeply (e.g., Paul Graham) to internalize startup thinking
- •‘Just do it’: learning comes from shipping and trying many things
- •Cultural contrast: Denmark’s fear of failure vs strong safety net
- •Play offense; avoid optimizing for what you’re afraid to lose
