Obair — Technical Overview
What's under the hood
A detailed look at the Obair workflow engine — its architecture, task model, automation pipeline, AI integration, and deployment options.
Task Model
Three task types, one unified process
Every step in an Obair workflow is one of three task types. Mix them freely within a single workflow to model exactly how your process actually works.
Standard Tasks
Manual tasks assigned to one or more team roles. A team member takes ownership and advances the status through Not Started → Ready → In Progress → Complete. Supports On Hold for paused work and back-transitions when rework is needed.
Automated Tasks
Tasks that execute automatically when their predecessors complete. Configure a script type — webhook, shell, Python, or MCP tool — along with any required credentials and parameters. Execution is tracked, retried on failure, and logged to the task run history.
Decision Tasks
Branching nodes that evaluate context and route the workflow to the appropriate next task. Decisions can be made by a human (selecting from defined options) or delegated to an AI agent via MCP sampling — enabling LLM-driven process control without custom code.
Workflow Engine
Visual design, graph-powered execution
Workflows in Obair are directed graphs. The visual editor lets you build and modify them without touching code; the engine executes them with full state tracking.
Graphical Workflow Editor
A ReactFlow-based canvas where tasks are nodes and connections are edges. Drag to create tasks, draw connections between them, and configure each task via the detail panel. The graph is saved and immediately executable.
Directed Task Graph
Each workflow is a directed graph where tasks have predecessor and successor relationships. The engine automatically determines which tasks are Ready based on the completion state of their predecessors.
Rework Edges
Processes rarely flow in a straight line. Rework edges are backward connections in the graph that route a task back to an earlier step — modelling review loops, correction cycles, and iterative approval processes natively.
Workflow Templates
Any workflow can be marked as a template. Templates are instantiated into Jobs — concrete runs of the process — so the same workflow structure can be reused across many independent engagements or projects.
Automation Pipeline
Reliable automation, zero message loss
Obair's automation pipeline is built for production. It uses a transactional outbox pattern and NATS JetStream to guarantee that every automated task is executed — even across restarts, failures, and network interruptions.
Transactional Outbox
When a task transitions to Ready, a dispatch record is written atomically alongside the state change. No task can be lost between a database commit and the message queue — durability is guaranteed by design.
NATS JetStream
Task dispatch events are published to NATS JetStream, a durable message streaming system. Consumers acknowledge tasks only after successful execution — failed tasks are retried automatically up to a configurable limit.
Four Script Types
Automated tasks execute via webhook (HTTP POST to an external endpoint), shell script, Python script, or MCP tool call. All types receive the task context as structured JSON and return a result payload that is logged to the task run history.
Kubernetes Execution Profiles
For shell and Python scripts that need isolation or consistent resource limits, attach an Execution Profile. The runner creates a Kubernetes Job with the specified container image, CPU, and memory bounds — results are captured from pod logs and reported back to the workflow.
AI Integration
Workflow tools for AI agents
Obair implements the Model Context Protocol (MCP) in both directions — exposing its workflow engine as a set of tools that AI agents can call, and calling tools on external MCP servers as part of automated task execution.
Obair as an MCP Server
Any MCP-compatible client — including Claude Code and other AI agents — can connect to Obair and call workflow management tools: query workflow state, list ready tasks, create tasks, advance task status, clone templates, or delegate decision tasks to an LLM.
Obair as an MCP Client
Automated tasks with script type mcp_tool connect to an external MCP server and invoke a named tool, passing the task dispatch payload as input. This enables Obair workflows to drive any MCP-capable system — AI models, document processors, data pipelines, and more.
LLM-Driven Decisions
Decision tasks can be resolved by an AI agent via MCP sampling. The connected LLM receives the task context and the available options, evaluates them, and selects the next step — enabling AI-in-the-loop process control without custom integration work.
Secure, JWT-Protected
The MCP endpoint is protected by the same JWT authentication used across all Ullav services. Connecting an AI client requires a valid bearer token — no unauthenticated access to workflow data or operations.
Deployment & Scale
From pilot to enterprise scale
Obair is designed to grow with you. Start with a single team and a local deployment; scale to multi-team, Kubernetes-backed production without changing how you design your workflows.
Three-Component Architecture
The platform runs as three independent services: awe-server (the REST API and workflow state manager), awe-relay (the outbox-to-NATS bridge), and awe-runner (the task executor). Each can be scaled independently to match your throughput requirements.
PostgreSQL Durability
All workflow state, task history, execution logs, and notes are persisted in PostgreSQL. Migrations run idempotently on startup — no manual schema management required during upgrades.
Docker & Kubernetes Ready
All Obair services ship as Docker images with Helm charts for Kubernetes deployment. Sensitive configuration is passed via Docker secrets or Kubernetes secrets — never baked into images.
Multi-Language Interface
The Obair web application supports English, German, and Irish (Gaeilge) via next-intl. Teams operating across language regions can use the platform in their preferred language without any customisation.
API
A complete REST API
Every capability in the Obair UI is also available via the REST API, documented with OpenAPI and a Swagger UI. Integrate Obair into your existing toolchain, build custom dashboards, or drive workflows programmatically.
Full CRUD for Workflows & Tasks
Create, read, update, and delete workflows, tasks, task links, and jobs via REST. Clone templates, merge workflows, and manage the full lifecycle of your processes through the API.
Task Status Management
Advance or revert task status via API — the same state machine enforced in the UI. External systems can drive workflow progression without going through the Obair interface.
Execution History
Query the full run history for any automated task — including input payload, output payload, outcome, timing, and runner identity. Build custom reporting and alerting on top of Obair execution data.
OpenAPI Documentation
The full API is documented with OpenAPI 3.0 and served via Swagger UI at /swagger-ui. Client SDKs can be generated from the schema for any language.
Technical FAQs
Technical questions answered
What is the technology stack?
The awe-server backend is built in Rust using the Axum framework, with PostgreSQL for persistence, NATS JetStream for message queuing, and optional Kubernetes integration for task execution. The Obair web application is built with Next.js 16, React 19, TypeScript, and Tailwind CSS. The graphical workflow editor uses the ReactFlow (@xyflow/react) library.
How does the automation pipeline guarantee delivery?
When a task transitions to Ready, a dispatch record is written in the same database transaction as the state change (transactional outbox). A separate relay process picks up unpublished dispatch records and publishes them to NATS JetStream. The runner consumes from NATS and acknowledges only after successful execution. This three-step chain means no automation is silently dropped — even if any individual component restarts mid-process.
Can Obair connect to AI agents like Claude?
Yes. Obair exposes an MCP server endpoint (Streamable HTTP, JWT-protected) that any MCP-compatible client can connect to. This includes Claude Code, Claude Desktop, and any agent built on the Model Context Protocol. Exposed tools include workflow state queries, task creation, status advancement, template cloning, and LLM-delegated decision resolution.
What deployment options are available?
Obair can be deployed as a fully managed SaaS installation, as a self-hosted Docker Compose setup, or on Kubernetes via the provided Helm charts. On-premises and hybrid deployments are supported for organisations with data residency or network isolation requirements. All configuration is externalised via environment variables and Docker/Kubernetes secrets.
Does Obair expose a public REST API?
Yes. All workflow, task, job, note, and execution management operations are available via a documented REST API. The full schema is available in OpenAPI 3.0 format, with a Swagger UI served at /swagger-ui. Authentication is via JWT bearer token using the shared Ullav auth infrastructure.
How does Obair fit into the broader Ullav platform?
Obair shares authentication (ullav-user-management JWT service), deployment infrastructure (Docker/Kubernetes on ullav-net), and integration patterns with the rest of the Ullav product suite. It is designed to work alongside Comad for asset management workflows and can be connected to any other Ullav product or external system via the API or MCP.
Ready to build smarter workflows?
Get in touch to discuss how Obair can be deployed and tailored to your organisation's needs.