Your PMS keeps the records. Agentric OS runs the work. It watches what happens to bookings, units and tasks, decides what should happen next, and acts through the PMS you already use — with an approval step wherever you want one.
Not a PMS with an AI chat bolted on. It sees every job through to the end: it notices a problem, decides what to do, does it in your PMS and checks that it was done.
Seaview Apartment 4 · arrival tomorrow
Unit marked out of order in the PMS
Opened · one per unit, no duplicates
Open maintenance task → Auto
Urgent task created in the PMS
Task read back · waiting for it to close
Not “ticket created”
“Unit back in service — or a person knows why not”
Agentric OS › Configurations › Vacation rental
A PMS records what happened. Somebody still has to make the next thing happen.
The PMS stores the booking and the task. It doesn’t chase the plumber, notice the task is overdue, or tell anyone the arrival is at risk.
A broken boiler becomes a thread in a messenger. Whether it gets fixed before check-in depends on who remembers to follow up.
Every new property adds arrivals, cleanings, changes and questions. Headcount is the only thing that scales with them.
A chatbot on top of the PMS can answer a question. Letting it change a reservation with no rules and no trace is a risk nobody signs off on.
Four steps, the same for every situation — from a broken unit to a guest asking to leave late.
An Agentrika connector follows your PMS and reports what changed. An event is a hint, not the truth: before anything is decided, the current state is read from the PMS itself.
What just changed
An event that matters opens a case and Agentric OS runs it to the end: steps, waits, deadlines and escalation are part of the case, not something a person has to keep in their head.
Case timeline · Broken unit
Reading is free. Anything that changes something in your PMS is checked against rules you set, and gets one of three answers.
Policy · vacation rental
The command goes to your PMS through the connector. Then Agentric OS reads the result back. “Sent” is not the same as “done”.
Command log
A few situations to show the idea — not a fixed list. Each one is a set of steps and rules that you can adjust to how your operation works.
Opens an urgent maintenance task and waits for it to close. Resolved when the work is done; escalated when it is closed as not completed, not closed within a day, or could not be opened.
A problem reported by a guest or a cleaner becomes a task with an assignee and a cost estimate, tracked until someone closes it.
Checks what the next arrival and the cleaning plan allow, then moves the checkout time — with approval wherever your policy asks for it.
The same logic from the other side: previous departure, cleaning status, then a new check-in time that the PMS and the team both know about.
An agent answers from the reservation and the property facts. Anything that would change a booking becomes a command — and goes through policy like every other.
Any situation your team handles by hand can become a case: describe the steps and the rules, and Agentric OS runs it. Nothing in the platform is rebuilt — you install a new version of the configuration.
A badly built process cannot go around the limits. The controls sit below the cases, not inside them.
An agent can read and propose. Only one component can send a change to the PMS, and it only sends what policy allowed.
Every change it would make is written down, but nothing is sent. Compare with what your team did, then switch it to live.
The approver sees the exact change. What is sent afterwards is exactly what was approved, not a new guess a minute later.
Every change is sent only once. A repeated signal or a connection hiccup never produces a second task or a second change.
After acting, the result is read back from the PMS. A change with no visible effect is flagged, never silently counted as done.
A case that cannot move forward is marked stuck and handed to a person with its full history — and can be retried from where it stopped.
Agentric PMS is not a second PMS. There is no parallel bookings database to reconcile and no new screen your team has to live in.
Agentric OS
decides, acts and checks the result
↑ what changed · what to do ↓
PMS connector
the only part that holds your PMS password
↕
Your PMS
reservations · units · tasks · channels
Agentric PMS runs wherever Agentric OS runs — next to your PMS, on your terms.
Container images for the platform and for each connector. Your data centre or your cloud account, with the AI model you choose.
PMS credentials live only with the connector. The platform that runs cases and agents never holds them.
Each operator account is isolated, with its own versions of cases and policies. Roll a change out to one before all.
No. Reservations, guests, units and tasks stay in your PMS. Agentric PMS works on top of it: it sees what changed, decides what should happen next and does it in the PMS. There is no second bookings database to keep in sync.
Only what your rules mark as automatic. Every change is checked against your rules first and is either done, sent for approval or refused. If no rule fits, a person decides. AI agents cannot change anything in the PMS on their own: they suggest, and only what your rules allow is carried out.
In shadow mode every situation is handled in full and every change Agentric OS would make is written down, but nothing is sent to the PMS. You compare what it would have done with what your team actually did, then switch it on when you trust it.
Through an Agentrika connector, the part that links Agentric OS to your PMS. Adding or updating a connector does not require changing anything else, and the password to your PMS is stored only in the connector.
Resource Utilization is about price: it keeps rates aligned with demand. Agentric PMS is about operations: maintenance, check-in and check-out changes, cleaning hand-offs and guest requests. Resource Utilization is an Agentrika automation, Agentric PMS is an Agentric OS configuration, and they can work side by side on the same PMS.
Tell us which PMS you run and which situations eat your team’s day — we’ll map the first case together.
Or reach us at info@aglium.com • Telegram
