Foundry, plus the layer
you would otherwise build yourself
The Neologik Platform is not an alternative to Microsoft Azure AI Foundry. It is built on it, and it runs on Kubernetes inside your own Azure subscription. What we add is the governance and operations layer around it: an identity per agent, audit, autonomy limits, memory with erasure, knowledge, channels and the admin surface that keeps it all running.
Where the platform fits
If you want a draft email summarised or a slide written, a consumer app is perfect. If you want an RFP completed using approved content, in the right format, with an audit trail, that is where Neologik fits.
​
The platform connects your AI, your data and your systems into one governed layer. Large language models get cheaper and more capable every month, so the layer is deliberately model agnostic. You can switch the underlying model without rebuilding the workflow around it.
Built Foundry First
For every capability the platform needs, we look at what Azure AI Foundry already offers before building anything, and any decision not to use Foundry needs a written justification. Here is the whole picture, including the parts still in progress.
Status is stated as documented, not as we would like it to be. Where something is inÂ
preview or merely announced, we either put it behind a switch or defer it.
Only build on released services
Anything Microsoft labels preview, or has merely announced, is adopted behind a switch or deferred. Your production systems never sit on unfinished services.
Your data stays in your environment
Agents, tools and data stores all run inside your own Microsoft subscription. Any Foundry feature that would move data or control outside that boundary needs explicit safeguards, or we do not use it.
Actions are traceable to people
Every agent has its own identity, and tools act on behalf of the individual user wherever attribution matters. Any integration route that would blur who did what is not used.
How it is put together
Operators curate content, configure behaviour and grant reach. An agent with no channel is a worker only other agents can call. An agent with no knowledge attached answers from its model alone. Attach an index and it searches your documents and cites them.
Agent
A model given a job: instructions, tools, knowledge, memory and limits. Every agent is a row of configuration; the model it runs on is one of its settings.
Sub agent
A helper owned by one parent agent. No channels of its own, called by the parent over the secured agent to agent channel.
Worker
A standalone helper with its own compute and identity, reached only by agents and apps holding an explicit connection.
App
A bespoke application of yours registered on the platform, provisioned the same hands free way agents are.
MCP Server
A tool service with typed operations: create a Planner task, run a query, generate a Word document. Not an agent. No instructions, no judgment, no conversation
Connection
An operator created permission for one agent to use another agent, a tool or a model. No connection row means no access, always.
Agent Identity
The agent's own Azure and Entra identity. This is the security boundary for its data.
Knowledge Index
A searchable store of your ingested documents: one Azure AI Search index plus a storage container. Attach it and the agent cites what it used.
Loop
A standing, scheduled or manual task for an agent, with a judge model, a quality threshold and an optional human approval gate.
Blueprint
One shareable file describing a complete use case, anonymised by construction, that rebuilds that use case in another environment on import.
Channel
A typed attachment on an agent that provisions the surface people reach it through: Teams and Copilot, web chat or email.
Governance tier
General, confidential or restricted, recorded against each agent and each loop. A configuration time control, not runtime isolation.
Where everything runs
Agents, tools, apps and data stores run on Kubernetes inside your own Azure subscription. Nothing multi tenant sits between you and your agents.
​
Models are called through your own Foundry account. Configuration lives in the platform's own SQL database, which is the master record of every agent. Chat history, analytics and memory live in Cosmos DB. Secrets live in your environment's Key Vault and are never displayed again once stored.
An identity per agent
Every agent has its own Azure and Entra identity, which is the security boundary for its data. Row level security applies to every agent, at every tier.
Releases that have to pass
Foundry Evaluations score agent behaviour against pass or fail thresholds before a change goes live, folded onto our own test harness.
Governance tiers, described accurately
General, confidential or restricted, recorded against each agent and loop. It gates web search, confirms downgrades, floors loop tiers and travels with blueprints. It is a configuration time control, not runtime isolation, and we say so.
Governance is the product, not the paperwork
Agents, tools, apps and data stores run on Kubernetes inside your own Azure subscription. Nothing multi tenant sits between you and your agents.
​
Models are called through your own Foundry account. Configuration lives in the platform's own SQL database, which is the master record of every agent. Chat history, analytics and memory live in Cosmos DB. Secrets live in your environment's Key Vault and are never displayed again once stored.
No connection, no access
One agent may use another agent, a tool or a model only where an operator has created a connection. There is no implicit access anywhere in the platform.
Memory you can erase
Memory consolidation is on by default and disclosed at onboarding. The controls are a per agent switch and a Forget user action that removes an individual's memory.
Audit that names the person
Tools act on behalf of the individual user wherever attribution matters, so the trail records who did what rather than which service account did it.
Cost you can see
What each workflow costs to run, by agent and by team, before the invoice arrives rather than after.
Autonomy with a brake
Loops carry a judge model, a quality threshold and an optional human approval gate. Token budgets and tool permissions are set per agent.
Answers that cite their source
Attach a knowledge index and the agent searches your documents and cites them, with the document version it used.
The context engine is the bit most people forget to build
The admin surface is served from your own environment. It is where your operators create agents, build indexes, get documents in, open channels and check that any of it is working.
Working areas
Home, Agents, Indexes, Knowledge and Analytics for operators. Apps and MCP, Blueprints, Audit and Admin for administrators
Checks are named, not skipped
Anything the platform cannot evaluate is listed as such rather than quietly passing. An empty green panel you cannot trust is worse than no panel.
Platform Health, on the home page
Provisioning issues, failed indexing, loop approvals waiting, certificate and secret expiry, unset model slots and channels awaiting admin consent.
Blueprints and reuseÂ
A complete use case exports as one shareable file, anonymised by construction, and rebuilds itself in another environment on import.
Start from a pattern, notÂ
a blank page.
400
agent patterns, anonymised by construction
Our catalogue holds 400 agent patterns across construction, financial services, the public sector and consulting, mapped to the lifecycle of the work rather than to a feature list. 100 of them are already running on the platform for clients in regulated environments.
100
already running on the platform today
400
agent patterns, anonymised by construction
4
4
industries, each with eight business areas
industries, each with eight business areas
100
already running on the platform today
0
client names or configurations in any pattern
0
client names or configurations in any pattern