One AI Platform, Two Infrastructure Paths

Building XToka AI Fabric gave us control over the infrastructure underneath our AI applications. It also raised a product question: if we have our own sovereign AI infrastructure, should customers have to choose between AI Fabric and Microsoft Foundry?

Our answer was no. We designed our enterprise AI platform so the execution environment can change while the product remains familiar. An organisation can work through Microsoft Foundry (formerly Azure AI Foundry), through XToka AI Fabric, or through a hybrid architecture using both.

For governments and corporations, that flexibility matters. Different teams handle different information, and their requirements do not always fit a single deployment choice. The application should support those differences while giving people a consistent way to work.

Separating the product from its infrastructure

Employees using an AI platform want to find information, analyse documents, compare data, prepare briefs and complete approved workflows. The location of the compute is an architectural concern that should be handled through deliberate deployment decisions.

We separate these responsibilities into two layers. The product layer handles organisational knowledge, user access, documents, integrations, retrieval, workflows, governance and business logic. Underneath it, the execution layer provides the models and infrastructure used for AI tasks.

This separation lets us adapt the execution environment to an organisation's requirements without rebuilding the entire application. The knowledge connections, permissions and workflows remain part of the product architecture as the infrastructure underneath evolves.

It also gives infrastructure discussions a clearer starting point. We can consider the needs of a workload alongside the experience employees require, rather than allowing one deployment decision to determine every product capability.

Why Microsoft Foundry remains part of the strategy

XToka has extensive experience building within the Microsoft Azure ecosystem. For many organisations, that environment is already part of daily operations. Their identity systems, databases, business applications and infrastructure may already depend on it.

Using managed AI services can fit naturally into that setting. An organisation can access models without taking responsibility for operating all of the underlying compute itself. Where that arrangement meets the workload's requirements, it can remain an appropriate choice.

The decision still needs to be made at the workload level. One department may be well served by its existing cloud environment, while another has requirements for dedicated infrastructure, a particular data location or a specialised model operated separately from a managed AI service.

Those differences do not require the organisation to start again with a separate product. They require an architecture that can accommodate more than one execution path, with clear decisions about what belongs in each environment.

Where AI Fabric adds another option

AI Fabric focuses on sovereign, private AI for governments and corporations. It gives us an infrastructure path for organisations that want greater control over where and how their AI workloads run.

That control needs to be considered across the deployment. The model is one component, but documents, retrieval systems, integrations and operational information also form part of an AI workflow. A meaningful infrastructure decision considers the complete path taken by the workload and its data.

For a customer, the discussion therefore starts with practical requirements. Which information will the system process? Who should have access? Which systems must connect to it? What control does the organisation need over its execution environment?

AI Fabric provides another option for answering those questions. The purpose is to align the architecture with the organisation's needs and provide a foundation for private AI applications, while retaining the ability to use other infrastructure where appropriate.

One product across two execution paths

The central idea is straightforward: the same product can support different execution environments. One organisation may primarily use Microsoft Foundry, another may primarily use AI Fabric, and a third may divide workloads between both.

For example, an organisation could choose one environment for a document workflow and another for a different type of analysis. This is an illustration of the architectural choice, not a rule that every customer should follow. The appropriate split depends on the information, tools, models and operational requirements involved.

Keeping the product layer separate means its knowledge connections, permissions and business workflows do not need to be recreated from the beginning each time the infrastructure choice changes. It provides continuity for the application while allowing the execution layer to develop.

Changing an execution environment still deserves engineering attention. Model behaviour, integration details and operational requirements can differ. The value of the separation is that these changes can be addressed within a defined part of the architecture, rather than forcing a wholesale product rebuild.

Choosing the right model for each task

Infrastructure is only one part of the decision. Different tasks can call for different models, and some tasks are better handled without a language model at all.

Complex reasoning may justify a more capable model. A focused document extraction task may be suited to a smaller one. A private workload may need a model running within AI Fabric. The choice should follow the task's requirements and be assessed against the result the organisation needs.

If an answer already exists in trusted organisational information, retrieving it can be more useful than generating a new version. If a business operation must follow explicit rules, conventional software can execute those rules directly. AI should be used where its capabilities contribute to the workflow.

This approach connects product design with infrastructure efficiency. It encourages us to consider the appropriate resource for each step, instead of sending every request to the same model simply because that model is available.

Preserving room for change

AI models and infrastructure will continue to evolve. Organisations will also learn more about their own workloads as they move from early experiments to regular use. A deployment choice made at the start of a project should leave room for that learning.

Separating application responsibilities from execution gives the platform a more adaptable foundation. Teams can consider new models or infrastructure options without discarding the knowledge connections and workflows they have already built.

Adaptability also depends on understanding what must remain consistent. Access rules and business requirements should continue to guide the application as technical components change. Infrastructure flexibility is valuable when it supports that continuity, rather than creating new fragmentation for users.

Our aim is to make these decisions easier to revisit as requirements develop. Customers should be able to assess a different execution path on its merits while preserving the value of their existing application work.

Sovereignty without isolation

Businesses already combine public cloud services, private networks, internal applications, databases and specialist systems. Enterprise AI can fit into the same kind of mixed environment.

XToka AI Fabric adds a controlled infrastructure option to that architecture. Customers can continue using Microsoft Foundry where it meets their needs and choose AI Fabric for workloads with different requirements. A hybrid approach can bring both paths into the same product strategy.

Building our own infrastructure was the first step. Designing the product so customers could retain a choice of infrastructure was the next. Together, those decisions support our view of practical enterprise AI: clear control over workloads, deliberate model choices and an application that can evolve with the organisation using it.