Bring Your Own Model Just Became a Real Setting, Not Just a Framework

The framework piece shipped months ago. This is the architecture that makes it real.

We published the decision framework for Bring Your Own Model earlier this year. The argument was straightforward: organizations with existing enterprise agreements, compliance requirements, or specific model preferences should not have to route every AI workload through a platform provider's default account just because that is easier for the platform.

The framework mattered. But a framework is not infrastructure.

Atlas now has real multi-provider routing. An organization can connect its own model provider account and route AI workloads through it instead of defaulting to Joyful's platform models. The system includes adapters for four provider types: a fixed-endpoint provider like Anthropic, one like OpenAI, one like Gemini, and a customer's own Azure AI Foundry endpoint for organizations running their own enterprise model deployment.

This is shipped architecture. Not a roadmap slide. Not a beta you have to beg for access to. The infrastructure is live.

Rolling out carefully does not mean rolling out slowly. It means not breaking spend accounting.

The capability is being rolled out progressively, org by org, behind a feature flag. That is not caution for caution's sake. It is operational discipline.

When you route a workload to a customer's own provider account, you are no longer just tracking tokens inside your own billing system. You are handling their credentials, attributing spend correctly across agents and workflows, maintaining audit trails that span multiple provider APIs, and making sure cost visibility does not disappear the moment a workload leaves your infrastructure.

Getting multi-provider routing, spend accounting, and credential handling right matters more than getting it out fast. We have seen what happens when platforms rush identity integration or cost attribution and then spend six months cleaning up the mess in production. That is not the standard.

Provider portability and identity integration follow the same principle: use what the business already trusts.

The same logic that applies to model providers applies to identity. Atlas now supports signing in with an organization's existing Microsoft identity. If a company already manages user access through Microsoft, it does not have to hand Atlas a brand-new, separate password to secure.

That may sound like table stakes. It is. But it is also the difference between a system that plugs into the tools and providers a business already trusts and one that demands the business standardize on the platform's defaults because integration was hard.

This is what provider-portable intelligence and governed access mean in practice. Not as phrases in a product brief. As architecture decisions that respect how enterprises actually operate.

• Route AI workloads to your own Anthropic, OpenAI, Gemini, or Azure AI Foundry account
• Use your existing Microsoft identity for user access and permissions
• Maintain spend attribution and audit trails even when workloads route to external providers
• Keep governance, observability, and cost visibility regardless of which model executes the work

The harness is the system that makes intelligence operational. That includes the routing layer.

Access to a model is not an AI strategy. The system around the model is the strategy. That system includes how you route workloads, how you track what they cost, how you govern what they can do, and how you connect them to the business context they need to be useful.

Atlas is a Business AI Harness. The harness connects models to business data, approved knowledge, tools, workflows, governance, observability, and human judgment. Multi-provider routing is part of that harness. So is identity integration. So is the spend attribution that lets you see what a workload actually cost and whether it delivered value.

The architecture is live. Broad self-serve availability is still rolling out. If your organization has specific model provider requirements or compliance constraints that make this capability material, that is a conversation worth having now rather than waiting for general availability.

We built the framework. Then we built the infrastructure. Now we are rolling it out the way you would want your own team to roll out credential handling and cost accounting: deliberately, with feature flags, org by org, until it works the way it should.