Merge automated dinner planning: from dozens of hours to 30 minutes per event

Case studies that claim “we use AI for everything” are usually empty. This one includes a couple of concrete details worth examining: how an event-planning bot works and what the company says about tool-call reliability. A caveat up front: this is a customer story published on OpenAI’s blog, meaning it is vendor-produced material, and the figures cannot be independently verified.

What the dinner bot does

Merge sells infrastructure for AI products: customer-data synchronization, secure agent access to tools, model routing, and cost controls. The company also uses some of its own products internally.

One example is a series of private dinners for customers and prospects. For a dinner in Dallas, the team specified the city and the target guest profile. The bot then pulled candidates from the CRM and Apollo, checked previous invitations and responses, and prepared an outreach campaign in the name of CEO Shensi Ding. It also maintains the attendee spreadsheet, suggests seating arrangements, and creates calendar notes where sales and customer success teams add context about each guest.

The division of labor is straightforward: the model reasons and drafts copy, while Merge connectors provide access to Salesforce, Gong, Google Sheets, and Gmail. Ding reviews the output, rewrites phrases that sound inauthentic, and personally finalizes the guest list because the bot lacks the context of personal relationships.

According to the company, preparing lists and emails and maintaining the spreadsheet previously took the team dozens of hours; it now takes about 30 minutes per event. The comparison covers the same tasks over a three-month period. At the same time, the number of dinners increased from 8 in Q2 to 16 in Q3, with more than 30 planned for Q4.

What developers can learn from this

The main point concerns reliability. Merge claims that tool calls made through its layer succeed 99.9% of the time, compared with roughly 60% through public MCP servers. The company does not disclose its comparison methodology and sells precisely the layer that supposedly solves this problem. Still, the underlying issue will be familiar to anyone who has built agents: the model may be good, while the chain fails on authentication, schemas, or integration timeouts.

The second detail is the use of Codex for code review. Ding showed how it helped with a new tool-access settings tab: the team discussed how to make the “Add tool pack” button clearer. People made the decisions, while engineers remained responsible for verification and release. That is an honest setup: the reviewer offers suggestions, but responsibility stays with the team.

The third point involves workflows for non-engineers. The head of sales created repeatable workflows for deal approvals, forecast updates, and follow-up steps after renewal calls. Instead of reconstructing the context every time, he receives prepared material and makes the decision himself.

Limitations

First, this is promotional content. The “before and after” time was measured by the company itself and excludes the cost of developing and maintaining the bot. Second, the bot sends emails in the CEO’s name, so a mistake in the recipient or tone could damage her reputation. That is why a person still reads everything before it is sent. Third, growth in the number of dinners does not prove revenue growth: the case study provides only positive feedback and demo opportunities.

Praise for the model’s “personality” and its ability to infer what was left unsaid is better treated as a user impression than as a measurement.

Practical takeaway

If you are building agents, measure the tool-call success rate separately from model quality: that is where reliability is most often lost. For internal automation, choose a narrow, repeatable process such as preparing lists and outreach, while leaving final review and sending to a person. And test the entire setup first on a new product that has not yet attracted customers, as Ding herself advises.