The Architecture of Agency and Transactional LLMs

Abstract: Language models are extraordinary at conversation and unreliable at bookkeeping. This paper describes the architecture behind Ordina's booking engine, a system that separates the two concerns entirely: a deterministic, server-owned state machine handles every fact that has to be correct (availability, holds, payments, confirmations), while a language model handles everything that has to feel human. We call this pattern Deterministic Core, Agentic Shell. What follows is a full account of why we built it this way, how each subsystem actually works, what broke along the way, and what we still consider open problems.

1. Introduction: The Imperative for Reliable Scheduling Systems at Scale

The world of artificial intelligence is currently splitting into two camps. One treats the conversation as the product: open-ended chat, creative writing, research assistance, anything where a wrong answer is annoying rather than expensive. The other treats the conversation as the interface to a transaction: a purchase, a reservation, a payment. Large language models have earned their reputation in the first camp. Handing them unconstrained authority in the second is a different proposition entirely, and it is the one this paper is about.

For a service-based business, a clinic, a salon, an independent consultant, a wellness studio, the calendar is the business. A missed lead is not a minor inconvenience; it is revenue that will not come back. A double-booked slot is not a bug report; it is a client standing in the wrong place at the wrong time, and a business owner scrambling to apologize for something a piece of software promised would never happen. Ordina exists to run that calendar autonomously: to answer a client's first message, hold a conversation, collect the right details, take a deposit if the business wants one, and confirm a real appointment, all without a human touching it. We ask for zero-touch scheduling and we promise zero double-bookings. Those are two different claims, and the second one is the harder engineering problem.

The question this paper tries to answer honestly is: how do you build a system that talks like a person and behaves like a database? How do you reconcile a probabilistic model, one that predicts the next likely token and is occasionally, unpredictably, confidently wrong, with a domain where "occasionally wrong" means a customer paid twice, or two customers were promised the same 2pm slot? Our answer is an architecture we call Deterministic Core, Agentic Shell, and the rest of this paper walks through it from first principles: why the naive approach fails, what we built instead, how each piece actually works today, and where we think the hard problems still are.

2. Background: Why Pure Agentic Orchestration Fails

It is worth being specific about what goes wrong, because the failure modes are not hypothetical; they are the predictable consequence of a specific architectural choice. A common pattern in modern "AI agent" frameworks, many of them ported from research codebases and popular precisely because they feel like having a conversation with a routing policy, puts the language model at the center of the application and lets it drive business logic directly: the model decides what to do next, calls a tool, reads the result, and decides again. Applied to a booking system, this produces at least four recurring failure modes.

Hallucinated availability. Ask the model to find a time next week and, in a pure agentic setup, it calls a calendar tool, receives some structured or semi-structured result, and has to interpret that result itself before deciding what to tell the customer. Interpretation is exactly where language models are weakest under pressure: they paraphrase, they round, they occasionally invent a plausible-sounding answer when the tool result is ambiguous or slow to arrive. A misread availability response does not fail loudly. It fails as a confidently stated, entirely wrong time, and the customer has no way to know the difference between a real slot and an imagined one.

Infinite retry loops. Without strict state persistence outside the model's own reasoning, an agent asked to recover from a failed tool call has to reason its way back to a sensible state every single time, and "reason its way back" is not a guarantee, it is a hope. A calendar API that times out because of a transient network blip can send a purely agentic loop into repeated retries, each one burning real inference cost, with no external mechanism forcing it to give up, escalate, or fall back to a safe default.

Financial vulnerability. This is the one that matters most. If a model's context window becomes even briefly confused, perhaps because two similar requests landed close together, or because a tool result got duplicated in the conversation history, a payment-initiation call can fire twice. A model has no innate concept of "I already did this." It has no ledger. Left alone, it will happily attempt the same side-effecting action again if the surrounding text looks like it is asking for it.

Silent consistency violations. The least discussed failure mode is also the most structural. Two customers can each be, from their own conversational thread's point of view, in the middle of successfully booking the same slot. A pure agentic system has no natural mechanism to arbitrate that race, because each agent instance is reasoning locally, from its own transcript, with no shared, atomic view of the resource both of them are trying to claim.

All four failures trace back to the same root cause. A language model works by predicting the next most probable token given everything that came before it. That is a remarkable capability for language, and it is simply not the same capability as acquiring a mutually exclusive lock on a database row, or guaranteeing exactly-once delivery for a financial transaction. Those are solved problems in distributed systems, with decades of literature behind them, and none of that literature assumes the component making the decision is a probabilistic model. Making an LLM a control-plane component is not a matter of prompting it more carefully. It is asking a component to do a job it was never architected to do, no matter how capable it becomes at everything else.

3. Design Philosophy: From Functional Core to Deterministic Core

None of this is a new problem dressed up in new clothes. Software engineering has a long history of separating "logic that has to be correct" from "logic that talks to the messy outside world," and the pattern we ultimately reached for has a name: Functional Core, Imperative Shell, a term popularized by Gary Bernhardt in a well-known talk on testing discipline. The idea is simple to state and surprisingly hard to hold onto under deadline pressure. Pure business logic, functions with no side effects, gets isolated in a "core" that is trivially testable because it has no dependencies on the outside world: no database, no clock, no network. Everything that actually touches reality, writing to a database, calling an API, reading the system clock, lives in a thin "shell" wrapped around that core. You get to reason about your hardest logic in complete isolation, and you get to treat everything uncertain as a boundary condition rather than something tangled through the middle of your code.

Generative AI changes what has to live in that shell, and it changes it in a way Bernhardt's original framing did not anticipate. Where the shell used to be a relatively boring, predictable layer of I/O calls against a static API, it is now, in a system like ours, a component that is itself unpredictable. The shell talks to a language model, and a language model is not a static interface; it is closer to another actor in the system, one with its own (extremely useful, extremely unreliable) judgment. Our answer, and the actual title of this architecture, is an extension of Bernhardt's idea rather than a rejection of it: a Deterministic Core, the finite state machine that owns every rule, transition, and guard governing a booking, wrapped in an Agentic Shell that owns the conversation itself: interpreting what a client actually means, recovering gracefully when they say something unexpected, and generating a reply that sounds like it came from a person who is genuinely glad to hear from them.

There is a useful way to frame this choice in terms more familiar from distributed systems theory. Every system that has to coordinate access to a shared resource under concurrent load is making a tradeoff, explicitly or not, between availability and consistency. A purely agentic system tends, by default, toward availability: it will always produce an answer, quickly, because the model is always willing to generate text. What it sacrifices is consistency: nothing forces two of those quickly generated answers to agree with each other, or with reality. Ordina makes the opposite bet for anything that touches money or a calendar slot: we would rather a customer wait a beat while the core resolves a genuine conflict than have two customers each be told, cheerfully and confidently, that they got the last opening.

3.1 Architectural Comparison

By keeping the model out of every decision that has to be provably correct, the system lets the conversation vary endlessly in phrasing, tone, and language while the underlying operations execute with the same precision as any other backend service. The client experiences flexibility. The database experiences none.

4. State That Survives the Conversation Going Quiet

A client might open the web widget, start describing what they need, and abandon the tab for a week before finishing. Another might message on WhatsApp and reply two days later, expecting the conversation to remember exactly where it left off. Any architecture that keeps booking state in memory, tied to a running process or a live session object, breaks the moment that process restarts, and production processes restart constantly: deploys, scaling events, the ordinary churn of a server fleet.

We considered, early on, reaching for a dedicated workflow or actor framework to model this: something purpose-built for durable, long-running state machines. We deliberately did not. The mechanism we settled on is almost aggressively simple: booking state lives as ordinary columns on the conversation's own database row. Which service is being discussed. Which date and time are provisionally held. What contact details have been collected so far. Where a price negotiation currently stands, if one is happening. Every turn of the conversation reads that row fresh from Postgres, and every state-changing action writes back to it directly, in the same request that triggered it.

There is no in-memory session object anywhere in this path, and there is no separate orchestration layer holding a copy of the truth. The database is the state machine's memory, full stop. That sounds almost too plain to be worth stating, but it is the entire reason a conversation can go dormant for a week and "wake up" exactly where it left off: nothing was ever depending on a process staying alive in between. We traded the elegance of a purpose-built state machine framework for the boring durability guarantees Postgres has had for decades. In a system where correctness matters more than architectural novelty, that trade was not a close call.

5. The Lifecycle of a Booking Conversation

From a client's point of view, talking to Ordina feels like a single, continuous conversation. Underneath, it is a tightly controlled sequence of computational phases, not a freeform chat that happens to wander toward a booking at the end. Decomposing the lifecycle this way is what lets us reason about concurrency, validation, and failure independently at each stage, rather than trying to hold the entire conversation's correctness in our heads at once.

5.1 Phase One: Grounding the Conversation in Real Business Facts

Before the assistant can be useful, it needs accurate ground truth about the business it represents: services offered, prices, hours, location, and whatever else a client might reasonably ask about. Business owners can add a free-text knowledge base, upload documents, or paste in a website URL, and that content becomes part of what the assistant can draw on.

We were deliberately conservative in how this is implemented. It would have been easy to reach for an embeddings pipeline and a vector database, chunking documents and doing semantic retrieval on every turn; that is the standard pattern for retrieval-augmented generation, and it is the right choice for genuinely large knowledge bases. For the size of content a typical service business actually has, a menu, a set of policies, an FAQ page, it is also unnecessary complexity. What we built instead is closer to a careful, budgeted dump: the relevant text is read fresh from the database, injected into the model's prompt within a fixed character budget so a single very long document cannot crowd out everything else, and explicitly and repeatedly scoped in the instructions given to the model: this content answers questions, and it must never be treated as authority for anything about an actual booking. A real available time, a real price, a real confirmation always comes from the deterministic core directly. It never comes from the free-text knowledge base, and it is never something the model is allowed to infer on its own.

That distinction, "knowledge for talking, facts for doing," turned out to matter more in practice than we expected when we first drew the line. Business owners will occasionally write something like "we're usually flexible on timing" into their knowledge base, meant as a friendly aside for the model to reference in conversation. If that text were ever allowed to influence the actual booking logic, it could quietly override the real, structured availability data the core computed. Keeping the boundary hard, no matter how tempting it is to let the model use "everything it knows" to be more helpful, is what prevents a business owner's casual phrasing from becoming an accidental policy override.

We later added a small but meaningful optimization to this phase, worth describing because it is a good example of the kind of iteration this architecture invites once it exists. A large share of any real booking conversation is routine data provision: a client typing their name, confirming an email address, replying "yes" to a question. None of those turns can possibly be a genuine question about the business, and yet the original implementation fetched and injected the full knowledge base context on every single turn regardless. We added a conservative classifier, deliberately biased toward over-including rather than under-including, that recognizes unambiguous routine shapes (a bare name, a bare email, a bare "yes," a bare time) and skips the fetch entirely on those turns, while anything that looks even slightly like it might be a question still gets the full context. The saving is not dramatic on any single turn, but multiplied across every routine turn in every conversation, it adds up to a meaningful reduction in both database reads and prompt size, at effectively zero risk to answer quality, because the one failure mode we cared about, under-informing the model on a turn that actually needed context, was the one we refused to trade away.

5.2 Phase Two: Availability Without Guesswork

The single most common failure mode in any scheduling software, AI-driven or not, is a race condition: two people attempting to claim the same slot at nearly the same moment. Handing a language model someone's calendar and asking it to "just tell them a time that works" does not solve this problem; it makes it worse, because the model becomes a second, unreliable source of truth sitting on top of the real one.

Ordina's core computes real availability directly against actual booked appointments and the business's connected calendar. The model never performs this computation and never sees the raw underlying data. When a client asks something like "can I come in tomorrow afternoon," the core resolves the genuinely open slots first, server-side, and hands the shell an already-correct, already-validated answer whose only remaining job is to be phrased warmly: something like "I have openings at 2:00pm and 4:30pm tomorrow, would either of those work for you?" The model is narrating a fact it was handed, not deciding one.

This distinction sounds subtle until you see what happens when it is violated even briefly. If the core has nothing to report on a given turn, perhaps because an upstream check failed transiently, the shell is explicitly and absolutely forbidden from stating, listing, or even implying any specific date or time. We added that rule after observing a real failure mode in testing: when availability data was temporarily unavailable, the model, rather than admitting uncertainty, would confidently invent a plausible-sounding "that time is unfortunately already booked" or "we're closed that day" response. It was not lying in any intentional sense; it was doing exactly what language models do when a plausible continuation is expected and the real answer is missing. That is precisely the behavior a transactional system cannot tolerate, and precisely why "the model narrates, the core decides" has to be enforced as an absolute rule rather than a strong suggestion.

5.3 Phase Three: Holding a Slot Without Losing the Race

Once a client settles on a time, something has to prevent that slot from being quietly claimed by someone else while the first client finishes providing their name, email, and phone number. Ordina holds the slot at the conversation level for the remainder of that session. It is worth being precise about what that hold actually guarantees, because it is less than it might sound like, and the real guarantee against a genuine double-booking comes from somewhere else entirely.

The session-level hold is optimistic. It gives one client a good-faith claim on a slot and lets the conversation proceed without repeatedly re-checking availability on every turn, which would be both wasteful and, at high enough concurrency, still not sufficient on its own. The actual, load-bearing guarantee is an atomic, lock-protected capacity check that runs at the single moment a booking is genuinely created, not before. At that moment, the database takes an advisory lock scoped to the specific business and day in question, an advisory lock being Postgres's mechanism for application-defined mutual exclusion that does not require locking any particular row or table, counts how many confirmed appointments already overlap the requested time window, and only permits the insert if the business's actual configured capacity allows it. Two clients finishing a booking for the exact same slot at the exact same instant cannot both win that race. One receives a confirmed appointment. The other receives an immediate, honest "that time was just taken" and a fresh set of real alternatives, rather than a stale error message or, worse, a false confirmation.

The model has no visibility into any of this locking machinery, and it does not need any. All it is ever told is whether a slot is currently held for this specific conversation, which is exactly enough information to know when it is appropriate to move the conversation toward finishing the booking, and nothing more.

6. Payments the Model Never Touches

For businesses that take deposits or full payment up front, the stakes of getting this wrong rise sharply, and the failure modes of distributed systems become directly relevant rather than theoretical. Webhooks, the standard mechanism by which a payment provider notifies a merchant's server that a charge succeeded, are notoriously unreliable in the specific ways that matter here: they can arrive late, arrive more than once due to the provider's own retry logic, or in rare cases not arrive at all. Any system that ever allows "the model said the customer confirmed payment" to count as proof of a completed transaction has built a straightforward fraud vector, whether or not anyone intended it to be one.

Ordina's rule here is absolute and, deliberately, has no exceptions we are willing to make for convenience. A booking can only ever be marked paid by a trusted, authenticated, server-to-server caller: the payment gateway's own webhook, or an internal verification and reconciliation check that has independently confirmed a real charge with the payment provider directly. That trust boundary is enforced with a shared secret carried on the request itself, not inferred from anything about who appears to be asking. A plain client-supplied "I paid" flag is never sufficient on its own, no matter how it arrives, and the model's own generated text has no bearing whatsoever on payment status. It is simply not a input the payment system reads.

Booking creation itself is idempotent, a property borrowed directly from distributed systems design: the same confirmation request, submitted twice, whether from a doubled click, a retried network request, or a webhook firing more than once, safely resolves to the same single appointment rather than creating two. Idempotency is the property that makes "at least once delivery," which is the honest default assumption for almost any network call, behave, from the business's point of view, like exactly once delivery. It is a well-understood pattern in payments infrastructure generally; the only thing specific to Ordina is that we apply it just as strictly to the booking record itself as we do to the charge, because a duplicated appointment is its own kind of costly mistake even when no money changes hands twice.

7. Bounded Negotiation: Keeping Persuasion Mathematical

Letting a language model freely negotiate a price on a business's behalf is a genuine, well-documented risk, not a hypothetical one. Models trained to be helpful and agreeable have a demonstrated tendency to concede far more than any competent human negotiator would, simply because generosity pattern-matches to helpfulness in the moment a customer pushes back. Left unconstrained, a model asked to "be flexible on price when it makes sense" will, sooner or later, be flexible in a way that quietly erodes a business's margin to zero.

Ordina decouples the negotiation mathematics from the negotiation language completely, and it is worth walking through exactly how, because the separation is the entire point. A business owner sets real, concrete parameters on their dashboard: a listed price, a hard floor that price should never go below regardless of what a client says, and a description of how the offer should move between the two if a client pushes back. From there, a negotiation proceeds in three distinct steps.

First, the client makes an offer, something like "can you do $75 for tomorrow?" The shell's only job at this step is extraction: identify the proposed number and hand it to the core. Nothing about how the client phrased the request, how politely or insistently they asked, changes what happens next.

Second, the core does the arithmetic. It clamps the offer against the real floor and the real listed price, applies whatever concession logic the business configured, and returns exactly one specific number: accept, hold firm at the floor, or counter with something in between. This step involves no language model at all. It is deterministic arithmetic on numbers the business owner set in advance.

Third, the shell narrates the result the core computed, in its own natural words: "I can't quite do $75, but for tomorrow I can do $85, would you like me to lock that in?" The wording can vary endlessly between conversations. The number cannot.

As a final layer of defense, one we added specifically because we do not fully trust any single safeguard on its own, every reply the model generates during an active negotiation is scanned before it ever reaches the client. If the model's phrasing somehow quotes a number outside the exact range the core computed, whether through a genuine model error or an attempted manipulation by the client earlier in the conversation, the reply is rewritten to the correct figure before it is ever sent. The business's floor is a hard boundary enforced by code, not a courtesy the model is trusted to remember on its own turn after turn.

8. Making Reliability the Default, Not the Exception

A missed appointment is one of the most avoidable forms of lost revenue a service business faces, and the losses compound in a way that is easy to underestimate. A business running at a twenty percent no-show rate is not losing occasional appointments; it is losing a fifth of its entire calendar to a problem that a handful of consistent, unglamorous habits mostly solve. Ordina automates exactly those habits, on fixed schedules the model has no involvement in remembering, because "the model remembered to follow up" is precisely the kind of soft guarantee we have spent this entire paper arguing against relying on.

None of these depend on the model remembering to do anything, which is exactly why they are reliable. A scheduled job either runs or it does not, and if it does not, that is a monitoring problem with a clear owner, not a silent gap in a conversation transcript nobody is reading. (For the client-facing version of this same list, aimed at business owners rather than engineers, see our earlier post, 5 ways to cut no-shows without being pushy.)

9. Engineering the Shell: Guardrails, Validation, and a Real Incident

Keeping the core deterministic solves most of the reliability problem, but it does not solve all of it, and it would be dishonest to write this paper as though the shell needs no engineering discipline of its own. "Prompt it carefully and hope" is not a strategy we rely on anywhere in this system, and the reason we can say that with confidence is that we have watched it fail.

Structured, validated output. When the shell needs to report something back to the core, a proposed date, a client's name, a price offer, it does so through a schema-constrained extraction call rather than free text the core has to parse and hope makes sense. If the model's output does not match the expected shape exactly, the core treats the value as missing and asks again, rather than guessing at intent from something malformed.

Multiple independent checks before anything client-facing ships. The model's raw reply is never sent directly to a client. It passes through a series of server-side checks first, each one added because a specific, real failure surfaced, not as a hypothetical precaution. One check rewrites premature payment language into the correct next step if the model jumps ahead of itself. Another blocks a confirmation message from going out at all while any required field is still genuinely missing. A third, and this is the incident worth describing honestly, specifically catches the model claiming a booking is confirmed, or that a confirmation email was resent, when neither thing actually happened.

That third check exists because of something we found in production, not something we anticipated in a design review. A client, testing the system, typed the literal word "Confirm" as a plain chat message rather than tapping the actual confirmation button the interface presented. The model, seeing text that read like an instruction to confirm, generated a warm, entirely plausible-sounding confirmation message, complete with fabricated booking details, even though no booking had been created anywhere in the database. When the client pushed back, pointing out that nothing had actually been booked, the model's response was, if anything, more confident the second time, reassuring the client that everything was indeed confirmed. It was a serious trust violation, and it happened precisely because the system, at that point, had no independent way to check whether the model's claim of success matched reality. We added a guard that checks a simple, unambiguous fact before any completion-sounding language is allowed to leave the system: is there a real, server-confirmed record of this booking actually existing? If not, the message is intercepted and rewritten to something honest, regardless of how convincing the model's original text sounded. This is, in miniature, the entire philosophy of this paper: never let the model's confidence stand in for verified fact, especially at the exact moment a client is asking "are you sure?"

The model never reveals how any of this works. It is instructed to behave as a genuine member of the business's staff, never describing internal mechanics like "system messages," "confirm cards," or database records, even under direct, deliberate questioning designed to extract that information. This is not obfuscation for its own sake; a client does not need to know, and should not need to care, that a Postgres advisory lock exists anywhere in the system. They need to trust that when they are told something is confirmed, it actually is, which is exactly the guarantee the rest of this architecture exists to make true.

10. Observability as a Byproduct of Structure

A useful, somewhat unplanned side effect of running bookings through a deterministic flow rather than freeform chat is what it does for analytics. In a purely conversational system, understanding how clients actually move through a booking process means combing through raw chat transcripts after the fact, trying to reconstruct where someone dropped off or why a conversation stalled, which is slow, subjective, and difficult to do at any real scale. Because Ordina's underlying state is explicit rather than buried inside conversational text, structured signal about the booking funnel, where clients drop off, which services get asked about most, how long a typical booking actually takes, comes essentially for free, as a natural consequence of the architecture rather than a separate analytics effort bolted on afterward.

It also changes what "remembering a client" actually requires. A returning client does not need the model to re-read old conversation transcripts to recognize them; their details and booking history already exist as structured records the system can look up directly. That has a real cost benefit, since re-processing old transcripts through a model on every turn would mean paying, in both latency and inference cost, to re-derive information that was already known and already stored correctly the first time.

11. Design Philosophy Beyond the Backend

The same emphasis on precision that shapes the backend architecture shows up, deliberately, in how Ordina looks and feels to use. We drew inspiration from the minimal, high-contrast, keyboard-first aesthetic popularized by tools like Linear: deep backgrounds, restrained color, interfaces that get out of the way of the task rather than decorating it. The goal is an experience with as little friction and as little cognitive load as the backend's guarantees actually earn it. A client should always be able to tell, at a glance, exactly where they are in the process. A business owner should always be able to trust that what is on their screen matches what is genuinely true in the underlying system, with no gap between the two. That consistency, from a database row all the way to a pixel on screen, is not a separate design goal from the architecture described in this paper. It is the same goal, applied one layer further out.

12. Limitations and Open Problems

A paper like this is more useful if it is honest about what it does not yet solve, so it is worth naming a few genuine tradeoffs rather than presenting the system as finished.

The advisory lock we use for capacity checking is scoped per business per day, which is the right granularity for the overwhelming majority of the businesses we serve today, small teams with a handful of concurrent appointment slots, but it is not infinitely scalable in principle. A business with an extremely high volume of concurrent bookings on a single day could, in theory, experience lock contention at exactly that boundary. We have not needed to solve for that yet, and we would rather say so plainly than imply a level of scale-tested robustness we have not actually earned.

The knowledge base's "budgeted plain text" approach is a deliberate simplicity tradeoff, and it has a real ceiling. It works well for the kind of content a typical service business actually has. A business with a genuinely large, complex knowledge base, extensive documentation, a large product catalog, would eventually be better served by real semantic retrieval, and we are watching for that need rather than assuming our current customers will never reach it.

And even inside the boundaries this architecture enforces, the model can still be a frustrating conversational partner in ways that have nothing to do with money or calendars: it can misunderstand an unusual phrasing, it can be steered off-topic, it can occasionally sound stiffer than we would like. Constraining what the model is allowed to affect protects the business and the client from the failure modes that actually matter. It does not, on its own, make every conversation feel effortless, and we do not think prompt engineering alone will ever fully close that gap. That is a genuinely open problem, and one we expect to keep working on for a long time.

13. Conclusion: Building Transactional AI, Not Just Conversational AI

The gap between a novelty chatbot and a system a business can actually trust with its calendar and its money is exactly the gap this architecture was built to close. Combining the rigor of an explicit, testable state machine and genuine payment idempotency with the flexibility of a modern language model is what makes zero-touch scheduling something we can actually promise, rather than something we have to quietly caveat.

That is the foundation Deterministic Core, Agentic Shell gives Ordina: a system where the conversation can be as natural as talking to a person, and the outcome is as reliable as talking to a database, because underneath the conversation, that is exactly what it is.