How Adam AI is built
A technical white paper for IT leaders, architects and security teams: the architecture, the knowledge system, how agents are controlled, and how data stays inside your business.
1. Platform architecture
Adam AI is the operating system for a company’s AI. Everything that matters runs on hardware the customer owns: the models, the knowledge, the agents and the data stores. Cloud models are an option you switch on per agent, never the default.
| Layer | What it does | Design choice |
|---|---|---|
| Hardware | A controller workstation runs the platform; a separate GPU render node handles image and video; an optional warm standby takes over if the controller fails. | Sized per customer. Heavy media work never competes with agents for the controller’s GPU. |
| Platform | Around forty containerised services: web front end, API, databases, vector store, knowledge graph, local model server, agent gateway, voice, object storage and cache. | Each service is isolated in its own container and can be restarted or rolled back on its own. |
| Data stores | Business data, contact and CRM data, and credentials each live in separate databases. Customers get their own isolated databases. | No queries join across stores. Credentials sit in a dedicated vault database with its own service account. |
| Local models | Open-weight language, embedding, vision and speech models served on the customer’s GPUs. | Our standard is to pin and test model versions before rollout rather than take whatever is newest. |
| Agents | Around forty specialist agents on schedules and in chat, each with one home position in the business. | The scheduler is the engine; the dashboard is the reporter, so people always see what agents did. |
| Interfaces | A dashboard for people, chat and voice, and connectors into the business systems already in use. | Customers keep their existing tools. Adam AI works alongside them. |
2. Skills, tools and integrations
Agents are only as useful as what they can do safely. Adam AI separates skills (how to do a job well) from tools (the systems an agent may touch), and grants both by position rather than by agent.
600+ skills
A searchable library of written procedures for sales, service, finance, marketing, operations and IT. Skills are embedded for semantic search, so agents find the right one by meaning.
70+ tools
One catalogue across documents and OCR, research, media generation, voice, search, automation, finance and CRM, comms, networking and security operations.
Standard tool protocol
Tools are exposed to agents through the Model Context Protocol, so every capability is described, permissioned and logged the same way.
Integrations cover the systems a growing business already runs: Microsoft 365, CRM and marketing automation, PSA, RMM and IT documentation, accounting, Direct Debit, e-signature, MFA and security monitoring. Writes into a business system require an explicit confirmation step.
3. The 2nd brain: knowledge systems
Every chat, agent and project draws on one shared knowledge system, queried on demand. The whole knowledge base is never pasted into a prompt; agents fetch only what the task needs.
| Tier | Holds | Why |
|---|---|---|
| Markdown cascade | How the business works: positions, procedures, rules and decisions, version-controlled. | Readable by people and agents alike, reviewable like code. |
| Temporal knowledge graph | Atomic facts and how they change over time: who, what, when, superseded by what. | Answers “what is true now” without losing history. Writes are allow-listed. |
| Vector search | Chunks of documents and learnings for semantic recall. | Finds the right paragraph by meaning, with access checks at retrieval. |
| Live business data | The current state of tickets, deals, invoices and devices. | Agents read the source of truth instead of a stale copy. |
| Session memory | What happened in a conversation or run. | Continuity without polluting the long-term store. |
Routing rule. Atomic facts go to the graph; narrative learnings go to Markdown plus a graph fact; large documents are chunked for search; each runbook lives in exactly one topic file.
Always in sync. Documents and learnings are change-detected and re-indexed on every release and hourly, and new learnings are added to the graph nightly. Knowledge health is measured as recall, not uptime: a timed real search must succeed at start-up, and each working session begins with a self-test.
4. Agent positional awareness and access control
The dashboard’s structure is the organisation chart. Sections are departments and pages are positions. Every agent has exactly one home position and inherits that position’s knowledge, skills and tools, and nothing more. That keeps each agent’s blast radius small and makes its job obvious to the people around it.
# Example position file (illustrative, simplified) owner: Head of Service agents: service-triage, service-drafts skills: ticket-summary, knowledge-lookup, reply-drafting tools: service-desk (read), knowledge (read), email (draft only) autonomy: L1 # drafts only, a person approves each one kpis: first-response time, reopen rate # Remove a line and the grant is gone. An agent named in no position does not run.
| Control | How it works |
|---|---|
| Autonomy levels | L0 observe, L1 draft for approval, L2 act from approved templates, L3 autonomous. Most customer-facing work starts at L1. |
| Privacy classes | Agents that handle customer, staff or financial data are private-class: local models only, with no cloud fallback. |
| People | Every dashboard sign-in needs two-factor authentication. Role, department and menu access are then checked on the server, not just hidden in the interface. |
| Agent credentials | Agents are isolated from API keys and token pools. They never hold a credential: access is implicit, granted through the isolated vault database and applied by the platform for the integrations their position allows. |
| Operating modes | A global mode (for example a public demo) caps what any chat, agent or device may see, whatever the user’s role. |
| Document clearance | Four clearance levels plus department scoping, checked when a document is indexed, when it is retrieved and when the original is downloaded. |
| Human approval | Actions in business systems preview first and need a confirm. High-risk changes wait in an approval queue. Records are archived, not deleted. |
| Secrets | Credentials are never fed into knowledge, logs or prompts. They live only in the vault, and every commit is scanned for leaked secrets. |
5. Microsoft 365
Microsoft 365 is where most of a business’s knowledge already lives, so the connection is designed to respect Microsoft’s own permissions rather than bypass them.
- Delegated access for people. Document and Teams search runs as the signed-in user, so Microsoft itself trims results to what that person may see. Per-user tokens are held encrypted.
- App-only access for the system is limited to defined jobs such as sending system email and ingesting a monitored mailbox, and is being narrowed to named mailboxes only.
- Admin consent only. In tenants we manage, user consent to AI apps is blocked, the admin consent workflow is on, and AI apps are set to assignment required.
- Minimal scopes. Read-only scopes by default; write scopes only for a named, approved job. Company workspaces only, never personal accounts.
- Change control. Connecting AI to a tenant is a high-risk change: a director signs off, then a senior engineer makes the connection, never the help desk.
- MFA. Multi-factor authentication is our standard on the Microsoft 365 mailboxes and administrator accounts we manage.
6. Containers, network isolation and updates
Container isolation
Each service runs in its own container with its own restart and roll-back. Data stores are separate services, and the credential vault has its own service account.
Private mesh, default deny
Devices join a self-hosted encrypted mesh. The rules are default-deny with per-device isolation: only the controller can reach a device’s agent, and no inbound firewall ports are opened.
Two locks on every device
The on-device agent is designed to listen only on the mesh, and every request also needs a per-device token. Calls are audited, tokens rotate with an overlap window, and revoking a device means rotating its token to nothing.
Pull-only updates
Devices dial in for updates; the controller never pushes. Update kits are hash-pinned and verified before anything runs, and contributions coming back up land switched off until a person clears them.
Continuous scanning. Every commit is checked for secrets; code and container images are scanned for vulnerabilities on a schedule, locally, with only the vulnerability databases fetched; third-party skills and tools are scanned before adoption.
Your box owns its state. There is no remote kill switch. If a subscription lapses, the customer keeps their hardware, data and every integration already wired in; only new library updates stop.
7. Air gaps and data egress
The question that matters is what can leave the building. The answer is decided by policy in code, not by individual users.
| Data class | Where it may go |
|---|---|
| Customer, staff, contact and financial data | Local models only. Private-class agents have no cloud fallback. |
| Business content that is not personal | Local first; an opted-in agent may use a cloud model through the privacy gateway. |
| Public content (for example marketing copy) | Any model, still logged. |
| Anything that looks like a credential | Never leaves. Hard block. |
| Unsure | Treated as private. |
The privacy gateway is the single checkpoint in front of every cloud model. A local classifier finds personal data, a per-customer list protects named entities, and each request is blocked and kept local, redacted then allowed, or allowed clean. When in doubt it blocks. Its logs store hashes of the content, not the content itself.
Air-gapped and offline sites. The local stack (models, knowledge and agents) does not need the internet to run. For a site that needs an air gap we deploy with every cloud tier switched off, and because updates are pull-only, the site takes them only when it chooses to. The honest trade-off: cloud-only models and cloud services are then unavailable.
What we deliberately keep back
This paper explains how Adam AI is designed and controlled. It is not a build guide. Network maps, configuration, model choices, source code and the results of our internal testing are shared with your technical team under NDA during a technical due-diligence session.
Technical FAQ
Do we need to open any inbound ports?
No. Devices talk over an encrypted private mesh, and the dashboard is published without opening inbound firewall ports.
Can an agent use a tool it was not given?
No. Tools and skills are granted by the agent’s position file. An agent outside any position does not run, and agents never exceed their position’s permissions.
Where are credentials kept?
In a dedicated vault database with its own service account. Agents never see them: access to an integration is granted implicitly through the vault, so a compromised prompt has no key to leak. Credentials are never fed into knowledge, prompts or logs.
How do people sign in?
Every dashboard sign-in requires two-factor authentication, and what each person can see and do is then enforced on the server by role, department and menu access.
Can Adam AI read our whole Microsoft 365 tenant?
Not by default. People search as themselves, so Microsoft trims results to their own permissions, and system access is limited to named jobs with minimal scopes.
What happens if we stop paying?
You keep your hardware, data and integrations. There is no remote kill switch; only new library updates stop.
Can it run with no internet at all?
The local stack can. For air-gapped sites we switch off every cloud tier, and cloud-only models and services are then unavailable.
Want the full technical pack?
Book a technical due-diligence session. We walk your team through the architecture and share the detail under NDA.