Skip to content

ORA (OR Assistant)

Platform Users — Engineers & Low-code Ops Users (ORA / Panel Builder) OR Platform ORA — AI Planning Interface Agent Workflows Plan Visualisation ADK Integration SDK UI — Frontend Shell FDK Architecture Low code Config-driven DDK Schema Definition Code Generator Generated Server MDK WEM DAL Experiment Manager Nexus Deployment Control Live Monitoring Registry Browser SCDK Source Control Pipeline Mgmt Azure DevOps deploys ↓ SDK API — GraphQL Federation Gateway Federation Gateway Component Resolvers Auth & Licensing Plugins: gql-autogeneration Migrator Helm KinD Boilerplate GenAI ··· Microservices — Domain IP Services Data Pipeline Core Platform Metrics & Analytics Spatial & Geo Simulation Event Detection Camera & Device Fire & Resource Opt. Satellite Modelling ↓ Nexus deploys Deployed OR Applications Rail Ops Dashboard Mine Mgmt Dashboard Port Ops Dashboard ··· FDK-built · DDK-backed · MDK-powered · deployed via Nexus ↑ Application Users — Operations Teams (shift managers, analysts, planners)

ORA (OR Assistant) is the AI application built on the ADK. It provides a chatbot interface where users can describe a business problem, get a structured application plan, and build OR application components — all powered by ADK's agent orchestration and plugin capabilities.

Who is this for?

  • New OR users who want to translate a business problem into a structured application plan before deciding which platform components to use
  • Domain experts and operations analysts who want to engage with OR without deep platform knowledge — describe the problem in plain language, get a clear plan
  • Experienced OR developers prototyping the architecture of a new application before committing to detailed implementation
  • Project teams scoping a client brief and needing a platform-aligned plan with defined user flows, research tasks, and success metrics

Platform Context

Why This System Exists

The Optimal Reality platform is powerful — but that power comes with complexity. Knowing which DK to use for a given problem, how to structure a workflow, what data connections are needed, and how an application should be architected takes time to learn.

For a domain expert — an operations analyst, a logistics planner, a network engineer — the value is in the problem they need to solve, not in learning platform tooling. If significant platform knowledge is required to get started, the time from "business problem" to "working OR application" is long, and the barrier to adoption for non-technical stakeholders is high.

ORA addresses this directly. A user describes their business problem in natural language, and ORA orchestrates an AI agent workflow that analyses the problem, identifies what needs to be built, designs the user flows, and produces a structured application plan — all before a line of code is written. The output gives the team a clear map: what models to build, what data layer to define, what application to construct, and what outcomes the system should drive toward.

What this enables in practice:

  • A logistics team that needs an OR-powered tool for fleet scheduling can describe the problem to ORA and receive a structured plan — research tasks, user flows, key metrics — that maps directly to how the platform would implement it. They start building with clarity, not guesswork.

  • A new project team unfamiliar with OR can use ORA to translate a client brief into an actionable platform plan, reducing the time needed to move from scoping to development.

  • An experienced OR developer can use ORA to rapidly prototype the architecture of a new application before committing to detailed implementation work.


Core Concepts and Principles

Agent workflows, not chatbot responses

When a user sends a message to ORA, it does not return a pre-formatted answer. It triggers an agent workflow — a directed graph of AI-powered tasks that runs on the ADK backend. Each task performs a specific analytical function: researching the problem domain, defining user personas and their journeys through the system, identifying measurable objectives. Because these tasks run as an orchestrated workflow rather than a single prompt, the reasoning can be structured, parallel where appropriate, and inspectable at each step.

Transparent reasoning via live workflow visualisation

As the agent workflow runs, ORA displays it as a live DAG alongside a Kanban board of task states — pending, in progress, completed. Users see which analysis steps have finished and which are still running, making the AI reasoning process transparent rather than a black box. For the kinds of high-stakes operational decisions OR is designed to support, this matters: teams need to understand how a plan was developed, not just receive it.

Structured output that maps to platform capabilities

ORA's output is not a narrative document. It is a structured application plan with distinct sections: research tasks, user flows (as navigable persona journey diagrams), and key metrics with measurable targets. This structure maps directly to how OR applications are built — research tasks become the models and data sources needed in MDK, user flows become the FDK application screens, and metrics become the experiment objectives. The plan is designed to be actioned using the rest of the platform, not just read.

From plan to configuration — each DK as an AI tool

Beyond planning, ORA can directly configure and build application components through the ADK's tool-use capabilities. Each OR DK — DDK, MDK, FDK — is surfaced as a composable AI tool. This means ORA's agent can take the plan it has produced and begin scaffolding concrete platform artifacts: defining data schemas in the DDK, creating workflow structures in the MDK, or generating application components in the FDK. The agent operates with the same capabilities an OR developer would use manually, but driven by the plan it generated from the user's original problem description. This closes the loop from natural language input to working OR application structure — without requiring the user to manually translate each planning decision into platform configuration.

Persistent context per project

ORA maintains a persistent agent and chat session for each OR project. Conversation history is preserved across sessions, so teams can return to a planning conversation and continue where they left off. ORA accumulates understanding of the problem over multiple interactions rather than starting fresh each time.


Role in the Optimal Reality Platform

ORA occupies the AI planning layer of the Optimal Reality platform. It sits above the execution and data layers, providing a natural language interface that translates business problems into structured plans for how the platform should be used.

ORA is responsible for:

  • AI-powered application planning — orchestrating an agent workflow that analyses a business problem and produces a structured, actionable plan
  • ADK integration — ORA is built on the ADK (Agentic Development Kit), OR's AI runtime layer that manages agent lifecycle, workflow execution, and surfaces every OR DK as a composable AI tool
  • Plan visualisation — surfacing the agent's reasoning as a real-time workflow DAG, task Kanban board, and structured plan overview

ORA interacts with:

  • ADK — all agent lifecycle management (agent creation, chat sessions, workflow polling) is handled by the ADK (Agentic Development Kit), OR's AI runtime layer
  • FDK / MDK / DDK — the plans ORA generates are intended to be built using the other OR DKs, bridging from business requirements to platform implementation
  • or-sdk-api — ORA communicates through the SDK API gateway, which federates the ADK subgraph

How It Fits in the End-to-End Platform

User (natural language description of a business problem)

ORA (AI chat interface + live plan visualisation)

ADK backend (agent lifecycle, workflow execution)

Agent workflow tasks (research, user flow design, metric definition)

Output: Structured Application Plan

FDK + MDK + DDK (used to build the planned application)

ORA sits at the entry point of the platform journey — it helps users understand what to build and how before they engage with the detailed tooling of the MDK, FDK, and DDK. It is the bridge from a business brief to an OR implementation plan.

User documentation for Optimal Reality