Elyra

Elyra is a restaurant operations platform built around AI agents. It answers the phone, replies to email, decides which table a booking goes to, keeps a profile on every guest, and runs campaigns off that profile to bring them back. The company is backed by Y Combinator, and was founded by Alan Mando and Felix Odeberg Glasenapp.

What it claims to do

The following is based on how Elyra describes the product publicly.

The Voice Agent answers calls 24/7, handles reservations, cancellations and questions, and supports multiple languages. Every conversation is logged. The escalation path is spelled out unusually carefully: if a situation needs a person, the call transfers; if nobody picks up, it returns to the AI rather than dying on a dead line; if the AI still cannot resolve it, it arranges a callback and passes the context to staff. The stated principle is that no path ends with the guest unhelped.

The Email Agent replies to incoming mail using the restaurant’s menus, booking rules and seating layout, aimed particularly at large-party and set-menu enquiries where a slow reply loses the booking. It tags and sorts messages into categories such as booking requests, general enquiries, supplier messages and press, and forwards to a human with context when needed.

Table Allocation places each booking against the whole floor plan, weighing party size, occasion, guest history and the restaurant’s own seating rules. It is pitched as revenue recovery: finding a table where a conventional booking system would have said no. A restaurant can lock the layout when it is happy with it, which stops the system reshuffling until it is unlocked.

Guest Intelligence is the layer underneath the rest. Preferences, allergies, celebrations and visit history are captured from calls, emails and bookings into a per-guest profile, and staff get a briefing before service on who is coming and what to watch for.

Campaigns uses those profiles for outbound messages: post-visit follow-ups, seasonal promotions, and win-back sequences aimed at guests who have not visited recently.

Analytics is the most interesting one, because it is explicitly not built for a human to read. Elyra describes it as a dashboard you do not have to watch: the system reads its own performance data, proposes operational changes such as adjusting a booking window or reallocating tables for a busy period, and either applies them immediately if auto-approve is switched on or files them in an approval queue with an explanation.

Why it is worth looking at

Start with the obvious question: why would a restaurant buy this instead of hiring someone?

A person can answer the phone. But a person answers one call at a time. On a festival night, a Friday evening, or any hour when everyone decides to call at once, the second caller waits and the third hangs up. Hiring another person raises the limit but does not remove it. And no restaurant is going to employ four people whose only job is picking up the phone and replying to email.

Software does not have that limit. It takes every call at the same time. That is the real thing being sold, and it is not something a restaurant can match by hiring.

Which is why it is worth looking at closely. Once the phone, the inbox, the booking record and the guest history all sit in one system, the restaurant is not using a tool. It is depending on one.

The sections that follow ask what that dependency costs. Whose models might be running the conversation. What happens when Elyra goes down. What the guest profile never hears. Whether the problem was worth solving in the first place, and whether the restaurant can tell if it was.

The guest, the restaurant and Elyra each have a stake in this. The last section maps what each one assumes and what breaks when the assumption fails.

Everything that follows is written from the outside, from public material and from reasoning about what the product would have to be doing in order to work as described. Where something is an assumption rather than an observation, it is marked as one.

Based on Elyra’s publicly visible team on LinkedIn and the lack of clear evidence that it develops its own core AI models, it seems possible that some of the technology used to understand and respond to conversations comes from third-party providers. This could include models used to understand speech, process conversations, and generate responses.

Now if the dependency exists, it introduces an important economic question:

A restaurant’s usage could vary significantly. A 20-second call does not cost the same to handle as a 10-minute conversation. Longer conversations may require more speech processing, AI processing, and response generation, which could increase what Elyra pays its providers. This makes the relationship between customer usage, Elyra’s pricing, and the costs it pays to third-party providers important.

Now there are several possibilities:

• Does Elyra charge based on call duration?
• Does it charge per call, regardless of duration?
• Does it use some combination of a fixed platform fee and variable usage charges?

My own guess is that Elyra uses a mix of both. There is likely a fixed platform fee that the restaurant pays every month no matter what, plus a usage charge on top that grows with how many calls or minutes the system handles. The usage charge is where Elyra earns its margin, since it can price each minute above what that minute costs to run. The fixed fee is the safety net: it guarantees Elyra a minimum amount of revenue from every restaurant, even in a slow month when the phone barely rings.

If that is right, the margin question above mostly goes away. Long calls cost Elyra more, but they also earn Elyra more. And the fixed fee means a quiet restaurant still covers its share of the platform, so Elyra is not losing money on customers who do not use it much.

The Inverse Pyramid Diagnostic

Now here is an interesting part we can see by applying one of my frameworks, the Inverse Pyramid Diagnostic (IPD).

The framework looks at what happens when an organization depends on foundational technologies that it does not control. If a foundational dependency becomes cheaper, more capable, more expensive, slower, or unavailable, how much of that change actually propagates into the organization above it?

In Elyra’s case, if this dependency exists, those providers sit below Elyra in the technology stack. This creates a potential fate-sharing relationship: improvements or disruptions at the foundation can propagate upward into Elyra’s product, economics and ultimately its customers.

Finance Propagation

Suppose one of the providers Elyra relies on increases its prices. For example, if the inference costs increase by 30%, what happens to Elyra?

There are several possibilities:

• Elyra absorbs the additional cost, reducing its gross margin.
• Elyra passes the additional cost to restaurants through higher pricing.
• Elyra optimizes its architecture to reduce the number of expensive model calls.
• Elyra changes providers or routes different tasks to different models trading off accuracy/quality to maintain the price.
• Elyra’s existing pricing structure already provides enough margin to absorb the increase.

Capability Propagation

Suppose one of the AI models Elyra relies on becomes significantly better at reasoning, speech recognition, instruction following, or conversational handling without a proportional increase in cost.

Elyra could potentially use the improvement to:

• handle more complex conversations,
• reduce hallucinations,
• improve reservation accuracy,
• support more complicated restaurant policies,
• increase automation,
• or expand what its agents can do.

And this becomes even more interesting when we introduce competition.

Competitive Propagation

Suppose Elyra and one of its competitors rely on the same or similar underlying model providers. Later that foundational model improves. Competitor A uses the improvement to increase accuracy, reduce latency, or lower its cost per interaction. But Elyra on the other hand sees little change.

This is where the propagation gap becomes diagnostically useful. For example:

That gives us the natural transition into the next part of the framework:

Absorption Audit

The purpose of the Absorption Audit is therefore not simply to ask whether Elyra benefits from improvements at the foundation. It asks:

Potential absorbers could include the model/context layer, proprietary data, prompts and instructions, retrieval, agent workflows, tool orchestration, integrations, evaluation systems, operational processes, or even the restaurant itself.

For example, if a model becomes 40% better at reasoning but Elyra’s reservation accuracy improves by only 5%, the missing 35% isn’t necessarily a failure of the model.

It suggests that something further up the stack may be limiting how much of that foundational improvement reaches the final product. That “something” becomes the subject of the Absorption Audit.

What “learning from every interaction” could mean

Elyra’s FAQ states that the system is trained on a restaurant’s menu, availability, policies, and service style, and that it learns from every interaction, becoming more accurate and personal over time.

If third-party foundation models are involved, Elyra would generally not be able to directly retrain those models or change their underlying weights after each interaction.

Though there are several mechanisms that could be responsible for the system becoming more accurate and personalized over time.

• Change prompts and instructions to guide how the AI understands and responds.
• Provide restaurant-specific context such as menus, policies, and operations.
• Retrieve relevant and up-to-date information from restaurant data.
• Use guest history to personalize future interactions.
• Use conversation history to maintain context.
• Use tool calls to verify information or perform actions.
• Apply business rules to control the AI’s behavior.
• Use evaluation and feedback to identify errors and improve the system.
• Route different requests to the model best suited for the task.

It could be the context supplied to the model, an updated guest profile, restaurant-specific knowledge, the decision layer surrounding the model, the agent’s workflow, or some combination of these components.

This distinction matters because it tells us where Elyra’s proprietary intelligence actually lives. For example, a guest interaction might produce a transcript. That transcript could then be classified, summarized, added to a guest profile, used to update restaurant specific context, fed into an evaluation pipeline, or used to modify some decision or routing layer. At this point, we can only make educated guesses about what mechanisms Elyra actually uses. But identifying this workflow is important because it tells us where improvement is being accumulated inside the system.

This brings us back to the earlier Propagation Gap. We can ask whether the limitation exists in its context, data, retrieval, orchestration, evaluation, workflow, or another layer surrounding the foundation model. This can be a good starting point for Absorption Audit.

Which will also tell us which layer of the system is its long term competitive asset.

Under this premise, Elyra may have the freedom to retrain or adapt its model as the restaurant data it operates on changes, such as menus, policies, availability, etc.

But how does Elyra keep the model relevant as that data changes over time?

Continuously adapting the model to those changes may itself create a significant economic and operational constraint.

This introduces the problem of data drift.

Two Types of Distribution Shift

There are different forms of distribution shift that can affect a deployed model.

In concept drift, the relationship between inputs and outputs itself changes over time. For example, “open until 10 PM” may have previously meant that customers could make reservations until 10 PM, but if the restaurant changes its policy to require reservations before 9 PM, the model has to learn this new relationship.

In covariate shift, the inputs change, but the relationship between the inputs and outputs stays the same. For example, customers may usually ask about dinner reservations, but during a festival, most customers may suddenly start asking about lunch reservations instead. The model is seeing different inputs, but what those inputs mean has not changed.

These two situations require different responses: Concept drift may require the model to learn a new relationship, while covariate shift may only require the system to adapt to the changing mix of inputs.

Therefore, if Elyra’s model is expected to become increasingly accurate over time, the important question is not simply whether new data is being generated.

The question is:

Possible approaches

Let’s look at some possible approaches when the incoming data keeps changing and the model needs to be retrained or adapted.

Incremental or online learning is one approach, where the model’s parameters are continuously updated as new data arrives rather than periodically retraining the entire model from scratch. This allows the models to adapt gradually as new observations become available.

Sliding window retraining is another approach, where Elyra periodically retrains the model using only a recent period of data. Instead of continuously accumulating the entire historical dataset, the system maintains a temporal window and periodically rebuilds the model using the most recent observations. This allows the model to adapt to recent changes while limiting the amount of data that needs to be processed.

Seasonal or contextual model routing takes a different approach. Rather than continuously modifying a single model to account for every change, Elyra could maintain multiple specialized models and use a lightweight router or deterministic rule to determine which model should handle a particular context. This could allow the system to preserve knowledge from different historical regimes while still adapting to the current environment.

The system could also use drift detection mechanisms to determine when adaptation is actually necessary. This creates an important distinction between detecting change and responding to change. For example, mechanisms such as ADWIN, Page-Hinkley, or PSI can be used to monitor changes in data distributions or model performance and trigger retraining only when there is sufficient evidence that the existing model is becoming stale.

The economic trade-off

Now the economic trade-off we have here is:

If Elyra retrains the model too often, it may spend more computing power, time, and engineering effort on updates that provide very little improvement. In other words, the cost of retraining may be higher than the value gained from having a slightly better model.

On the other hand, if Elyra waits too long before retraining, the model may become outdated. As menus, restaurant policies, customer behavior, and other conditions change, the model may gradually become less accurate. This can eventually affect the quality of the system’s responses and decisions.

Therefore, the goal is not to retrain the model as often as possible. The goal is to find the lowest cost needed to keep the model performing well.

But retraining can also create value. Imagine how many customers or how much business Elyra could miss simply because the model was not updated when the environment changed.

That is why two things need to be considered:

Risk Mitigation (defensive execution) and Revenue Expansion (offensive execution). Evaluating model retraining purely on loss avoidance misses the upside revenue generated by capturing new consumer demand or increasing conversion rate.

A decision model should balance both defense loss avoided and offense opportunity captured against operational execution costs:

$C_{\text{retrain}} < \underbrace{(\Delta \text{Degradation} \cdot V_{\text{risk}} \cdot N_{\text{existing}})}_{\text{Defensive}} + \underbrace{(\Delta \text{Lift} \cdot V_{\text{margin}} \cdot N_{\text{new}})}_{\text{Offensive}}$

• $C_{\text{retrain}}$ = Total compute, infrastructure, and engineering cost to update the model.
• $\Delta \text{Degradation}$ = Loss in accuracy/performance if not retrained.
• $\Delta \text{Lift}$ = Expected increase in prediction accuracy or recommendation relevance with updated data.
• $V_{\text{margin}}$ = Financial margin/profit generated per newly converted customer or transaction.
• $V_{\text{risk}}$ = Financial value at risk per existing customer or transaction.
• $N_{\text{new}}$ = Volume of potential new demand or expanding market segment.
• $N_{\text{existing}}$ = Volume of existing customers or transactions exposed to that risk.

Therefore, the decision to retrain should not be evaluated purely as a cost-avoidance problem. The economic value can come both from preventing degradation and from capturing additional business value.

Elyra’s services are positioned as a system that answers restaurant calls 24/7 so a restaurant will “never miss another booking.” In practice this means a restaurant can move a critical front of house function, handling of incoming reservation calls from its own staff to Elyra.

But at the same time, Section 17 of Elyra’s Terms & Conditions states that Elyra does not guarantee continuous availability, accepts no liability for losses arising from downtime, and is not obligated to provide maintenance.

The reinforcing loop

Picture a busy Friday evening. The restaurant is fully booked, and calls are coming in fast. If Elyra goes down right at this moment, the immediate problem seems small: the voice agent just stops answering calls.

But this small failure doesn’t stay small. It sets off a chain reaction, each problem makes the next one worse. This is called a reinforcing loop: one change pushes the next change in the same direction, and that change pushes the next one, and so on.

Now let’s look at this from a different angle.

In other words: the better Elyra gets, the more a restaurant leans on it and the more a restaurant leans on it, the worse it hurts when Elyra fails. A restaurant that barely trusts Elyra yet won’t feel much if it goes down, because they’re probably still using it as a backup, not the main way calls get answered. Their own staff or process can catch what falls through. A restaurant that has come to depend on it fully will feel it a lot, because that fallback no longer exists.

This is often exactly what happens: as trust grows, a restaurant becomes more willing to remove the human backup around Elyra. This cuts operating costs during normal conditions, but it also quietly removes the redundancy that would have caught a failure. This is why timing matters as much as trust. A failure on a slow afternoon may barely register as there’s enough slack to cover it. But a failure on a busy Friday night, the exact scenario we started with, hits a restaurant that has the least slack and the most to lose.

A possible fix: local reservation state

Elyra’s terms currently say: “We may modify or discontinue all or part of the Services without notice.” That “without notice” part is the problem. A restaurant shouldn’t be left in the dark when Elyra fails, there needs to be a way to detect the failure and hand things back to the restaurant.

One way to approach this is to keep a local, independent copy of reservation data at the restaurant, a copy that doesn’t depend on Elyra being online to be read. The system should periodically sync reservation information, so the restaurant always has a recent copy of the bookings that were successfully made before any failure. In practice, this means that while Elyra is running normally, it also regularly saves a copy of every booking somewhere the restaurant can reach on its own, for example a computer at the front desk, a tablet the host uses, or a simple local database at the restaurant. So if Elyra ever goes down, the restaurant isn’t starting from nothing.

That copy should include enough information to actually run the restaurant without Elyra for a while: reservation time (when the table is booked for), guest name (who it’s for), party size (how many people), contact information (how to reach the guest if needed), booking status (confirmed, cancelled, seated, etc.), and preferences such as dietary notes, seating preference, or special occasions.

With just this, staff can keep the floor running by hand, checking guests in, managing the walk-in queue, and knowing who to expect, even with Elyra completely offline.

The failure flow would then look like:

This works because of an important distinction between data continuity and service continuity. The restaurant cannot necessarily keep using Elyra’s AI agent after an outage. But it can keep the information generated before the outage, and use that to keep running.

Elyra’s ability to become increasingly personalized depends on a simple but important condition: it can only learn from what’s actually said to it. Anything that happens where Elyra isn’t present, it never finds out about. Consider a guest calling in for the first time. During the reservation call, Elyra may know their name, party size, and the reservation time.

But during dinner the guest tells the waiter: “I don’t eat seafood”. This information is extremely valuable during the guest’s next interaction with the restaurant. But the problem here is that Elyra was not there when it happened.

This creates an information boundary:

Restaurants already keep informal records of guest preferences, that’s not new. But the deeper issue here is psychological. Once a restaurant relies on Elyra, staff start to assume that guest information is being handled automatically, that it’s no longer something they need to actively think about. Elyra creates that mindset simply by working well.

The table-side gap breaks this assumption. Preferences shared at the table don’t enter Elyra on their own, someone has to notice, remember, and manually go add them. Once staff trust Elyra to handle guest information, they stop paying attention to it themselves. So small tasks, like manually updating a guest’s dietary note after hearing it at the table, are easy to forget, not because anyone skips it on purpose, but because the system trained them that way.

Negative guest profiles

A related question: does Elyra keep track of guests a restaurant would rather not serve again, for example, someone who has repeatedly caused problems for staff or other diners?

Before looking at what Elyra can do, a restaurant owner should first ask:

The obvious assumption is:

Restaurant is busy → calls go unanswered → potential customers cannot book → revenue is lost.

But this chain is not as simple as it looks. An unanswered call does not automatically equal a lost customer.

Say a restaurant gets 1,000 calls a month, and 200 go unanswered. Not all 200 were trying to book, some were asking about hours, parking, menu, dietary options, takeout/delivery, outdoor seating, etc. And even among those who did want a reservation, several things could still happen: they call back later, book through another channel, or walk in anyway. But here’s the part that matters most: even if every one of them genuinely wanted a table, the restaurant may not have had space to seat them regardless. So the number of missed calls was never the same as the number of lost customers.

So the question is not: How many calls are we missing?

It is:

This could mean lost reservations, and therefore lost revenue. But it could also mean something else entirely. A restaurant might find that many of these calls aren’t about booking at all, they’re simply asking:

“Do you have parking?” “What time do you close?” “Do you have vegetarian options?”

In that case, there’s no obvious revenue lost from the call itself. But there’s still a real cost, especially if there’s no dedicated person just to handle reservations. Every one of these calls pulls a staff member away from what they’d otherwise be doing, including taking the next reservation, or actually seating and serving the guests already at the restaurant. Seen through the lens of reservations specifically, a parking question isn’t harmless just because it isn’t a missed booking, it’s still competing for the same attention that reservations need.

Before adopting Elyra, a restaurant needs to know what its missed-call problem actually is: lost demand, poor conversion, staff interruption, inconsistent answers, or some mix of these. Each one costs the business differently, and a fix aimed at the wrong one won’t help. Adopting Elyra without knowing which one is real means solving a problem the restaurant may not actually have.

If Elyra solves the problem, how exactly does value get created?

Let’s assume the restaurant believes Elyra can solve their problem. The next question is: what happens after Elyra becomes part of the restaurant’s operations?

There are several possible outcomes

The first one could be recovering demand that would otherwise be lost, the most obvious one. A customer calls to make a reservation, but nobody answers, and without Elyra, that customer might simply abandon the restaurant altogether. With Elyra in place, the flow changes: the customer calls, the AI answers, availability is checked, and the reservation gets completed.

But the restaurant should be careful not to count every AI-handled reservation as new revenue, because the real question is whether this customer would have booked anyway, even without Elyra.

If the answer is yes, Elyra has simply made things more convenient rather than creating new demand. If the answer is no, it has recovered demand that would otherwise have been lost, which is where the real value lies.

So conceptually:

Potential incremental value = Demand recovered that would otherwise be lost − cost of operating the service

The hard part is figuring out how much of that demand was genuinely at risk of being lost in the first place.

Another possibility is reducing operational interruptions.

Now consider a different restaurant. Perhaps reservations are not the main problem. Instead, employees are constantly interrupted by phone calls while serving customers. Elyra changes this by handling routine calls itself, which means fewer interruptions and staff attention that stays with the guests actually in front of them.

The value here is not necessarily additional revenue per reservation. It is additional operational capacity. But that needs to be evaluated carefully. Suppose Elyra frees up two hours of staff time a day, that doesn’t automatically mean the restaurant has saved two hours of salary, since the staff are still there, still on the clock.

So the question becomes:

Maybe service gets faster. Maybe mistakes go down. Maybe staff simply have more attention to give each table.

The value chain is therefore:

Calls handled by AI → interruptions decrease → staff attention is released → some other part of the operation improves.

Whether that improvement is meaningful enough to justify the cost of the service is ultimately something the restaurant has to determine for itself.

There’s another mechanism worth calling out, that is improving conversion of demand that already exists and it may be particularly relevant to Elyra.

Imagine a customer asks for an 8 PM reservation, and a busy, tired staff member, juggling three other things at once, just says “no tables available” and moves on, not out of carelessness, but because checking every nearby time slot takes effort they don’t have left in that moment. The customer hangs up and leaves.

Elyra doesn’t get tired. It checks availability every single time, the same way, at 9 AM or 9 PM, and can say: “8 PM is unavailable, but we have 7 PM or 9:30 PM open.”

The chain becomes:

Customer request → preferred slot unavailable → alternative availability offered → customer accepts → unused capacity is filled.

That’s real value, created through better use of existing capacity, and it’s a different mechanism entirely from simply “answering calls that were being missed.” This one isn’t about missed calls at all, it’s about calls that were answered, but answered by someone too stretched thin to give the customer the full options they actually had.

Once a restaurant adopts Elyra, a fair question naturally follows: how does it actually know whether the thing is helping?

The obvious answer is data, track what’s happening, measure it, look at the results after a few months. But that answer has a problem hidden inside it. Any method that expects the restaurant to start recording every call, classifying what each customer wanted, maintaining spreadsheets, and manually tracking every lost opportunity is really just creating a second job on top of the first one. And this matters more than it might seem, because the restaurant adopted Elyra partly because it already has limited staff attention to spare. Asking it to now spend that same limited attention tracking whether Elyra is working defeats the entire point of adopting it.

So the real question isn’t how the restaurant collects data. It’s this:

Because Elyra sits directly inside the conversation with the customer, it’s already in a position to capture this information on its own, without anyone on staff lifting a finger. What was the customer actually trying to do? Did the reservation go through successfully? Was the requested time unavailable? Was an alternative offered instead, and did the customer accept it?

None of this needs a human to log it after the fact. Elyra already has to know all of this just to do its job in the moment, taking the call, checking availability, offering alternatives. The data isn’t a separate task bolted on top, it’s simply a record of the work Elyra was already doing anyway.

That’s really the whole test, and it’s worth taking seriously. If figuring out whether Elyra is worth it takes more staff effort than Elyra saves, something has already gone wrong, no numbers needed to prove it. This happens automatically, just from Elyra doing its job. Over time, a real picture forms on its own.

The end result isn’t just “is Elyra working, yes or no.” It’s a clearer answer to a more useful question: which specific part of the business is Elyra actually helping, and is that help worth what the restaurant is paying for it. That’s a question only the restaurant can answer.

The purpose of this chart is to identify the assumptions each actor is making, what those assumptions depend on, and what happens when they fail.

The important structure here is: Customer trusts the restaurant → Restaurant delegates interaction to Elyra → Elyra depends on the restaurant’s data and systems → Restaurant remains responsible for the final experience.

What the customer assumes

The customer assumes	What needs to support it	If it fails
My reservation actually exists	Elyra successfully creates the reservation in the restaurant’s system	Customer arrives and has no table
My requested date, time, and party size were recorded correctly	Accurate extraction and confirmation of critical details	Wrong reservation
The availability information is accurate	Elyra has access to current reservation and capacity data	Customer is promised a table that does not exist
My dietary preferences or special requests were recorded	Request is captured and passed into a workflow the restaurant can access	Restaurant is unaware of an important request
Information about the menu is accurate	Menu knowledge is current and reflects actual availability	Customer arrives expecting something unavailable
Information about opening hours, policies, or services is correct	Restaurant information remains updated	Customer makes decisions based on incorrect information
The restaurant will honour what I was told	Elyra only makes commitments the restaurant can actually fulfil	Customer feels misled by the restaurant
If I call again, the restaurant can understand what happened previously	Relevant interaction or reservation history is accessible	Customer has to repeat information
If something goes wrong, the restaurant can resolve it	Clear recovery and human intervention path	Customer is trapped in an unresolved failure

What the restaurant assumes

The restaurant assumes	What needs to support it	If it fails
Elyra will not overbook the restaurant	Accurate availability logic, synchronization, and conflict handling	Operational chaos and unhappy customers
Elyra will accurately record customer information	Reliable extraction, validation, and confirmation	Wrong guest details on file
Elyra will not lose important customer requests	Reliable transfer into the reservation or staff workflow	Staff do not know what the customer asked for
Elyra will not promise something we cannot deliver	Clear boundaries around what it is allowed to commit to	Restaurant is put in an awkward spot, either break the promise or scramble to honour it
Elyra has the latest information about our restaurant	Reliable process for updating menu, policies, hours, availability, and service information	Customers receive outdated information
Elyra will represent our service appropriately	Defined service behavior and escalation boundaries	Damage to the restaurant’s customer experience or brand
Reservation data will remain synchronized	Reliable integration and handling of failed or conflicting updates	Elyra and restaurant operate on different realities
We can intervene when something goes wrong	Human override and access to interactions	Errors continue without correction
We can understand what Elyra did on our behalf	Visibility into conversations, decisions, and actions	Restaurant cannot diagnose or resolve problems
Elyra will know when it should not act autonomously	Decision boundaries and escalation rules	AI makes decisions outside its authority

What Elyra assumes

Elyra assumes	What needs to support it	If it fails
Reservation availability is accurate	Accurate availability data and a working connection to the booking system	Elyra gives the wrong availability
A successful response means the reservation was actually made	Confirmation from the booking system	Elyra tells the customer the booking was made when it wasn’t
Restaurant information is accurate	Reliable and regularly updated information about hours, menu, services, and policies	Elyra gives customers incorrect information
Elyra only promises what the restaurant can provide	Clear rules about what Elyra can and cannot offer	Elyra promises something the restaurant cannot fulfil
Customer information is clear	Elyra can ask questions and confirm details when needed	Elyra misunderstands the customer or makes the wrong booking
Information reaches the restaurant staff	A reliable handoff into the staff’s normal workflow	Staff never see or act on the information