Pedro S. Lopez is the creator of whatsapp-web.js, an open-source Node.js library for automating WhatsApp Web. His engineering work spans reverse engineering, customer-data synchronization, and interfaces that let AI agents reach business systems. At Airbyte, where he worked as a software engineer, he has explored how integrations can give agents useful data while preserving user permissions.
From browser internals to data integration
With whatsapp-web.js, Lopez gave developers a programmatic interface to a messaging application ordinarily operated through a browser. The library uses Puppeteer to run WhatsApp Web and access its internal functions, exposing messaging capabilities through JavaScript objects and events. A developer can receive an incoming message and respond through a small event handler. This unofficial integration also carries maintenance demands and account-blocking risks because it depends on a changing third-party application.
Lopez’s supporting work reaches beneath that interface. He adapted moduleRaid, originally developed by pixeldesu, for the Webpack 5 implementation used by WhatsApp Web. His version extracts bundled modules and provides ways to find their exports and functions. Together, these projects show how he makes browser-based capabilities available to developers: locate the functions inside an application, then expose them through an interface other software can use.
Before Airbyte, Lopez was an early engineer at Grouparoo, an open-source customer-data synchronization framework. Grouparoo worked on reverse ETL: moving data from warehouses into operational applications so businesses could act on information they had already collected. When Airbyte acquired Grouparoo in April 2022, Lopez joined Airbyte’s Connectors team, extending that integration work to a platform connecting many sources and destinations.
Giving agents usable, permission-aware data
Lopez’s writing on agent-driven integration examines what changes when software agents use these connections. Agents need to discover capabilities during execution and retrieve information across applications, while integration infrastructure must handle authentication, changing schemas, stale data, and records that identify the same customer differently across systems. His approach separates those responsibilities from the agent’s reasoning logic.
Permissions that follow the user: Lopez argues that an agent’s access must follow the person making the request. A shared service account can otherwise expose records that person could never retrieve directly. Copying records into a searchable index must also preserve their original access controls; making data easier to retrieve cannot justify broadening who can retrieve it.
Connectors tested for useful answers: His work with Airbyte’s agentic connector factory uses phased discovery, testing against live APIs, and readiness checks to guide connector generation. Validation includes “golden questions”: whether the connector can supply the information needed to answer useful questions. This tests the integration’s purpose as well as its code.
Interfaces agents can operate reliably: In his work on Airbyte’s MCP and command-line interfaces, Lopez describes two thin interfaces over one platform, built from OpenAPI specifications. They expose Airbyte’s Context Store, a search-optimized index of data from applications such as Zendesk, Stripe, and HubSpot. His CLI design favors JSON input and output, consistent noun–verb commands, bundled skills, and execution without interactive prompts. For MCP, he emphasizes a small initial tool set with progressive discovery, OAuth authentication, and long-lived sessions. These choices address how agents find operations, invoke them consistently, and retain usable access across extended interactions.
Pedro Lopez explains how Airbyte exposes the same data platform through MCP and a CLI—and why discovery, authentication, structured output and client limits determine which interface works for an agent.
Keep interfaces thin over shared APIs, and use OpenAPI specifications to help them follow a frequently changing platform.
MCP authentication must fit real client UIs and long-lived session expectations; protocol features such as URL elicitation still depend on client support.
MCP makes conversational access convenient and updates centrally; a CLI supports longer tasks and Unix output processing, while adding package-versioning and runaway-loop concerns.