Engineering

Where INNOQUO is heading

We explore and build the infrastructure, controls and knowledge systems needed to operate enterprise AI safely, observably and under governance.

We are not chasing every new tool or model. We work on problems that will still matter when the technology changes: identity, knowledge, permissions, security, evaluation and operations.

Clear view

Five engineering directions

Agent platforms

Infrastructure to run agents as enterprise systems — not demos.

Identity and execution context
Isolation and sandboxing
State and memory
Tool runtime and connectors
Execution control
Scaling and cost
Observability

Includes agents.innoquo.com — a platform to configure, connect and publish agents under your rules.

Explore Agents by INNOQUO →

Enterprise knowledge

Connected, verifiable and governed organisational knowledge.

RAG and retrieval
Enterprise search
Source provenance
Document permissions
Knowledge freshness
Quality and traceability
Multilingual content

Includes INNOQUO's knowledge base and Lang by INNOQUO for language-aware production AI.

Explore Lang by INNOQUO →

Identity and governance

Control over who can do what, on which resources, under which policies.

Which agent is acting
On whose behalf
On which resource
With which permission
Under which policy
When approval is required
How actions are audited

Tool protocols such as MCP are part of this problem — not a separate product category.

Explore AI governance →

AI security

Protecting data, tools, models and the platform itself.

Prompt injection
Data exfiltration
Tool abuse
Supply chain risk
Secrets management
Workload identity
Isolation and egress controls
Model and agent security

Explore AI security →

AI operations

Knowing whether the system actually works — and improving it.

Quality and evaluations
Cost and capacity
Latency and availability
Traces and audit
Incidents and regressions
Human supervision
Continuous improvement

Explore AI infrastructure →

Cross-cutting principles

Evidence before promises

Explicit controls

Least privilege

Reproducible architectures

Observability by design

Human intervention where it matters

Portability across models and providers

Visible engineering work

Visible work

Published architectures, labs, repositories, research and products — evidence you can inspect, not a promise list.

Reference architectures

Complete designs with components, flows, identity, security and operations.

Explore architectures →

Engineering labs

Reproducible implementations to validate patterns and controls.

Explore labs →

Applied research

Technical documents on production AI problems.

Explore research →

Open source

Reference code and modules we use, test and document.

Explore repositories →

Insights

Engineering notes on systems, decisions and operational lessons.

Explore insights →

Unified knowledge search

Search across research, architectures, labs and resources.

Search knowledge →

INNOQUO works so AI systems can know, act and evolve inside an organisation without losing control. Concrete implementations are linked here as they ship — not announced as future products.

Is there a problem we should investigate?

If you are designing an AI platform, connecting agents to enterprise systems, or establishing permissions and controls — tell us what obstacle you are hitting.

Propose a problem

Technical radiography

Technical radiography · Where INNOQUO is heading

The model is not the system

An enterprise AI system needs more than access to an LLM. The technical radiography shows how INNOQUO structures these capabilities, where we place trust boundaries and what controls each execution requires.

Model + Identity + Knowledge + Tools + Policies + Runtime + Evaluation + Observability = Production AI system

Reference architecture

A cross-cutting platform — not a chatbot with RAG. Select a layer to inspect responsibilities, boundaries and operational signals.

Model gateway OpenAI · Azure · Bedrock · vLLM

Tool gateway MCP · SaaS APIs · Databases · Event systems

Human control Approvals · Escalations · Review queues · Overrides

Channels through which users and systems interact with agents.

Responsibilities

Web and API
Copilots and chat
Backoffice tools
Enterprise applications

Operational signals

Request volume
Authentication entry point
Channel-specific policies

Who is acting, on whose behalf and with which claims.

Responsibilities

User and workload identity
Tenant isolation
RBAC and ABAC
Delegation and least privilege

Must not contain

Long-lived secrets in application code

Operational signals

Auth failures
Cross-tenant access attempts
Delegation expiry

Centralises agent definition and governance without necessarily executing workloads.

Responsibilities

Agent registry and versioning
Model and tool assignment
Policies and permissions
Quotas and deployments
Approvals and change audit

Must not contain

Plain-text secrets
Per-tool business logic
Full conversation storage by default
Direct execution without isolation

Operational signals

Policy changes
Deployment drift
Approval queue depth

Permission-aware enterprise knowledge — not only a vector store.

Responsibilities

Connectors and ingestion
Classification and chunking
Embedding and indexing
Permission-aware retrieval
Citations and provenance

Must not contain

Retrieval without ACL propagation
Unbounded source scope

Operational signals

Retrieval precision
Stale document rate
Citation coverage

Where agents plan, call models, invoke tools and validate results.

Responsibilities

Agent runtime and state
Workflow orchestration
Sandboxed execution
Retries and compensation

Must not contain

Unbounded execution time
Shared credentials across tenants

Operational signals

p95 latency
Tool failure rate
Retry storms

Guardrails, observability and continuous evaluation across every path.

Responsibilities

DLP and output filtering
Audit and traces
Evaluations and SLOs
Cost attribution
Incident response

Operational signals

Policy denials
Hallucination rate
Cost per successful task

Governed execution flow

How a request moves from authenticated entry to audited outcome.

1 Request enters authenticated
2 Identity context is built — user · organisation · tenant · roles · claims
3 Agent loads configuration and policies
4 Permitted knowledge, model and tools are selected
5 Retrieval respects document permissions
6 Model proposes a response or action
7 Policy engine evaluates — ALLOW · DENY · REQUIRE_APPROVAL
8 Tool runs with scoped credentials
9 Output is validated and filtered
10 Traces, costs, decisions and evidence are audited

Example

A finance agent may read invoices but not issue payment. Above a threshold, policy requires human approval and a delegated identity with temporary permissions.

Platform planes

Agent runtime

Session → State → Planning → Retrieval → Model call → Tool decision → Policy check → Execution → Validation → Response

Sync vs async execution
Stateless vs stateful agents
Tenant isolation and sandboxing
Retries, idempotency and circuit breakers

Knowledge plane

Enterprise sources → Connectors → Parsing → Classification → Chunking → Embedding → Permission-aware retrieval → Citations

ACL and chunk-level authorization
Freshness, lineage and deletion propagation
Data residency and retrieval observability

Identity and policy

Can [subject] perform [action] on [resource] under [context]?

RBAC vs ABAC vs custom policy services
Delegated identity for tool calls
Approval thresholds by risk level

Security

Untrusted input → Prompt injection → Model reasoning → Tool selection → Privileged systems → Sensitive or irreversible action

Instruction isolation and context validation
DLP, egress controls and tool scopes
SBOM and artifact verification

Operations

Trace → Identity context → Retrieval → Model → Policy → Tool execution → Evaluation → Cost attribution

Task success rate and groundedness
Approval and escalation rates
Human escalation and cross-tenant violations

Policy request

{
  "subject": {
    "user_id": "usr_123",
    "tenant_id": "acme",
    "roles": ["finance-analyst"]
  },
  "agent": {
    "id": "invoice-agent",
    "version": "2.4.1"
  },
  "action": "payment.create",
  "resource": {
    "invoice_id": "INV-2026-1842",
    "amount": 12800,
    "currency": "EUR"
  },
  "context": {
    "channel": "internal-portal",
    "risk_level": "high"
  }
}

Policy response

{
  "decision": "REQUIRE_APPROVAL",
  "policy": "finance.payment.high_value",
  "reason": "Payment exceeds autonomous execution threshold",
  "approver_role": "finance-manager"
}

Trust boundaries

┌──────────────── Enterprise ────────────────┐
│ Users · Applications · Internal data       │
│ Enterprise APIs and systems                │
└──────────────────┬─────────────────────────┘
                   │ Trust boundary
┌──────────────────▼─────────────────────────┐
│ INNOQUO platform                           │
│ Identity · Policies · Runtime · Knowledge  │
│ Audit · Evaluation                         │
└──────────────────┬─────────────────────────┘
                   │ Provider boundary
┌──────────────────▼─────────────────────────┐
│ External providers                         │
│ Model APIs · SaaS tools · Cloud APIs       │
└────────────────────────────────────────────┘

What data leaves the organisation?
Where does each component execute?
Who controls the keys?
How are tenants isolated?
Which provider may retain data?
How is an identity revoked?
What happens if the model proposes a dangerous action?
How is a decision reconstructed during an audit?

Threats and controls

Risk	Control
Prompt injection	Instruction isolation and context validation
Exfiltration	DLP, allowlists and output filtering
Tool abuse	Policies, scopes and delegated identity
Cross-tenant access	Strong tenant isolation
Secret leakage	Workload identity and secret broker
Supply chain	SBOM, signing and artifact verification
Irreversible action	Approval and compensation
Compromised model	Model gateway and external controls

Deployment patterns

Managed-first

Cloud AI APIs · Managed vector store · Serverless runtime · Enterprise IdP

Suited for

Speed · Lower ops · Variable load · Small teams

Trade-off

Vendor dependency · Less control · Regulatory limits

Controlled cloud-native

Kubernetes · Model gateway · Agent runtime · Policy engine · Observability · Managed models

Suited for

Multiple teams · Isolation · Central governance · Enterprise needs

Trade-off

Higher complexity · Internal platform · Operational cost

Regulated or sovereign

Private cloud / on-premises · Self-hosted models · Private knowledge plane · Restricted egress

Suited for

Highly sensitive data · Strict residency · Air-gapped environments

Trade-off

Cost · Capacity · Model operations · Slower updates

Implementation stack

Technologies can change. Architectural responsibilities remain.

Identity

Entra ID · Okta · Keycloak · IAM · SPIFFE/SPIRE

Runtime

Kubernetes · ECS · Lambda · Container Apps · Temporal · LangGraph

Knowledge

PostgreSQL · OpenSearch · pgvector · Azure AI Search · S3 · SharePoint

Models

OpenAI · Azure OpenAI · Bedrock · Anthropic · vLLM

Policy

OPA · Cedar · Custom policy services

Tools

MCP · REST · gRPC · Queues · Event buses

Observability

OpenTelemetry · Prometheus · Grafana · Langfuse

Security

KMS · Vault · Secrets Manager · Defender · GuardDuty

Decisions and trade-offs

Decision	Option A	Option B	Criterion
Agent state	Redis	PostgreSQL	Latency vs durability
Orchestration	LangGraph	Temporal	Reasoning vs durable workflows
Policy engine	OPA/Cedar	Custom service	Standards vs flexibility
Model routing	Direct provider	Central gateway	Simplicity vs governance
Retrieval	Vector-only	Hybrid	Cost vs quality
Execution	Serverless	Kubernetes	Elasticity vs control
Tools	Shared credentials	Delegated identity	Ease vs traceability

Published technical evidence

Architectures, labs, repositories and decision records — linked when available.