Technical Overview · October 2026
Technical Overview.
How Evolvable.ai works.
Architecture, security controls, integrations and deployment for the sovereign AI agent platform. One install on your infrastructure runs your agents, your workflows and the controls around them.
0+
integrations, native and MCP
0+
AI Firewall detectors
0
workflow node types
0
ways to deploy, incl. air-gapped
01
Reference architecture.
A containerised platform inside your estate. Every request enters through one gateway, runs through the trust layer and touches only the systems and models you connect.
Evolvable platform
containers · your infrastructure
Gateway · TLS · Auth · Tenant. Schema-per-tenant isolation · every store inside your network
Evolvable Edge
Sensor on Windows, macOS & Linux devices; 20+ AI services
Network integrations
Firewall, IPS, WAF & web proxy logs ingested
Built on proven open technology
Operating the platform
Multi-tenant
Many units or customers per install, each with its own data, keys and policies.
Health & metrics
Built-in health views; events to your monitoring by webhook.
Backup & restore
Standard database and storage backups; encrypted config export.
Updates
Versioned container images; offline bundles for air-gapped sites.
Design principles
Sovereign by default
Platform, data, logs and keys stay in your estate. Models run where you choose.
Controls in the runtime
Firewall, gates and audit run inside the request path, not as add-ons.
Open standards
MCP for tools and building, an OpenAI-compatible API, standard databases.
No lock-in
Your LLM accounts, your data stores, exportable agents and configuration.
02
The runtime: life of a request.
Every request follows the same seven steps. The controls are part of the runtime, not a proxy in front of it, so nothing reaches a model, a tool or a user without passing them.
- Receive
- Authenticate
- Screen input
- Reason & retrieve
- Gate actions
- Screen output
- Record
Runtime · AI Firewall · Human oversight · Observability
- 1
Receive
From a channel, API, webhook or schedule.
- 2
Authenticate
User, role, tenant; per-user sign-in if needed.
- 3
Screen input
Firewall blocks, masks or flags the prompt.
- 4
Reason & retrieve
Plans, retrieves, delegates to sub-agents.
- 5
Gate actions
Risky tools wait for a person or AI judge.
- 6
Screen output
Response and tool results checked.
- 7
Record
Trace, version, cost and ROI saved.
Three engines, one runtime
Agent teams
- Sub-agents, agent-to-agent calls and parallel fan-out
- Skills, JSON schemas, model per agent
- Versions, diff and restore; evals before go-live
spawned on demand
Workflows
- ~80 node types incl. agents, MCP, SQL, Python
- Triggers: webhook, schedule, Slack, mailbox
- Durable approval and decision nodes
Dual RAG & memory
- pgvector semantic + Neo4j graph retrieval
- Read-only text-to-SQL on structured tables
- Curated, learned and scoped memory
+ SQL tables + memory
Interfaces for your developers
Chat & task APIs
Sync, streaming (SSE) and async tasks
OpenAI-compatible
Drop-in for existing OpenAI SDKs
Builder MCP API
Build agents from any MCP client
Signed webhooks
HMAC-signed, with retry & replay
Anatomy of an agent · configured, not coded
Identity
Instructions, model, behaviour, output schema
Knowledge
Documents, databases and memory it may use
Capabilities
Tools, connectors, skills, sub-agents, sandbox
Governance
Firewall policies, approval gates, risk tier
Value
ROI tags, evals, monitoring, versions
03
Integrations & models.
Connections are set once per tenant, enabled per agent, and called with a shared service account or each user's own identity. Four methods reach anything your agents need.
Examples shown; systems without a ready connector are reached through MCP or REST.
Bring your own model, per agent
- OpenAI · Cloud
- Azure OpenAI · Cloud
- Anthropic · Cloud
- Google Gemini · Cloud
- Ollama · Local
- vLLM · Local
- TGI · Local
- Per agent: Each agent picks its model; tenant default as fallback.
- Your bill: Your own LLM accounts, no mark-up. Spend tracked per model.
- Air-gap ready: Local models via Ollama, vLLM or TGI on your GPUs.
GPU sizing for local models · INT8 VRAM
No GPU needed when you use cloud model APIs.
Every channel your people use
How agents sign in to your systems
Shared service account
One account per connector, held in the key vault. Best for back-office automation and workflows.
Per-user identity
Each user signs in with their own Microsoft or Google account; the agent acts with their permissions only.
04
Security & governance.
Five layers of control wrap every agent and workflow. Each layer writes its own evidence, so audit answers come from records, not interviews.
Identity, keys & tenant
Schema-per-tenant isolation · JWT sessions and granular roles · SHA-256-hashed API keys with rotation · key vault secrets by reference · per-user OAuth for connectors · TLS everywhere
AI Firewall & Edge
Input and output policies on selected or all agents · 60+ detectors: PII and national IDs, secrets, injection, jailbreak, exfiltration, 14-language profanity incl. Arabic, LLM judges · block, mask or flag · Evolvable Edge on devices
Human oversight
Pre-approval, veto window, AI judge, post-review or blocked · on any tool, MCP call or workflow step · approver groups and SLA escalation · risk tier and coverage per agent
Observability & evals
End-to-end traces · error rate, guardrail hits and eval pass rate per agent and model · evals before go-live · supervisor monitoring
Audit & evidence
LLM, tool and decision logs · firewall executions with review status · every agent and workflow versioned; fleet as of any date
Audit evidence on record
LLM call log
Prompt, response, model, tokens, cost
Tool & decision log
Every action, approver, reason, timing
Firewall executions
Detector, action, review status
Change history
Every version; fleet as of any date
Where your data goes
Evidence for the frameworks you report against
- ISO/IEC 42001
- NIST AI RMF
- EU AI Act
- OWASP LLM Top 10
- UAE PDPL
- DIFC Reg. 10
- KSA PDPL & SDAIA
- IIA
- Compliance mapping · coming soon
Shared responsibility
Evolvable.ai
Releases & security fixes · detector updates · deployment guides · support · sizing & hardening help
You
Infrastructure & OS · network controls · backups · TLS & DNS · identity & approvers · model accounts & GPUs
05
Deployment & sizing.
Containers for Docker Compose or Kubernetes with Helm. The same build runs everywhere; separate environments are separate instances or tenants.
Public cloud
AWS, Azure, Google Cloud or a local-region cloud
Private cloud
OpenShift, VMware or sovereign cloud
On-premises
Your data centre, cloud or local models
Air-gapped
No internet; local models; offline updates
Platform sizing
Databases co-located on one host.
Dedicated PostgreSQL (HA) and Neo4j. Confirmed in a sizing workshop.
Software
- Ubuntu 22.04+ / RHEL 8+
- Docker 24+ & Compose v2
- Kubernetes 1.27+ & Helm 3
- PostgreSQL 15+ & pgvector
- Neo4j 5+
- NGINX / Traefik
- Ollama / vLLM / TGI (opt.)
Network flows
none in air-gapped mode
per use case
Your network
Typical rollout
- 01
Week 0
Prerequisites agreed
- 02
Week 1
Install, SSO, firewall on
- 03
Weeks 2–4
First agents live
- 04
Ongoing
Scale & govern
What we need from you before day one
- Linux hosts or a Kubernetes cluster sized as above
- DNS names and TLS certificates
- Identity provider and role mapping
- LLM accounts or GPU servers
- Service accounts for the systems to connect
- Firewall rules for the flows above
Take it with you
The Technical Overview datasheet
All six pages, print-ready. Share it with your architects, platform engineers and security team.
PDF · 6 pages · 0.5 MB
Planning a deployment?
Book a sizing and architecture session.
One install on your infrastructure runs your agents, your workflows and the controls around them.