Authoring boundary
Studio serializes one APL document from its canvas and YAML editor; BPMN XML is transpiled at import. Dry Run is local and mocked; Deploy & Start is the only authoring action that persists state.
Architecture overview
Abada orchestrates agentic workflows on a transactional ACID rail. Studio is the AI-native authoring and operations surface, APL is the native definition language, the Engine is a PostgreSQL-authoritative transactional core, agent nodes execute as durable external work, and the Insight Engine closes a governed self-optimizing loop. Clients and workers use the versioned API; any engine replica may handle a command; PostgreSQL owns the workflow truth.
flowchart TB
subgraph Authoring[Abada Studio - single operator UI]
D[Designer: canvas + APL YAML + AI assist]
R[Run: Dry Run local · Deploy & Start durable]
I[Insight: proposal review]
O[Operations: instances · worker health]
end
subgraph EngineC[Engine cluster]
E1[Engine replica 1]
EN[Engine replica N]
end
AW[Agent Worker - first-party sidecar]
W[Third-party workers]
DB[(PostgreSQL: state · facts · proposals)]
AN[Insight analyzer]
M[LLM provider]
P[Traefik or trusted ingress]
IDP[OIDC identity provider]
D --> R
R --> P
P --> E1
P --> EN
E1 <--> DB
EN <--> DB
E1 -. agent task .-> AW
AW --> M
M --> AW
AW -. complete + attempt metadata .-> E1
W -. fetch-and-lock .-> E1
AN -. lease .-> DB
DB -. findings + proposals .-> AN
AN -. validated APL drafts .-> DB
I -. approve / reject .-> E1
IDP -. signed JWT .-> E1
E1 -. optional OTLP .-> O[OpenTelemetry backend]
The doctrine expressed across these components is the table is the law, agents are the advice: deterministic decision tables evaluate inside the transaction, probabilistic agent work stays on the durable worker protocol, and humans govern every executable change.
Architectural boundaries
Section titled “Architectural boundaries”Public boundary
/api/v1 and worker protocol v1 expose stable DTOs, typed errors,
pagination, idempotency and trace propagation — including the additive
abada.agent/v1 profile.
Execution boundary
Core command services reconstruct state and execute the canonical model inside explicit transactions; agent and external work always arrives back through a command.
Persistence boundary
JPA repositories and Flyway migrations map durable definitions, instances, tasks, subscriptions, jobs, variables, history, Insight facts and outbox records.
State ownership
Section titled “State ownership”| State | Authority | Replica memory policy |
|---|---|---|
| Definitions and versions | PostgreSQL deployment rows | Parsed immutable model may be cached by deployment ID |
| Instances, tokens and joins | PostgreSQL | Command-local only |
| Variables and user tasks | PostgreSQL | Detached read snapshots or command-local models |
| Subscriptions, timers and work | PostgreSQL | Acquired through locks and leases |
| Agent and external tasks | PostgreSQL external-task rows (attempt metadata included) | Acquired through fetch-and-lock leases |
| Insight facts, findings and proposals | PostgreSQL (facts commit with their command) | Analyzer works from durable windows |
| Audit history and lifecycle events | PostgreSQL | Lifecycle delivery originates from the outbox |