Home·Platform·Architecture

How it's built, and why that matters for your environment.

Ajutant is designed to be deployed in your own Azure tenant and operated by your own IT team. The architecture below explains how it runs, where your data lives, and how identity and access work. Written for the people who'll evaluate it.

Six principles, applied throughout.

The architecture is shaped by six commitments. Everything that follows in this page is a consequence of these.

Your tenant, not ours

The platform deploys into your Azure subscription. There's no shared backend, no multi-tenant database, no operational route by which we could see your data even if we wanted to.

Identity from your directory

Authentication, group membership, and access decisions come from your Entra ID. We don't issue identities. Off-boarding a user in your directory off-boards them here.

Packaged, repeatable deployment

The platform is deployed as a packaged set of Azure resources, configured to your environment. No long bespoke install. Re-deployable to a fresh subscription if you need to.

Swap models without re-platforming

The runtime calls models through a stable interface. You can swap the model behind any workload (Azure-resident, external, or open-weight) without changing the platform or the governance.

Built for IT operations

Full audit trail, request-level tracing through Azure Log Analytics, chat backups, scoped admin roles, kill switch per assistant or platform-wide. Designed to fit how an IT team already runs Azure workloads.

Integration is the point

Ajutant is built to connect to the rest of your environment, not to sit beside it. Assistants ground in your document stores. Workflows trigger from and feed into your business systems.

Deployed inside your Azure subscription. All of it.

There is no Ajutant-hosted control plane your traffic passes through. The application, the data, the indexes, the logs: all of it runs in resources we provision into your subscription, under your tenant's policies.

The application is a container workload. State lives in a managed relational database you own. Vector indexes for grounding sit alongside it. Logs go to your tenant's logging stack. You can switch the whole platform off in your subscription without involving us.

We retain a deployment toolchain to push updates and a support channel you can open if you need help. Neither has standing access to your data.

Your Azure tenantApplication runtimeContainer workloadIdentityYour Entra IDApplication dataManaged databaseVector indexFor groundingAudit & logsYour logging stackModel providersAzure AI / othersPITLDeploysSupportsUPDATES

Every Ajutant component runs inside your Azure tenant. We push updates and offer support. We have no standing read access to your data.

Your prompts and documents do not leave your tenant.

When a user sends a prompt, the platform retrieves grounding context from your indexes, calls a model endpoint, and returns the response. Every step happens inside your tenant boundary, except the model call itself.

The model call goes to a provider endpoint you choose: an Azure-resident model running in your subscription, or an external provider via an enterprise contract that disallows training on inputs. You decide which model each workload uses.

Nothing in this flow pipes telemetry, prompts, or document content back to us. The audit trail is yours to read, retain, and dispose of according to your own policies.

Your Azure tenantUserRuntime+ governanceYour dataVector indexAudit logYour tenantModelendpointYour choice1234In your tenantTo chosen model endpoint

1. User → Runtime · 2. Grounded against your data · 3. Model call to the endpoint you chose · 4. Logged in your audit trail.

Identity comes from your directory. Not from us.

Ajutant doesn't issue user accounts. Authentication is delegated to your Entra ID, and access decisions inside the platform are made against the same group memberships you already manage there.

An assistant can be scoped to a single team, a department, or the whole organisation. A user only sees the assistants their groups give them access to. Off-boarding someone in your directory off-boards them here.

Administrative roles inside the platform are themselves scoped against directory groups. There is no separate Ajutant user list to keep in sync.

Your Azure tenantYour Entra IDsingle source of truthLegal teamFinance teamPlatform adminsAjutantscoped by your groupsLegal assistantsFinance assistantsAdmin consoleSCOPES

Group membership in your directory drives every access decision inside Ajutant. No parallel user list to maintain.

Integration is the point. Not an afterthought.

An AI platform that doesn't connect to anything is a chatbot in a tab. Ajutant is designed to sit inside your environment, not beside it: grounded in your data, triggered by your systems, and routed to by other tools that need governed access to a model.

Inbound. Ground in your data. Assistants read from your document stores and knowledge sources, so answers are grounded in your own material.

Outbound. Drive your workflows. Assistants and workloads can call out to your business systems through the same governance layer.

Sideways. Route everything else through us. Any tool that needs a model can call Ajutant's gateway instead of going direct, so your governance applies even where the code isn't yours.

Connected the way your architects expect. Everything above happens through documented REST APIs specified in OpenAPI, slotting into your existing Enterprise Integration Platform with no Ajutant-specific connector.

Your Azure tenantAjutantruntime + gateway+ governanceDocument storesSharePoint, drives, KMsIdentity & policyyour Entra IDBusiness systemsvia your workflowsThird-party toolsvia gatewayGROUND INSCOPETRIGGER /DRIVEROUTETHROUGH

Ajutant sits in the middle of your AI activity: grounded in your data, integrated with your workflows, and the route through which other tools reach a model.

Feedback that stays in your tenant. Routed to your teams, not the provider.

When users react to an answer (was this useful, did it save you time, what went wrong) that signal is the most valuable data in the system. In most AI tooling, it goes back to the model provider. In Ajutant, it stays inside your tenant and routes to the people who can actually act on it.

Two streams, two destinations. Improvement signal goes to the team that owns the assistant. They use it to refine prompts, grounding documents, or which model is doing the job.

Serious issues route to IT Operations, in real time. Ethical concerns, explainability problems, factual errors that matter: flagged immediately to the people who can pull an assistant, escalate, or open an incident.

Either way, the signal stays yours. Nothing trains the provider's next model. The improvements compound inside your organisation.

Your Azure tenantUsergives feedbackAjutantroutes by typeAssistant ownerbusiness or KM teamIT Operationsin real timeUSEFULNESSTIME SAVEDETHICALCORRECTNESSrefineModelproviderNofeedback

User reactions never leave your tenant. Improvement signal refines the assistants you own; serious issues reach IT Operations immediately. The model provider sees none of it.

The shape of what lands in your subscription.

A high-level view of the resources Ajutant provisions and where each one sits. The detailed deployment shape is shared during scoping.

Compute
Container workload running the application and the gateway. Scales with usage; you control the limits.
Application data
Managed relational database for users, assistants, configurations, audit records. Backed up by your tenant's policies.
Vector grounding
Index of your own documents, for retrieval. Embeddings stored inside the same tenant.
Identity
Federated with your Entra ID. No separate user store. Your conditional access policies apply.
Model providers
Azure-resident or external by your choice. No bundled tokens. Swap any model behind any workload.
Audit & tracing
Request-level tracing and audit feed into Azure Log Analytics. Retention and access on your terms.
Backup & recovery
Chat history, assistant configurations and application state under your tenant's backup policy. Recoverable like any other Azure workload.
Operational controls
Scoped admin roles, kill switch per assistant or platform-wide, cost caps per team. For the people who run the platform day to day.
Feedback routing
User reactions captured in your tenant and routed: improvement signal to the owning team, serious issues to IT Operations in real time.
Deployment
Packaged Azure deployment, configured to your environment. Repeatable, not a long bespoke install.
Network boundary
Inside your tenant's virtual network, behind your network policies. No inbound from us.

Have your architect on the call. We'll go as deep as they want.

The detail above is the brochure version. A 30-minute walkthrough with whoever should evaluate the platform: the deployment shape, the data-flow specifics, and the questions your security team needs answered.