Safely manage your Zendesk from the AI assistant you already use, via the Deltastring MCP. Beacon configuration platform →
← Back to news

Airbyte's Pedro Lopez Says Agents Need Their Own Interfaces, Not Human-Friendly Ones

Zendesk

Pedro Lopez's argument that AI agents require fundamentally different interface design than human-facing tools represents a critical inflection point for CX infrastructure. Airbyte's practical experience building two agent-facing interfaces—a Model Context Protocol server and CLI—reveals that the conventions CX teams have relied on for years actively sabotage agent performance. The core insight is architectural: exposing narrow tool surfaces with JSON I/O, persistent sessions, and non-interactive authentication patterns outperforms human-friendly design every time. This matters directly to your stack because it signals that the next generation of integrations between Zendesk, Freshdesk, Salesforce and emerging agent platforms will not look like the API documentation you know. OAuth becomes mandatory rather than optional, session management inverts from stateless web patterns to mobile-app-style persistence, and the entire contract between tool and consumer shifts from discoverability through documentation to progressive discovery through agent interaction. For teams already running Agentforce or considering agent-native workflows, this means your current connector architecture may be optimised for the wrong consumer.

The specification-versus-implementation gap Lopez identifies poses an immediate operational risk. The MCP spec exists, but Claude Desktop does not support URL-mode elicitation, forcing Airbyte to build credential flows outside the standard. This fragmentation means that vendor claims about "spec compliance" are marketing noise—what matters is what Claude, ChatGPT, and other agent platforms actually implement. CX teams evaluating new integrations should demand not spec alignment but tested, working implementations across the specific agent platforms your organisation uses. The practical implication is that smaller vendors claiming MCP or agent-native support without demonstrating working flows across multiple clients are selling incomplete products. Simultaneously, Lopez's recommendation to use both MCP and CLI—MCP for non-technical users and prototyping, CLI for long-running tasks and complex outputs—suggests that your integration strategy cannot be monolithic. This creates a new operational burden: maintaining multiple interface layers, each with different versioning, distribution, and failure modes. The question worth asking is whether your current vendor partnerships are prepared to maintain this dual-interface complexity, or whether you will need to build abstraction layers internally to shield your teams from the underlying fragmentation.

The deeper implication concerns how CX teams should interpret agent errors going forward. Lopez reframes repeated agent mistakes not as user error but as contract bugs—a signal that the interface design has failed. This inverts the traditional support model where human error is the default explanation. For CX leaders, this means agent-driven workflows will require new diagnostic frameworks and potentially new vendor accountability standards. If your Zendesk or Freshdesk integration is causing agents to loop, retry, or call the wrong endpoint repeatedly, the failure is not the agent's reasoning but your interface's clarity. This shifts responsibility upstream to integration design and forces a conversation about whether your current vendor partnerships are equipped to iterate on agent-facing contracts as rapidly as agent capabilities evolve. The infrastructure layer is moving faster than the CX tooling layer, and teams that treat agent interfaces as a one-time integration project rather than an ongoing design practice will find themselves managing increasingly brittle systems.