← All speakers

Bio, Work & Ideas

Derek Meegan

Conference affiliation: Software Engineer · Browserbase · 2026

On this page

Derek Meegan is a software engineer at Browserbase, where he builds internal agent infrastructure and tools for software development and customer support. A central project in his work is bb, a shared agent he helped develop for support investigations, data queries, feature-request capture, and code changes.

From business systems to browser infrastructure

Meegan studied management information systems and economics at Temple University before developing business intelligence and automation systems at Grant Thornton. He progressed from an internship to a senior associate role, leading delivery of an internal financial-reporting platform for a major rideshare client. The work combined software development, reporting and compliance requirements, and coordination of a growing team.

His move into browser infrastructure began with a problem in his own work. In early 2025, he and a friend were building an application that required deployed web automations. Maintaining browsers on AWS began consuming more time than developing the application itself. Stagehand led him to Browserbase, whose hosted browsers offered a way to move browser management out of his application.

Meegan published a serverless browser-automation template connecting Python Playwright code running on AWS Lambda to remote browsers on Browserbase. It includes asynchronous job submission, status tracking through DynamoDB, and automated deployment. The project also changed his career: Browserbase founder Paul Klein IV found the repository and contacted him about joining the company. Meegan recounts that transition in his reflections on his first year in San Francisco.

He joined Browserbase in June 2025 as a customer engineer, working directly with enterprise customers and building tools for debugging, benchmarking, and capturing support knowledge. He later moved into software engineering. Customer work exposed him to recurring automation failures and the information colleagues needed to resolve them—experience he brought to building an agent for use across the organization.

A shared agent for organizational work

Meegan helped build bb on an earlier internal prototype by colleague Shubhankar, collaborating with Browserbase’s engineering team on its capabilities, security, and integration into employees’ work. He and Kyle Jeong co-authored a detailed account of bb’s architecture. The system uses a common agent loop for different jobs, loading task-specific instructions and permissions rather than maintaining a separate bot for every workflow.

  • One agent, many skills: bb uses OpenCode for its core conversation and tool loop, with domain knowledge supplied through instructions loaded when needed. A support investigation can draw on log-correlation procedures; a data request can load warehouse schemas and query patterns. The same infrastructure serves interactive Slack requests and background events such as completed support tickets.
  • Scoped access and credential brokering: bb separates its execution environment from the credentials needed to reach company services. An integration proxy checks permitted operations before making requests, while selected integrations receive credentials at the network layer. Background jobs receive narrower permissions for their specific purpose. Access controls sit in the software surrounding the model, giving different workflows different permissions.
  • Reliable browser operations: Meegan’s automation guidance, co-authored with Harsehaj Dhami, turns customer-debugging experience into concrete practices. Reusing authenticated contexts avoids repeating login flows; controlling downloads through the Chrome DevTools Protocol handles PDFs that behave differently from ordinary pages. These details determine whether an automation can finish its job.

Business outcomes before autonomy

Meegan’s writing questions whether complete autonomy is always the right destination. He argues for starting with the business outcome: faster engineering delivery, shorter reporting turnaround, or better customer support. The appropriate solution may combine human judgment, AI assistance, and autonomous tasks—or require no agent at all. He treats human accountability as a consequential difference between people and models.

His work on production browser agents makes that emphasis concrete. Under a model in which each step succeeds independently with 99% probability, a 100-step workflow succeeds only about 36% of the time. Costs accumulate along the way, while the business value depends on completing the task. Meegan therefore emphasizes success per transaction, accounting for retries, rather than judging each run in isolation. His insurance-portal example combines deterministic tools, OCR verification, separately handled authentication, and task-specific skills to keep the agent focused on work that needs it.

Read the topics behind these talks

1 conference talk

Key ideas

Scroll to read ↓

Derek Meegan of Browserbase explains how small risks compound across browser workflows, why completed transactions matter more than individual runs, and how an insurance-portal architecture reduces the decisions a model must make.

  • Under independent step success, 99% accuracy compounded across 100 steps yields only about 36.6% end-to-end success. Reducing model-directed steps is a reliability lever.
    5:17 ↗
  • Define completion through a concrete artifact and measure success per customer transaction, including the attempts permitted by its retry budget.
    8:17 ↗
  • In the insurance example, separate authentication, a packaged download operation, OCR-based verification, and a workflow skill narrow the model’s responsibility to the remaining ambiguity.
    13:06 ↗
  • Production costs include browser infrastructure, integrations, observability, developer repairs, and reevaluation as websites and models change.
    9:34 ↗

References