An AI chatbot that only answers questions is worth less than a slow human. We build assistants that finish the task inside the conversation itself: booking the table, logging the complaint, updating the record, instead of just describing what should happen next.
RestroAgent was built for The Broad Fork Bistro, a single-location, full-service restaurant that ran reservations off a phone line, complaints off a comment card, and menu questions off whichever server answered the host stand. We put one system behind all three: a reservation agent, a complaint agent and a support agent, sharing one database and one memory of the conversation.

Reservations, complaints and menu questions were handled by whoever was free, through three disconnected channels. A complaint about a Tuesday dinner had no way of reaching whoever built Wednesday’s seating chart, and a generic chatbot could answer a question about hours but couldn’t touch the actual booking.
Three specialized agents sit behind one chat window, each wired to the restaurant’s own database and delegating to each other mid-conversation. A guest can have a table rebooked and a complaint logged in the same thread, because the agents handling both are working on the same record.

A chatbot that can only answer FAQs still leaves the real work to staff. RestroAgent’s agents are built to finish it themselves. The reservation agent reads and writes straight to the live table map. The complaint agent classifies what comes in (a cold entree is not a billing dispute) and resolves what it can, escalating the rest. The support agent answers from a knowledge base the other two also draw from. What makes it one assistant rather than three bots is the hand-off: a guest can ask about a dietary restriction, then move their 7pm to 7:30, without repeating themselves.
Every message enters through one chat window. An orchestrator reads the intent and hands the conversation to the agent built for it, and all three agents read from and write to the same restaurant database, so nothing has to be reconciled later.
Reads intent on every incoming message and hands the conversation to the agent built for it.
Books, cancels, and checks availability directly against the live table map. No separate booking log to reconcile.
Classifies severity, resolves what's routine, and flags anything that needs a manager before it reaches one.
Answers from the same knowledge base as the other two agents, so hours, policy, and menu answers stay consistent.
An agent can hand a thread to another agent without the guest starting over or repeating what they already said.
Reservation changes land in the same table map the host stand uses, not a queue that syncs later.
Routine issues get resolved on the spot; anything serious reaches a manager instead of sitting in a log nobody checks.
Hours, policy, and menu details come from a single source, so answers don't drift depending on which agent responds.
Each agent has a narrow job description rather than one model trying to be a reservationist, a complaints desk, and a concierge at once.
Each delegation between agents is logged, so if a guest's reservation and complaint end up tangled, there's a record of which agent touched what, in order.
The aim was that a guest could get a task finished in a single conversation. Here is how the shipped assistant differs from what came before it.

Sat with host-stand staff to see where reservations, complaints, and questions actually collided, not where we assumed they would.
Defined what a reservation agent, a complaint agent, and a support agent each owned, and where one hands off to another
Connected the reservation agent directly to the restaurant's own database instead of a separate booking layer.
Set the thresholds that decide what the complaint agent resolves itself versus what reaches a manager.
Tested against actual Friday-night volume, not a scripted demo, before handing it to staff.
Host-stand staff learned exactly what a ping on their phone meant, and what didn’t need their attention at all.
