How We Integrate an AI Agent With Your Existing POS, TMS, and Delivery Stack — Without Replacing Anything

When operators evaluate an AI agent, the first question is rarely about the AI. It is about the spaghetti underneath: the POS that the kitchen runs on, the reservation platform the host team trusts, the delivery aggregators that account for a third of revenue. "I am not ripping any of this out" is the default — and it should be. Stable systems are more valuable than perfect systems.

Qendrix is built for that constraint. The agent is the orchestration layer. The POS, TMS, and delivery stack stay where they are. This post is the engineering walk-through of how we make that work in practice, including the failure modes we have learned the hard way.

The integration model in one sentence

Qendrix maintains a real-time mirror of three pieces of state — availability, menu, and guest profile — and writes back to the systems of record through their native APIs. Conversations happen against the mirror. State changes get pushed to the upstream systems within milliseconds, with retries and reconciliation when the upstream is slow or unhappy.

What we connect to today

• Reservation platforms: OpenTable, TheFork, CoverManager, SevenRooms, Resy.
• POS systems: Lightspeed, Toast, Square for Restaurants, Revel, Hiopos, plus several regional players.
• Delivery aggregators: Uber Eats, Deliveroo, Glovo, Just Eat. Read-only for now on the agent side.
• Telephony: Twilio, Vonage, native SIP trunks, and on-prem PBX systems via SIP gateways.
• Messaging: WhatsApp Business API, Instagram Graph API, Google Business Messages, Telegram, web chat.

We also build custom integrations. About 20% of our deployments include at least one custom connector — usually a regional POS or a hotel PMS. The agent does not need every integration to be present from day one; we phase rollouts so the operator sees value within the first week.

Why integrations break, and what to do about it

Most integration failures are not bugs. They are timing. Reservation systems update availability seconds or minutes after a booking. POS systems push menu updates as flat files at 4am. Delivery aggregators rate-limit aggressively. The agent has to behave correctly while the upstream systems lag.

Our approach has three rules. First, never trust a stale read for high-stakes writes — when a guest says "book me for Saturday at 9," we re-read availability inside the same transaction. Second, always reconcile asynchronously — every booking is double-checked against the upstream within sixty seconds, and any divergence triggers a host alert. Third, always degrade gracefully — if the upstream is unreachable, the agent offers a hold rather than a confirmed booking, and the host resolves it within minutes.

Menu sync: the unglamorous workhorse

Most of an integration's value is in the menu. The agent cannot answer "is the burrata still on?" if it does not know that the burrata was 86'd at lunch. We pull POS menu state every five minutes during service and listen for webhooks where supported. For systems without webhooks, we built a lightweight in-restaurant relay that taps the POS terminal and pushes deltas to us within seconds.

We also normalize menu data aggressively. Every dish gets a structured profile — allergens, dietary tags, courses, modifiers, average ticket — even if the underlying POS treats it as a flat string. This is what lets the agent answer "is anything gluten-free under 20 euros?" without the operator having to enter that data twice.

Telephony: the part that is harder than it looks

Phone integration is where most projects stall. We support three modes. Mode one: Qendrix provides the phone number, the operator forwards their existing line to it. Easiest, most common. Mode two: SIP trunking — we plug into the operator's existing telephony directly, no number changes. More work, fewer surprises for guest-facing collateral. Mode three: PBX bridging — for restaurants inside hotels with on-prem phone systems, we install a local SIP gateway that routes calls through us while the PBX continues to do everything else. We have run this at five-star hotels with no end-user disruption.

Security and data residency

Guest data is operator-owned, end of story. We are EU-based, our default deployment region is Frankfurt, and we offer Spain, France, Italy, Portugal, and Ireland on request. We never train shared models on operator-specific data. Each restaurant's agent runs against its own retrieval index, and the index can be wiped on request within hours.

What rollout looks like, week by week

• Week 1: Discovery, integration mapping, sandbox provisioning, content ingestion (menu, hours, FAQs).
• Week 2: Channel hookups (WhatsApp, Instagram, phone). Soft launch on one channel for staff testing.
• Week 3: Live with guests on all channels. Daily reviews with the GM. Edge cases logged and tuned.
• Week 4 onward: Steady-state operation. Weekly performance review until the operator is comfortable, then monthly.

Most restaurants are fully live inside three weeks. The systems they were already running stay exactly as they were. The agent just makes them louder.