CHAPTERS
- 0:05 – 0:25
Second-time YC founder: introducing Sherwood and Sazabi
Sherwood Callaway joins Aaron Epstein to discuss returning to Y Combinator for a second time. He previews Sazabi and why this batch will be a different, more intentional experience.
- •Sherwood is entering YC again after exiting his first YC company
- •Goal: introduce Sazabi to the new batch and broader world
- •Framing the conversation around lessons learned and a new focus
- 0:25 – 1:36
Sazabi’s product: AI-native observability that finds and fixes production issues
Sherwood explains Sazabi as an AI-native observability platform built for fast-moving engineering teams. The core promise is moving debugging from manual spelunking to question-driven, AI-assisted incident resolution.
- •Positioning: “Datadog/Sentry built in 2026,” designed for modern teams
- •Pain: hours lost digging through dashboards, logs, flame graphs during outages
- •AI coding changed building software; maintaining/debugging hasn’t kept up
- •Natural-language questions: why prod is down, what an error means, who’s affected, which commit caused it
- 1:36 – 3:43
The hot take: “Logs are all you need” (and why AI changes the tradeoffs)
Sazabi’s manifesto includes a contrarian claim that logs alone can power effective observability. Sherwood contrasts this with the traditional ‘three pillars’ model and argues AI makes unstructured logs far more valuable.
- •Core principle: consolidate observability around logs to reduce instrumentation burden
- •Traditional model requires logs + metrics + traces (multiple tools and setups)
- •Logs are simplest for developers (print statements, readable streams)
- •AI can now parse and reason over unstructured log text at scale
- •Agents can derive insights and explanations directly from log lines
- 3:43 – 4:47
Career origin story: from front-end to infra obsession via CI/CD
Sherwood traces how he moved from front-end work into infrastructure by tackling slow builds and deployments. That rabbit hole sparked a long-term focus on reliability and developer productivity.
- •Started as junior front-end engineer at Crunchbase
- •Took on CI/CD performance problems because “important stuff” was off-limits
- •CI/CD work led into infra/DevOps responsibilities
- •Developed an obsession with reliability and faster, higher-quality shipping
- 4:47 – 6:32
Building observability at Brex during hypergrowth
At Brex, Sherwood helped scale foundational infrastructure and then formalize observability as microservices and team ownership expanded. He describes observability as the discipline of answering production questions when reality diverges from pre-release plans.
- •Joined Brex early as one of the first infrastructure engineers
- •Helped build staging/prod, microservice framework, CI/CD through hypergrowth
- •Kubernetes + many microservices created visibility/ownership challenges
- •Helped start the observability team to restore clarity in production
- •Observability philosophy: production is unpredictable; prepare to respond effectively
- 6:32 – 7:42
What the Brex observability team actually built and rolled out
Sherwood details the concrete work behind a mature observability program: auto-instrumentation, telemetry pipelines, Datadog configuration, dashboards, monitors, and reliability practices. He also describes driving SLO/SLI adoption across teams.
- •Auto-instrumentation so new services inherit logs/metrics/traces automatically
- •Infrastructure for capturing and forwarding telemetry to observability systems
- •Deep Datadog setup/tuning across many modules and knobs
- •Dashboards and monitors for every service’s key metrics
- •Promoting SLO/SLI practices so teams measure and manage reliability
- 7:42 – 8:54
Why leave Brex: long-held startup ambition and the pandemic catalyst
Sherwood explains that founding a YC-backed startup was a goal since early in his career. During the pandemic in New York, he and his roommate/cofounder began exploring ideas seriously and applied to YC.
- •Came into tech via SF bootcamp; absorbed YC/startup culture early
- •Long-term goal: build a venture-backed startup and do YC
- •Pandemic and being “stuck” in NYC created time and momentum to ideate
- •Applied to YC with a cofounder after deciding they had a special team
- 8:54 – 12:58
Opkit: choosing healthcare voice AI and the ‘MBA case study’ trap
Sherwood describes Opkit (YC S21) as a healthcare voice AI company automating calls to insurers. He reflects that the choice was more opportunistic and theoretical than grounded in personal insight, creating misalignment with the founders’ strengths.
- •Built LLM-based voice agents for eligibility checks, prior auth, and claim status calls
- •Picked healthcare partly due to family connection (father is a doctor) and access to SMEs
- •Thesis-driven thinking: vertical fintech/healthcare as a big market opportunity
- •In hindsight: idea selection was not based on personal passion or deep firsthand pain
- •Key advice: build from prior expertise and strengths rather than fleeing what you know
- 12:58 – 15:55
Sunk cost and delayed reckoning: when to reconsider the core idea
The conversation turns to whether there were warning signs Opkit wasn’t the right fit. Sherwood notes they gradually became competent in healthcare, which made it harder to step away, but they didn’t fully evaluate the 10-year commitment or founder-market fit.
- •They started as the wrong team, but gained credibility and domain knowledge over time
- •Sunk cost fallacy: accumulating expertise made quitting harder
- •Should have asked earlier: do we want to spend 10 years in this space?
- •Naivete can help, but success requires years of ramping, trust, and networks
- •Sazabi decision: re-align product, market, and identity with who Sherwood is
- 15:55 – 18:01
Opkit’s late-stage pivot, fundraising reality check, and acquisition path
Sherwood outlines Opkit’s evolution from revenue-cycle SaaS to leveraging LLMs for call QA and data extraction, then to a voice agent product. With limited runway and muted investor enthusiasm, they chose to pursue acquisition rather than extend the journey.
- •Initially built RCM SaaS for insurance checks and claims submission
- •Discovered many insurer operations require phone calls; built a Philippines call center
- •Used LLMs for QA and data entry; then built a commercialized voice agent early in the cycle
- •With ~6 months runway, fundraising conversations lacked pull
- •Decision: seek acquirers instead of forcing a seed extension
- 18:01 – 20:24
From ElevenX back to the ‘end of manual debugging’: the spark for Sazabi
After joining ElevenX and rebuilding a voice-agent product, Sherwood fell back into the familiar pain of being the on-call/debug person. The contrast between futuristic AI products and primitive debugging workflows crystallized the opportunity for Sazabi.
- •Joined ElevenX (AI sales tech) via network connection; wanted to be closer to AI
- •Rebuilt the AI SDR product and migrated to a new platform
- •Returned to maintenance/on-call mode and re-implemented the usual tooling (Datadog, CI/CD)
- •Realization: debugging remained manual despite AI advances elsewhere
- •Conclusion: apply the same AI step-change to observability/maintenance work
- 20:24 – 22:47
What changes this time: founder-market fit, fun, and the self-healing vision
Sherwood explains how Sazabi is designed to be aligned with his strengths and enjoyable to build. He also lays out a long-term vision: self-healing software that improves without human intervention, focusing on maintenance as the larger share of engineering effort.
- •Key lesson applied: build something you know; align with experience and passion
- •Intentional identity: selling to startups like those he’s worked at; even naming reflects personal interests
- •Aiming for a product that feels great ("Linear of observability" vs legacy UX)
- •Mission: default observability tool for the AI era (agentic future)
- •North star: self-healing software; bigger opportunity is maintaining existing systems
- 22:47 – 25:15
Why do YC again: speed, culture, distribution—and the in-person experience
Sherwood gives practical and personal reasons for returning to YC despite already being in the network. He emphasizes urgency in the market, YC’s forcing function for shipping and go-to-market, and the chance to build distribution by selling into fellow YC companies.
- •YC as acceleration: the opportunity window is short and competitive
- •Culture-setting: deadlines and cadence push fast shipping and commercialization
- •Avoiding the trap of “building forever” with a large engineering-heavy team
- •Distribution: every software company needs observability; YC network is direct GTM leverage
- •Personal: first batch was remote; wants the full in-person Demo Day experience
- 25:15 – 29:42
Founder lessons and hiring: long-horizon integrity + the kind of engineers Sazabi needs
Sherwood reflects on startups as a long-term compounding game where relationships and reputation matter. He then describes the traits and roles Sazabi is hiring for, emphasizing high-agency builders across infra, data, product, and design-focused engineering.
- •Advice to past self: think long-term; relationships with batchmates/investors compound
- •Operate with integrity; today’s contacts may be tomorrow’s customers or funders
- •Hiring traits: high agency, fast learners, tool-lovers, flexible self-starters
- •Former founders valued for scrappiness and willingness to do unsexy work
- •Open roles: infra/data/storage (custom log ingestion/storage), full-stack, front-end/design engineering
