← All speakers

Bio, Work & Ideas

Ben Hylak

Conference affiliation: Raindrop · 2026

Ben Hylak is co-founder and chief technology officer of Raindrop, which builds tools for finding, investigating, and repairing failures in production AI agents. His work combines interface design with operational reliability: making open-ended software understandable to users and its unpredictable behavior diagnosable to engineers.

From spatial computing to agent infrastructure

Hylak completed avionics engineering internships at SpaceX before joining Apple, where he worked in engineering and human-interface design and helped develop the first version of visionOS for Apple Vision Pro. Spatial computing forced him to confront situations conventional interfaces seldom encounter: applications following users between rooms, accommodating different physical abilities, and remaining coherent in environments designers cannot fully anticipate.

After Apple, he worked with Zubin Koticha and Alexis Gauba on Sidekick, a Visual Studio Code extension. Their experience building AI software exposed a practical blind spot: conventional monitoring could identify exceptions but struggled to explain plausible answers that misunderstood users or quietly failed. The team subsequently built Dawn, an AI analytics company that evolved into Raindrop.

Hylak also developed a distinctive approach to reasoning models. His analysis of OpenAI’s o1 argued that stronger results depend on supplying detailed goals, relevant context, and explicit deliverables; his assessment of o3-pro, co-authored with Gauba, extended that principle to organizational context, tools, and model harnesses. Greater model intelligence does not eliminate the difficulty of communicating intent.

  • Unbounded products need visible structure. Drawing on his work with visionOS and multimodal interfaces, Hylak argues that products accepting open-ended language, images, and environmental inputs require recognizable hierarchy, familiar controls, examples, and presets. Durable artifacts should remain separate from transient chat so users can continue working without losing the object they created.
  • Raise the reliability floor. Hylak distinguishes an agent’s most impressive capability from its worst plausible behavior: deleting data, inventing policies, or taking inappropriate autonomous actions can destroy trust regardless of benchmark performance. His agent-evaluation guide favors targeted, code-aware regression tests grounded in real failures over brittle checks tied to particular tools or models.
  • Make production failures actionable. Effective monitoring combines explicit signals such as tool errors and regeneration with implicit indicators including refusals, frustration, and unmet user intent. Hylak argues that an operational issue must reveal when it started and whom it affects; loosely grouped conversation clusters can conceal distinct causes and resist reliable tracking.
  • Connect detection to verified repair. Raindrop Workshop provides open-source local tracing, replay, coding-agent debugging, and evaluation generation. Raindrop Triage investigates incidents through Slack, the web, and the Model Context Protocol. Together, they support a self-healing agent workflow that identifies failures, investigates their causes, proposes fixes, generates regression tests, and checks whether production behavior actually improves.

Read the topics behind these talks

4 conference talks

Key ideas

Scroll to read ↓

Reliable AI products emerge from observing real user intent, detecting specific failures, and turning recurring tasks into workflows that teams can improve independently.

  • What should you improve after the demo works?
    0:30 ↗
  • A correct answer can still miss the task
    1:48 ↗
  • Better models still need context
    6:05 ↗
  • Evaluations cover the failures you know
    8:30 ↗
  • Combine signals with user intent
    11:04 ↗
  • Make issue discovery a continuous practice
    13:15 ↗
  • Guide the variability that makes the product compelling
    14:10 ↗
  • Turn observed intent into dedicated workflows
    15:56 ↗
  • Rank improvements by impact you can achieve
    17:02 ↗
  • Keep changes accountable to one workflow
    17:51 ↗

Key ideas

Scroll to read ↓

Reliable agents need more than impressive capabilities: they need tests of the whole system, production issues tracked over time, and clear boundaries between detection and investigation.

  • What actually makes a deployed agent better?
    0:15 ↗
  • When the harness changes, what does the test still mean?
    3:57 ↗
  • The product team’s responsibility
    7:10 ↗
  • Test the whole agent, locally
    11:28 ↗
  • Turn strange behavior into an actionable issue
    13:08 ↗
  • A cluster is not an operational issue
    15:31 ↗
  • Express trace classifiers as code
    18:11 ↗
  • Detect a signal, then ask an agent to investigate
    18:38 ↗

Key ideas

Scroll to read ↓

Reliable agents need evidence from real trajectories: operational metrics, semantic issue signals, and reports that reveal how a task was actually completed.

  • What happens outside the golden dataset?
    0:52 ↗
  • Measure specific issues
    3:33 ↗
  • Turn cheap signals into release feedback
    6:38 ↗
  • Useful evidence is not always statistical significance
    9:42 ↗
  • Use signals to direct investigation
    13:22 ↗
  • Ask the agent what happened
    16:10 ↗
  • A failed write becomes a successful workaround
    21:06 ↗
  • From full trajectories to product-specific classifiers
    32:22 ↗
  • Discover failures you did not name in advance
    36:07 ↗
  • Integrate without stopping the release cycle
    38:55 ↗
  • Separate experiment controls from historical analysis
    42:41 ↗
  • Inspect the sequence, not only the outcome
    44:19 ↗
  • Keep labeled evidence usable—and customer data bounded
    47:46 ↗

Key ideas

Scroll to read ↓

As AI expands what users can ask, show, and change, interface structure becomes essential: it reveals capabilities, keeps work stable, and makes personalization understandable.

  • How do users know what a product can do?
    0:29 ↗
  • From visible buttons to open-ended situations
    4:07 ↗
  • Give the unfamiliar a recognizable shape
    7:04 ↗
  • A journal and a search engine should not feel the same
    9:45 ↗
  • Keep the work from drifting away in chat
    11:29 ↗
  • Make changes recoverable and context understandable
    13:08 ↗
  • Make agent steps visible as columns
    14:24 ↗
  • Offer a useful starting point
    15:24 ↗
  • Direct controls need more than broad labels
    16:21 ↗
  • From coarse presets to feature steering
    17:43 ↗
  • Retrieve the right controls, then personalize them
    18:30 ↗
  • Measure whether the result fits the user
    19:30 ↗

References