Rootly and Anthropic Bring AI Reliability to NYC Dinner

Rootly and Anthropic are convening an approval-only executive dinner at Huso in New York's Tribeca neighborhood to discuss incident management and AI-driven reliability. The Rootly AI x Anthropic Executive Dinner (NYC) brings the conversation into a private dining setting, where engineering leaders can examine what happens when an AI recommendation reaches someone responsible for a live service.

GarysGuide lists November 18 at 6 PM, with other event calendars identifying the year as 2026. Attendees should confirm the timing with the host through Luma; the organizer's readable public listing does not expose a date or time, and registration requires approval.

The premise has weight because a production incident turns abstract confidence into an immediate decision. Someone has to judge the evidence, authorize the action and explain the result, even when an agent supplies the proposed answer. For reliability and engineering leaders, that responsibility gives this dinner a sharper purpose than another general conversation about AI adoption.

A reliability conversation at Huso

The organizer describes a peer discussion about incident management, resilient engineering and the future of AI-driven reliability. A 12-course tasting menu is part of the announced format. Huso's own materials identify Buddha Lo as Executive Chef, while its contact page confirms the 323A Greenwich Street address in New York, NY 10013. The chef's role explains the culinary setting; no technical speaking role is announced for him.

An approval-only dinner creates a particular kind of opportunity. A smaller discussion may let an operator ask a follow-up, describe a messy dependency or explain why an apparently sensible recommendation would be dangerous inside a specific system. Those possibilities depend on the people who attend and the candor they bring. Neither a guest roster nor a named speaker or moderator lineup appears on the organizer's public page.

Engineering executives, SRE leaders and platform owners have a direct reason to consider the subject. Their teams must connect an alert to an investigation, an investigation to a decision and a decision to an accountable person. A conversation among peers can expose where those connections break down. The published format offers a setting for that exchange, without promising a training program, product demonstration or particular commercial outcome.

AI recommendations need an operating history

Rootly's production AI page describes a system that draws on service relationships, ownership, recent changes and past incidents. These are company descriptions of how its tools are intended to work, rather than independent evidence of a particular reliability improvement. They nevertheless identify a concrete problem for the dinner: a recommendation needs context from the system it proposes to change.

Consider the questions an engineering leader could bring. Does the suggested cause fit the sequence of changes? Is the agent drawing on an old incident whose circumstances differ? Can a responder inspect the evidence before accepting a proposed action? These are editorial preparation questions, not a claim that the hosts have committed to addressing each one. They give the discussion something more demanding than a tour of attractive capabilities.

Anthropic's Claude Agent SDK engineering guidance describes an iterative process of gathering context, taking action and verifying the work. That provides a relevant comparison with Rootly's emphasis on production knowledge. In incident response, each part of that process carries an operational cost: collecting evidence takes time, actions need boundaries, and verification must say whether the service actually recovered. The dinner's announced topic puts those costs within reach of a practical conversation, even though no joint technical architecture or new integration has been announced.

What engineering leaders should bring to the table

The most revealing example may be an ordinary incident with an awkward handoff. An agent has produced a plausible explanation, a responder is halfway through an investigation and another team owns the affected dependency. Walking through that example would make questions of access, escalation and responsibility concrete. Operators considering attendance can prepare an anonymized case without exposing customer data or confidential system details.

The commercial implications follow from those choices. When evaluating AI reliability tooling, a buyer needs to understand the investigation it supports, the evidence a responder can inspect and the authority the system receives. A confident summary alone leaves those decisions unfinished. The dinner gives senior leaders a place to compare the questions they ask vendors and their own teams, with the eventual value depending on the quality of the exchange.

DevCuration's coverage of AI Coding Summit NYC's release-decision questions examines a related responsibility earlier in the software lifecycle. Its Build & Connect NYC preview considers architecture and judgment during AI-assisted development. Rootly and Anthropic's dinner brings that responsibility into incident response, where the system already has users waiting and a decision cannot remain an interesting theoretical question.

Before requesting a seat

The original Luma page is the registration destination, and host approval is required. Date and start-time details in this preview come from third-party calendars and should be reconfirmed with the organizer. Published end times vary, so this article does not give a confirmed finish time. Readers should also check current availability and any dietary or access arrangements directly with the host.

At the next incident review, an engineering leader may have to explain why a hypothesis was trusted, who authorized a change and what the team learned from recovery. The Huso discussion can begin with the handoff that still makes that explanation difficult.