Agent work, with a clear path to review.

The model supplies intelligence. Harness connects the mission, context, working memory, workflow skills, action guards and tools. Existing access rules stay in place.

Guards are not instructions the model is hoped to follow. Each one is a reviewed registry entry compiled into the agent runtime's own pre-action checks for the tools it covers, and the same registry is compiled for more than one agent runtime. A guard that cannot reach a verdict denies the action.

This example illustrates a scoped repository change; no work or tests run here. Working memory supports the current task. Odin Next is separate organizational knowledge. Preparing the illustrative packet neither deploys a change nor grants release permission.

Model identity, deployment location and routing policy are separate choices. The EU example pairs Mistral with a configured EU-jurisdiction route through Odin AI Gateway. An eligible EU-broker route also requires the applicable provider agreement and DPA attestation; choosing Mistral alone does not set processing location.

In Gateway, a residency setting is configured on the access key. Once Gateway has validated that key configuration, the setting applies to the routed model requests made with it, including requests that name a specific model. A request can tighten that setting but never loosen it. If no eligible route can serve the request, Gateway refuses it instead of sending it elsewhere. Unless the key records a DPA attestation for the EU broker, an EU-jurisdiction key narrows to operator-controlled EU routes only. The policy follows the route, whichever model family it serves.

Model names identify illustrative families, not a promise of availability or a provider endorsement. This local preview does not switch a live model, configure a provider, or send a request.