Juno works with the cloud language model your organisation already holds a contract for: Gemini, Claude, OpenAI, Llama or another.
Five steps; the link serves once a live handshake has confirmed all three parts of it.
A model link is a small record your IT architect creates. It names the provider and the exact model, and it points at the key: the secret stays in the key store your security team already runs, and Juno reads it at the moment of the call.
The boundary rule sits in the same record. It states which content may reach the external model, and it is read on every call.
The handshake is a live call made before the link serves anything. Juno asks which model answered, resolves the key, sends a test payload and reads what comes back, and the link publishes when the three agree.
From then on the link is a governed object like any other, with an append-only version history, so a decision made in March points at the link that was in force in March.
Design time uses the model you chose; run time uses the model that sits inside your estate.
Juno separates the two on purpose. A planner states intent in plain language, the cloud model drafts a policy from a fixed action vocabulary, and the person reviews it, simulates it and publishes it to the rule store as a planning table.
From that point the Lima Rules Engine executes the published rule. The rules engine decides; the model explains, discovers candidate rules in past planner behaviour and detects drift.
The model inside your estate serves that run time. It is a small language model that ships with Juno, runs on your own hardware and is used as it ships, so a run puts a recommendation into words inside your own walls.
Gartner, 20 October 2025, expects more than half of enterprise generative AI models to be domain-specific by 2028. A supply chain model that ships with a supply chain ontology is what that prediction describes.
One record holds the provider, the key reference, the boundary, the region, the purpose and the budget.
| Field | What it holds | In the showcase estate | Who sets it |
|---|---|---|---|
| Provider | The organisation that serves the model. | The cloud provider named in the contract | IT architect |
| Model | The exact model and the version of it. | The model family and version in that contract | IT architect |
| Key reference | A path to the secret in your own key store. | Read at the moment of the call | Security team |
| Boundary rule | What may cross, and what stays inside the estate. | Schema and vocabulary cross; rows stay | Security team |
| Region | Where the model serves from. | The region your data policy allows | IT architect |
| Purpose | The kinds of call this link answers. | Design time and rule discovery | Agent owner |
| Budget | The monthly figure the token manager reads. | $6,000 for the purchasing team | Team owner |
Showcase estate. The link is versioned, so a decision points at the link that was in force on the day.
The question is which content reaches the provider. The boundary rule answers it in the record itself: schema names, your vocabulary and a planner’s intent may cross at design time, and order rows, prices, names and quantities stay inside the estate.
Six checks; the link starts serving when the model, the key and the boundary all agree.
The handshake runs when a link is created, when a field in it changes and on the schedule your team sets. Each result joins the audit trail, so a reviewer reads when the boundary was last proved against the model in use. A held link keeps the estate steady: design-time work waits for the owner, and run time carries on, because the model inside your estate serves those calls.
Changing a model is a change to one record, and your rules stay where they are.
Analysts describe this as vendor neutrality, and they ask for it because model prices, context limits and regional availability all move. Juno keeps the model behind a link, so a change is a configuration decision your IT architect makes in an afternoon, and every running agent keeps its behaviour.
Showcase estate.
S. Iyer created the model link on the Monday morning: the provider from the existing contract, the model named in it, a path to the key in the company key store and the boundary rule set to schema and vocabulary. The handshake ran at 09:05, confirmed the model, the key and the marker in the test payload, and published the link.
At 11:20 L. Tan stated the cancellation intent, and the cloud model read it and drafted the planning table. Eight weeks later the purchasing team moved to a second provider for design time. The published PO cancellation policy stayed at version 4, D. Okafor’s queue looked the same on the Monday morning, and the audit trail for September still names the first link.
Twelve layers of security, single sign-on, role-based access, row and column rules, and the permissions an agent carries of its own.
The difference is who owns the choice of model.
Many products are built around a single model chosen by the vendor. The choice arrives with the product, the price of the model arrives with the invoice, and a change of model waits for a release.
Juno holds the model behind a link your team owns. The provider, the model, the key, the boundary and the budget are all fields in a record, and the rule store keeps the behaviour of your agents steady while that record changes.
The families Juno supports today are Gemini, Claude, OpenAI and Llama, and others are added on request. The choice follows the contract your organisation already holds.
Order rows, prices, names and quantities stay inside your estate. Table and column names, your vocabulary and the intent a planner writes may cross at design time, under the boundary rule in the link.
Your own hardware, inside the Juno deployment. It ships with the product and is used as it ships, which is why run time carries zero token cost.
In your own key store. The link holds a path to it, and Juno reads the secret at the moment of a call, so the key stays under your security team’s control.
Each one builds on the one before it.
Reads your rows in place.
Connect and move ↗One record per real thing.
Master and govern ↗Apps for every decision.
Operate and decide ↗Asks and acts, at your level.
Ask and act ↗Bring two systems and one decision your planners make every week. In the first week we register the data, confirm the mapping with your team, answer your questions in ChatLima and run the first agent at the level you choose.
