Agents that read the same Master Profile.

Hotels want agents that can answer, advise and, later, act: a concierge assistant, a revenue agent, a chatbot on the site, a third-party tool the team already likes. Each of those agents needs to know who the guest is. None of them should have to invent that person from one system’s fragment.

Casa Layer is not an agent product. It does not sell a chatbot, a voice agent or a messaging suite. The layer is the record those agents run on.

An agent pointed at the PMS inherits the PMS card. An agent pointed at the CRM inherits the CRM’s list. A new agent then wants its own integration, and IT is back to building a guest join per consumer. The agents will change every year. The person they need should not.

This page does not put logos of agents on a wall and call them customers. The directory lists the agent systems Casa Layer can serve, with an honest connection status for each. The job here is the interface, not a marketplace.

Agents query the Master Profile directly over an MCP server; everything else reads it over an open REST API. Claude, a revenue agent, a concierge assistant, or one you build yourself: every agent works from the same profile. There is no bespoke guest integration to build per agent.

Casa Layer builds the Master Profile and holds it. The record sits above your systems rather than inside one of them. We sell no applications on top of it, and nothing is sold on top that traps the record, so the profile is not shaped to favour a product we would rather you buy. Your own source systems stay the record throughout.

An agent that can only read can only advise, so write access is being built, granted per system by you. Every connection live today reads only. You decide what Casa Layer can do in each system, under credentials you issue and can revoke.