A controlled gateway between Orbit and the systems each client uses.
Orbit never talks to a client's practice-management system directly. Every action starts as a scoped request sent to Blackstar's backend gateway, carrying a client token, its source, a request ID, the intent being requested, its arguments, and a reference to a published execution blueprint. The gateway is the only path between a conversation and a client's connected systems. Nothing reaches a practice's software without first passing through it.
Tool Gateway
A phone conversation is unstructured. A client's practice-management system is not. Somewhere between the two, a caller's request has to become something a computer system can safely execute, and that translation cannot happen inside the model itself.
That's what the tool gateway does. When Orbit decides an action is needed, such as checking whether a Tuesday afternoon slot is open, it doesn't send that thought straight to the practice's software. It sends a structured request to Blackstar's backend first. That request identifies which client it's for, where it originated, and exactly what operation is being asked for, with the specific arguments that operation needs. Nothing about the underlying system, its login, or its internal structure is exposed to the conversation. The model requests an outcome; the gateway is what turns that request into something a system of record can act on, if it's allowed to.
Step by step.
Before anything reaches a client's system, a request moves through a fixed sequence. First, the conversation produces an intent: a named, approved operation like "check availability" or "create appointment," never a freeform instruction. Second, that intent is packaged into a request envelope containing the client token, the request's source, a unique request ID, and the arguments the operation needs. Third, the gateway receives that envelope and resolves who it's for and what they're allowed to do, checking it against a published execution blueprint for that exact operation.
Fourth, and only if every check passes, the gateway forwards a constrained call to the client's connected system. Fifth, whatever comes back gets validated again before it's treated as a usable result. Every step happens the same way, in the same order, for every request. There's no shortcut where a request skips the gateway or reaches a client system on a different path.
What Orbit will not do.
Orbit does not send arbitrary commands to a client's system, and it cannot request an operation that hasn't been published as a blueprint for that client.
It cannot supply arguments outside what a blueprint's schema allows, and it does not maintain its own direct credentials to a practice's software.
It does not skip the gateway for speed, and it does not retry a blocked request under different framing to get the same result approved.
If an operation isn't published for a given client, the request is rejected. It does not get executed anyway because the intent seemed reasonable.
A conversational system that could reach a practice's live software directly, with nothing in between, would mean a malformed request or a gap in judgment had nothing standing between it and a real patient record or a real appointment book. The gateway exists so every request is inspected the same way regardless of how the conversation that produced it went. It's the difference between a system that can act on a practice's data and one designed, from the ground up, to only ever act inside boundaries someone else set on purpose.
See the gateway in front of a live system.
Review how this request path plays out against the Open Dental integration.