Introduction

Operaide is a platform for building, deploying, and operating AI-powered applications in TypeScript. The platform carries the non-functional concerns — authentication, multi-tenancy, access control, audit, deployment, connection management — so the code of your application can stay focused on the business problem. Whether you write every line yourself, pair with an AI coding assistant in the built-in IDE, or a mix of both is up to you.

What Operaide is

Operaide is a framework, a platform, and a built-in development environment for building AI-powered applications.

• Framework — you compose workflows (called Reaktors) from small, typed steps (called Aktors). Each aktor has explicit inputs and outputs. The platform runs the workflow, handles parallelization of independent steps, records every execution, and exposes the workflow as a REST endpoint with an OpenAPI specification. Aktors that call an LLM, extract structure from a document, talk to a database, send an email, or run a custom piece of business logic are composed the same way and look the same from the outside.
• Platform — a multi-tenant runtime that gives the framework somewhere to run. It ships with authentication (including OpenID Connect SSO), hierarchical role-based access control, the connection system through which every external integration is configured once and reused across workflows, a per-app-instance database and vector store, usage tracking for every LLM call and every workflow execution, and a monitoring dashboard.
• Apps with their own UI — a workflow can be used as a REST endpoint, but an Operaide application can also ship with its own web UI, designed for the specific business it supports: a review queue, a dashboard, an admin console, a task-specific data-entry screen. The UI uses the same authentication, roles, and tenant isolation as the rest of the platform, which means an application built for ten people in one department is held to the same security bar as one used across the entire organization. This is how Operaide enables interfaces that match the actual work, instead of forcing the work to match a generic SaaS product's assumptions.
• Built-in development environment — Operaide Studio is the platform's own IDE, running inside the platform itself. It works alongside AI coding assistants — Claude Code, Codex, Mistral Vibe, and others — that have been oriented to the platform's patterns through a curated set of skills and worked examples. The effect is that building an application does not begin with setting up a development environment and does not require every line of code to be written by hand. The direction of travel is that over time, less manual coding is needed, because the guardrails and the example library keep growing, and the AI coding tools are working against a known set of patterns rather than a blank page.
• Building blocks, not finished features — Operaide is deliberately not a library of pre-built AI assistants. It gives you the infrastructure to build the assistant that fits your organization. The substance of what your workflow does is yours to design; the scaffolding around it is not.

The platform runs as a containerized HTTP application. The simple path — and the default for most installations — is a single Docker container behind a reverse proxy of your choice. Larger deployments can split components across multiple containers when there is a reason to, but simplicity comes first: you do not have to orchestrate a fleet of services just to get started. The platform does not require a specific cloud provider, a specific database product, or a specific object store; you deploy the container where it makes sense for your organization.

How the platform thinks about LLM workflows

One choice runs through the design: a reliable LLM solution is built the way an experienced human would perform the task, decomposed into small, well-defined steps, each with a clear role, clear boundaries, a clear error path, and an escape hatch when a step cannot make a safe decision. This is deliberately the opposite of handing an open agent loop free rein over your data and tools. An autonomous agent is good at improvising; an experienced worker following a well-designed process is good at getting the same question right every time, and at explaining afterwards what it did and why.

The practical consequences show up everywhere in the platform. Workflows are code, so review and version control apply. Steps have typed interfaces, so the failure paths are visible before runtime. Execution records show the path a request actually took through the graph, not just the final answer. Access control, connections, and tenant isolation are platform primitives instead of workflow concerns.

This mindset is the most important piece of context for deciding whether Operaide is a fit for your problem. See the Design Mindset chapter for the longer treatment, including guidance on how to decompose a task, how to write prompts for individual steps, and how to judge in advance which kinds of problems fit this approach and which do not.

What you can build with it

Operaide is a good fit when your problem looks like one of these shapes:

• Knowledge-base Q&A over a specialized corpus — technical documentation, regulated content, internal handbooks — where the answer must be grounded in specific source documents and the provenance of an answer matters.
• Document analysis and classification pipelines — intake workflows that receive heterogeneous documents, classify them, extract structured fields per type, and route them downstream.
• Multi-step document or case workflows with human review gates — where an LLM produces a draft or a recommendation and a person has to approve or reject it before the workflow continues.
• Research and analysis agents constrained to a defined set of tools — the opposite of open-ended agents. The tool set is small, the task is specific, the output is structured.
• Internal tools with a bespoke UI that matches the actual work — an application built for your own organization, with an interface designed for the specific process it supports (a review queue, a classification dashboard, a department-specific data-entry workflow), deployed with proper authentication, access control, and audit. The AI is typically one step in a longer interaction rather than the entire product. These are the projects that tend to fall off the backlog because the cost of bespoke software is too high relative to the payoff; with the platform carrying the non-functional concerns and AI coding assistance carrying most of the typing, they become feasible instead of infeasible.

The pattern is that the same workflow runs many times, for many users or documents or tickets, under the same rules. If you are writing a one-off script you will run once, a simpler tool is probably a better choice.

Prerequisites and assumptions

• TypeScript. Application code is TypeScript. Your team needs at least one person who can read and review TypeScript well enough to steer an AI coding assistant — they do not have to write every line, but they need to judge and guide what the assistant produces.
• Code-first. Workflows are code, not visual blocks. This means version control, code review, and typed interfaces apply by default. There is no drag-and-drop builder.
• Multi-tenant from the start. The platform assumes multiple organizations share the same installation. Authentication, RBAC, and tenant isolation are always on — not optional add-ons.
• Self-hosted. You or your infrastructure operator run the platform. Data stays where you put it.
• Not an autonomous agent platform. The platform can run workflows that include agentic steps, but the design philosophy rewards bounded tasks with explicit checkpoints, not open-ended autonomy.

Where to go next

This handbook is organized into an Overview, a developer section (Part I), an administrator and operator section (Part II), and appendices.

Building applications:

1. Core Concepts — the vocabulary used throughout the handbook.
2. Aktor Framework — the composition primitive you will use every day.
3. LLM Calls — how to talk to models from inside a workflow.
4. Design Mindset — how to think about decomposing tasks for LLMs.
5. The rest of the key concepts and the examples in Part I.

Operating and administering the platform:

1. Security and Privacy — authentication, authorization, tenant isolation, and controlled data flows.
2. Compliance and Regulatory Positioning — how Operaide maps onto GDPR, the EU AI Act, and common compliance requirements.
3. Roles and Rights — the RBAC model.
4. The rest of Part II.

There is also a full Table of Contents for navigation.