Platform architecture · Téchnéos

Enterprise AI Application Kernel

Before this existed, every AI engagement rebuilt the same things from scratch: authentication, permissions, LLM provider plumbing, audit logging. The kernel makes that a one-time cost. It ships identity, fine-grained authorization, an AI gateway, governed tool execution, workflow orchestration, audit and observability out of the box, so a client project only writes domain logic.

The problem

Enterprise AI systems fail on governance long before they fail on model quality. A client in a regulated sector cannot deploy an assistant that calls internal tools unless every action is attributable: who asked, what were they allowed to do, which prompt version answered, which tools ran, and what was returned.

Rebuilding that per project is expensive and inconsistent. The kernel turns it into infrastructure.

What I built

Backend (NestJS)

  • Execution context & correlation propagation — a single correlation identifier carried through every request, LLM call, tool invocation and audit record.
  • Prompt registry with immutable versioning — prompts are addressable artifacts, so any past answer can be traced to the exact text that produced it.
  • MCP tool layer — governed tool execution, where each tool call is authorized, logged and bounded rather than trusted by default.
  • Durable workflows on Temporal, so long-running AI jobs survive restarts and resume rather than restart.
  • Audit and retention with allowlisted payloads, plus encryption of tenant LLM provider keys.
  • Identity and authorization — OIDC provider admin integration, fine-grained access groups and grant reconciliation against the authorization engine.

Frontend (Next.js)

  • A streaming chat interface with visible tool calls, attachments and dark mode.
  • An administration console of roughly 40 pages covering tenants, users, groups, grants, prompts, tools, models, workflows, audit and system health.

Infrastructure

  • Docker Compose stacks for local, staging and production topologies.
  • Identity realm-as-code and a version-controlled authorization model, so access rules are reviewable in pull requests.
  • CI checks enforcing architectural invariants, plus production deployment and backup tooling.

Invariants enforced in CI

Some properties are too important to leave to code review, so the build fails when they are violated:

  • No secret defaults — no configuration path silently falls back to a development credential.
  • No prompt text in telemetry — traces and metrics carry identifiers, never user or prompt content.
  • Allowlisted audit payloads — audit records contain explicitly permitted fields only.

Outcome

All nine planned milestones shipped in about ten weeks, ending with a documented boundary between kernel and business code: seven registration seams that let a client application be built without editing a single kernel file.

The property that matters commercially is traceability. One correlation identifier resolves an AI action to its authorization decision, prompt version, tool calls and distributed trace — which is what makes these systems deployable inside regulated client networks at all.

Estimate, not a logged metric: a new client project now starts with authentication, role-based access, audit and AI plumbing already working, realistically saving several weeks of setup per engagement.

Stack

Note: this case study is deliberately written without client names, product names or customer data. Milestone counts, test-suite counts and commit shares are taken from the repository; anything not measured is labelled as an estimate.