Why a mesh and not one agent
One model that predicts, decides and acts fails in two different ways at once, so the capabilities are split into nodes.
In practiceA wrong forecast is absorbed by a buffer. A wrong action reaches a guest, a shift roster, or an aircraft.
The tempting shape is one large model that predicts, decides and acts. It looks elegant on a slide.
It collapses in practice, because forecasting and acting have different failure modes, different feedback loops and different audit requirements. A wrong forecast is absorbed by a buffer. A wrong action reaches a guest, a shift roster, or an aircraft. Splitting them is not a technical decision dressed as a product one; it is a product decision that happens to need a specific architecture.
So each capability became a node with a strict boundary, and the boundaries are enforced by the protocol rather than by discipline.
One scene, four signals
Guest experience is not an agent of its own, because the same twenty minutes belong to four domains at once.
In practiceCheck-in: occupancy, a transit strike outside, a returning guest's last request, and who is on the desk.
Nothing in this system performs check-in today. The scene is here because it is the shortest way to show why the boundaries are drawn where they are.
Check-in looks like a process. It is schedulable, measurable, and obviously optimisable, which is exactly why it is the wrong thing to treat as one.
Four signals meet in that one moment. How full the house is tonight. What is happening outside, since a transit strike means every arrival lands in the same twenty minutes. Whether this guest has stayed before and what they had to ask for last time. And who is on the desk, how loaded they are, how far into the shift.
Model it as a process and you will optimise the metric a process offers: time to key. That number is measurable to the second, and it runs against the thing the property actually sells. A fast, cold arrival is an excellent process and a bad welcome.
This is why guest experience is not an agent of its own. It is a layer that crosses the others, because the same twenty minutes are simultaneously an occupancy fact, an external-context fact, a memory fact and a staffing fact. An agent that owned "guest experience" would have to own all four, and an agent that owns everything is not a bounded context.
It is also where the limit of any model of this kind shows. Time to key can be predicted from occupancy and staffing with reasonable confidence. Whether someone felt welcomed cannot. The gap between what is measurable and what matters is not a gap in the data; it is a property of the problem, and a system that forgets that will optimise confidently in the wrong direction.
The same holds harder at the other end. Departure carries the payment, and the end of an experience weighs more than its middle in what people remember, which makes check-out the moment most worth protecting and the one most often optimised for speed alone.
The five agents
Five agents, each with one domain, and a status a reader can check before reading anything else.
In practiceAetherix is built and instrumented, with a pilot partner in recruitment. Peritia is a named slot with no code.
| Agent | Status | Owns | Does not own |
|---|---|---|---|
| Aetherix | Built and instrumented · pilot partner in recruitment | F&B execution: covers forecast, staffing grid, waste risk, per-property memory | Orchestration, pricing, guest-facing anything |
| Tacet | Built: live data ingestion, MCP server v0 live | External signal: weather, street, events, ray-traced acoustic impact, yield rules | Deciding anything. It publishes rules for approval |
| Anima | Synthetic PoC, production DPIA-gated | Guest cognition: temporal memory of a guest relationship, confidence-weighted claims | Acting on what it knows. Production is DPIA-gated |
| Peritia | Design | House knowledge: what the people who work in a property know and never wrote down | Everything. It is a named slot in the contract, and no code |
| Orchestrator | Design | Supervisory routing and business rules across agents | Domain logic. It routes, it does not compute |
Tacet
Sensory
Orchestrator
Supervisory
Anima
Guest Cognition
Aetherix
F&B execution
this nodeHiveMemory
Anonymized peers
Manager
Tacet
Sensory
Orchestrator
Supervisory
Anima
Guest Cognition
Aetherix
F&B execution
this nodeHiveMemory
Anonymized peers, side input
Manager
Aetherix executes. It does not orchestrate.
| Node | Role | Status |
|---|---|---|
| Aetherix | F&B execution: forecast, staffing, memory, receipts | Live (staging) |
| Tacet | Sensory: weather, noise, open data → risk | Phase 3 |
| Orchestrator | Supervisory: MCP routing, business rules. Design, proto-stub in Phase 3, dedicated repo in Phase 4. | Phase 3, stub |
| Anima | Guest Cognition Layer | Synthetic PoC, hackathon prototype; production DPIA-gated |
Aetherix executes. It does not orchestrate.
Five rules that hold it together
The boundaries are enforced by the protocol and by the server, not by anyone remembering to respect them.
In practiceThe property identifier is never a tool argument, so a model has no way to name another property, let alone read it.
One bounded context per node
A node that owns two domains starts arbitrating between them privately, and the arbitration stops being reviewable. Splitting is what keeps a decision attributable to a component. Concretely: Tacet can say a strike will push arrivals into one window, and Aetherix can decide to move two covers of prep forward, but neither can quietly do both and present the result as a single judgement.
MCP is the only doorway
Nodes do not import each other. Every exchange is a tool call, which means every exchange is loggable, auditable and priceable. It also means a node can be replaced without its neighbours knowing. Tacet's rules reach Aetherix as a tool response with a timestamp and a source, not as a shared table.
Tenancy is resolved server-side, never passed as an argument
The property identifier is established at every layer by the server and is never a tool input. What a model cannot name, it cannot cross. This is the difference between a boundary and a hope: a prompt asking for last week's covers "for the other property" has no argument to fill.
Memory is local first, federated second, and never raw
Each property learns from its own history. Cross-property learning moves only as anonymised aggregates. A thirty-room independent gets the benefit of a network, such as how a rainy Tuesday in the same district moves breakfast covers, without its own covers, guests or prices leaving the building.
A fifth agent is an addition, not a redesign
The contract that governs exchanges between agents was designed to admit staff knowledge: what the people who work in a property know, which nothing captures today. That agent is named Peritia, the trade agent: a house's know-how, held by the house rather than by whoever is on shift. Not started, and no code. The pattern comes from my other project, Lore, the working proof of it in another industry.
What each node is allowed to learn
Autonomy is earned by feedback: a node that can be measured may adjust itself, one that cannot must be gated.
In practiceAetherix compares yesterday's forecast against the actual figure. The orchestrator has no outcome of its own to check.
The architecture is identical across nodes. What differs is whether reality answers back, and that decides how much autonomy each one earns.
| Node | Feedback available | Consequence |
|---|---|---|
| Aetherix | Manager replies, plus forecast compared against the actual figure | Can measure itself and gate on the result |
| Tacet | Rejections of its alerts, per coordinate | Learns local shielding without ground truth on the outcome |
| Anima | Guest signals, sparse and regulated | Learns slowly by design, and must forget on request |
| Orchestrator | None of its own | Judged only by whether the nodes it routed to were right |
A node with an outcome loop can be allowed to adjust itself. A node without one has to be gated before it ships, because nothing downstream will catch it.
Where the sector's twins stop
Hospitality digital twins model the building. None found models an operational decision before it is taken.
In practicePredictive maintenance and energy optimisation are mature. A staffing change simulated in advance is not.
Digital twins are mature and named elsewhere. Banks run market scenarios on them, Google models its data centres, Amazon its warehouses, and aerospace and automotive have used them for years to retire risk before touching hardware.
In hospitality they exist too, and they model the building: predictive maintenance, refurbishment simulated before the work starts, energy optimisation. Useful, and about walls.
Searching for one that simulates the impact of an operational decision before it is taken, a staffing change, an F&B order, a service adjustment, returns nothing. The sector models its assets and not its arbitrations.
This mesh is not marketed as a twin and does not simulate scenarios today. But cohort matching and the learning engine both point at that gap, and they arrived there from the operational side rather than from the vocabulary. Nothing was found, which is a finding, not a trophy.
The same architecture outside hospitality
The pattern holds in aviation maintenance, under a stricter regime and without a feedback loop.
In practiceLore's evaluation harness weighs close to a third of its codebase, because no outcome ever comes back to it.
Lore is this architecture in aviation maintenance, under a stricter regime. It captures oral expertise, retrieves it behind the governing procedure, and hands the decision to a licensed technician who signs the release.
What it does not have is the loop. Nothing tells it whether a captured observation was right, and the moment a technician escalates, the counterfactual disappears. That single absence is why its evaluation harness weighs close to a third of its codebase, where Aetherix can lean on measured outcomes instead.
Lore stays outside the mesh. Folding it in would make this one hospitality product more; leaving it out makes it an architecture that holds in a second industry under a stricter regime. The staff-knowledge agent inside the mesh is Peritia, not started, and the contract has room for it. It would be a different agent, not this one.
The mesh is not a hospitality pattern. It is what you build when a decision has to stay attributable to a component and to a person.
Where it stands
Five agents, five different degrees of existence, stated plainly and linked to the evidence.
In practiceAnima shipped as a hackathon prototype on synthetic data; production waits on a data-protection assessment.
- Aetherix is built and instrumented, on staging, with a pilot partner in recruitment.
- Tacet is Built. Live data ingestion pipeline, MCP server v0 on Fly.io, own case study, public repository.
- Anima is a Synthetic PoC. Shipped at a hackathon on synthetic data, production gated behind a data-protection assessment.
- Peritia is Design. Named in the contract, domain and contracts specified, no code, no page.
- Orchestrator is Design. A proto-stub exists. It does not yet deserve a page.
- Lore sits outside the mesh, as evidence the pattern holds elsewhere.
Public meta-repository: github.com/IvandeMurard/Hospitality-Multi-agent-Architecture.
One last pointer, since these two pieces answer different halves of one question. The field note Evaluating LLM agents: how would you know it had stopped working? explains how a system earns the right to ship. This page explains what the systems are. Read that one next if the statuses above raised the question of how they are checked.
Rose reads this note in full. She will not claim a node is further along than it is.