Skip to content

Apitomy Axiom 3.0.0

Axiom 3.0 is a new major version that puts workflows at the center. Events from GitHub and Jira flow into a durable event stream; subscriptions match them and start or resume workflow runs; workflows orchestrate action types (AI agents, Bash scripts or Node.js code), SDK calls, human tasks in a new Inbox, waits and event correlation. The new Workflow Workbench lets you build all of this together with an AI assistant.

3.0 is a clean break from 2.x: it cannot use a 2.x database. Read Upgrading from 2.x before installing.

Highlights

  • Workflows. Visual workflow definitions (powered by Apitomy Flow 3.0) with start, end, action, human-task, wait and receive-event nodes, conditional and parallel branches, versions and publishing.
  • Workflow Workbench. An AI-assisted editor for a workflow together with its action types, tools and subscriptions: AI edits arrive as reviewable, undoable change sets; drafts are validated continuously; action types and tools can be test-run from the workbench; publish when ready.
  • Event stream and subscriptions. GitHub and Jira event sources poll into a durable stream; subscriptions filter events with expressions and start workflows or deliver events to waiting runs, with retries and a full processing audit trail.
  • Runs. A runs list as the landing page, run detail with a live diagram, timeline, trace and lineage, re-run of failed runs, and running a workflow by hand from any stream event.
  • Inbox. Human-task nodes create tasks with structured forms; workflows wait for the answer.
  • Dashboards, tracing and lineage. Custom dashboards, end-to-end trace IDs, correlation IDs in logs, and a lineage view connecting events, runs, tasks, traces and AI usage.
  • Multiple AI engines. Claude Code, OpenCode and the GitHub Copilot CLI, side by side.

New Features

Workflows

  • Workflow definitions with a visual editor, version history with diffs, publishing, and import/export in configuration packs (Components → Workflows).
  • Node types:
  • start, end;
  • action: runs an action type, or calls an Axiom SDK function directly (sdk:<function>);
  • human-task: creates an Inbox task with a form and waits for the answer;
  • wait: pauses for an ISO-8601 duration;
  • receive-event: waits for a matching stream event, with correlation keys, match conditions, output mappings, look-back for events that arrived earlier, and a timeout.
  • Conditional edges (expressions over the run context) and parallel fork/join.
  • Standard inputs. A workflow's Start node declares which standard inputs a run receives: subject (the subject's id, name, type, ref, refSource, repository) and event (the triggering event). A run whose required inputs are not available is not created. Expressions read context.subject.<field> and context.event.<field>.
  • Validation at publish and while editing, including a warning when a node output would overwrite a workflow input.
  • Schedule triggers: run a workflow on a cron schedule against a fixed subject.
  • One active run per subject and workflow; duplicate starts are rejected (manual) or skipped and recorded (subscriptions and schedules).
  • SDK functions, including new axiom_create_subject, axiom_update_subject_body, axiom_list_agents, axiom_list_subject_runs, axiom_get_workflow_run and axiom_set_workflow_run_title.

Workflow Workbench

  • Workbench page listing compositions; each composition is a workflow plus its action types, tools and subscriptions, edited as server-side drafts with revision history and restore.
  • AI assistant bound to the composition: it edits the workflow through change sets that are highlighted on the canvas and can be undone per turn; it can read stream events, evaluate expressions against them, preview subscription filters, analyse runs and traces, and suggest tests.
  • Live validation with "Ask AI to fix this" and "Ask AI about this…" actions.
  • Test-run node and script action types and tools with sample inputs (Tests panel); runs of the published workflow with "Ask AI to analyze" (Runs panel).
  • Subscriptions in compositions. Start the workflow (create-workflow) or feed its receive-event nodes (workflow-dispatch). A matching-events preview shows which recent events a filter matches. Publishing never turns automation on: subscriptions are published disabled and enabled with an explicit Enabled switch.
  • Dependency-aware publishing with conflict detection, and engine/model selection per composition.

Runs

  • Runs list (the landing page) with filter chips for status, workflow, subject and labels.
  • Run detail: diagram with the current node, overview (subject, workflow, inputs, labels, trigger event), step timeline, execution trace and lineage.
  • Re-run a failed run with the latest published version of its workflow.
  • Run workflow… from any event in the event stream, with suggested workflows, an optional title and labels.
  • Optional run titles, set when starting a run or by the workflow itself (axiom_set_workflow_run_title).
  • Cancel running and waiting runs.

Events

  • Event sources for GitHub (Repository Events API) and Jira (JQL and changelog) poll into a durable event stream, with poll logs and status.
  • Event Stream page: filter by type and actor, live updates, and an event detail page with the processing audit trail, routing outcomes, started runs and lineage.
  • Subscriptions with expression filters, a live preview against recent events (including evaluation errors), routing rules (create-workflow, workflow-dispatch) and a "process events from" time.
  • Failed event processing is retried with backoff and can be retried by hand.
  • Expression evaluator for authoring (POST /expressions/evaluate), with the same scopes and context (context.subject, context.event) as a real run, including subscription filters.

Action types and tools

  • Node.js execution mode: an ES module exporting run(inputs, ctx).
  • Declared, typed inputs and outputs, validated when a workflow is published and when the task runs; workflow nodes map every required input explicitly; {{inputs.<name>}} is the only template placeholder.
  • Per-action-type step and budget limits, timeouts and labels.

AI assistant and engines

  • Session templates and a subject-scoped assistant; auto-approval rules, subagent views, stop/interrupt, todo and thinking display, cost and token totals.
  • The configuration assistant validates its drafts and previews workflows, subscriptions and event sources before applying them.
  • Claude Code, OpenCode (as a full interactive assistant engine) and the GitHub Copilot CLI can be used at the same time; per-engine settings in Settings → Engine.

Observability and operations

  • Custom dashboards with tabs and widgets.
  • Trace IDs across activity, AI usage, tasks and runs; correlation IDs in server logs; a lineage API and panel.
  • AI usage records the engine and the exact model.
  • Data retention settings for events, traces, runs and inactive subjects.
  • Dark mode.

Breaking Changes

Secrets are no longer injected automatically

In 2.x every secret was passed to every agent and script that did not configure its own environment. In 3.0 a process gets only the variables its environment declares:

  • Declare each secret an action type (or a tool it allows) needs in the action type's Environment, for example GH_TOKEN=${secret:GH_TOKEN}; the Add secret picker fills this in. Session templates have their own Environment.
  • A reference to a secret that does not exist fails the task, test run or session instead of passing the literal ${secret:NAME} text.
  • Validation warns when a script, Node.js code or a tool uses a secret ($GH_TOKEN, process.env.GH_TOKEN) that is not declared.

This keeps credentials away from code and agents that do not need them, and limits what a prompt-injected agent could reveal.

Removed features

  • Reports and report definitions, including their pages, REST endpoints, SDK functions (axiom_list_reports, axiom_list_report_definitions, axiom_add_report_label, axiom_remove_report_label) and the reportDefinitions section of configuration packs.
  • The AI Manager: its pages, /manager/** endpoints and escalations. Workflows replace manager-driven routing.
  • Projects and their open/close lifecycle, replaced by subjects (see below).
  • Invoking action types directly: manual task creation, the free-form task response endpoint, the invoke-action routing type and the SDK function axiom_create_task. Action types run only from workflow action nodes; human input goes through Inbox tasks.
  • The 2.x event pipeline (/events, the event queue and the Events log page), replaced by the event stream, subscriptions and poll logs.
  • AI edit endpoints and per-editor AI assistants for action types and tools, replaced by the Workflow Workbench.
  • The fixed home dashboard: / now opens the Runs list; dashboards are user-defined.
  • Action type flags userTriggerable, managerTriggerable, emitsEvent and the free-form inputSchema, replaced by declared inputs and outputs.
  • Legacy template placeholders ({{input}}, {{ref}}, {{repository}}, {{subjectName}}, {{subjectId}}, {{eventId}}, {{actionType}}, {{workDir}}, {{apiBaseUrl}}, {{taskId}}) and the ambient AXIOM_SUBJECT_* environment variables. Use {{inputs.<name>}} and map values from the workflow.

Renamed concepts and API changes

  • Projects → Subjects: /projects/** → /subjects/**; projectId → subjectId in tasks, thread entries, activity, AI usage and traces. A subject's description is now a Markdown body.
  • Actors → Agents: /actors/** → /agents/**; Task.assignedActor → assignedAgent; AiUsage.actorId → agentId.
  • System configuration: SystemConfig.engine is removed; use defaultEngine and engines.
  • SDK: *_project* functions are renamed to *_subject*; axiom_close_project, axiom_reopen_project and axiom_list_actors are removed (use axiom_list_agents).
  • Configuration packs are format version 3.0. 2.x packs are not expected to import cleanly.
  • Navigation is reorganized: Runs, Subjects, Inbox, Dashboards, Events, Workbench, Logs, Metrics, Components and Settings.

Configuration properties

2.x property 3.0 property
axiom.ai-engine axiom.agent.default-type
axiom.claude-code.* axiom.agent.claude-code.* (max-turns → max-steps)
axiom.opencode.* axiom.agent.opencode.*
axiom.manager.*, axiom.reports.*, axiom.github.poll-interval, axiom.pipeline.poll-interval removed

New properties include axiom.home (default ~/.axiom; workspaces, sessions, installed MCP servers and the encryption key live under it), axiom.agent.copilot.*, axiom.assistant.*, axiom.stream-pipeline.* and axiom.workflow.*.

Upgrading from 2.x

Axiom 3.0 starts from a new database schema and cannot use a 2.x database. If it finds one, it refuses to start and tells you to remove it. No 2.x data is migrated (projects, reports, events, tasks and manager configuration are not carried over).

  1. Stop Axiom 2.x.
  2. Back up ~/.axiom if you want to keep the old data.
  3. Delete ~/.axiom/data/.
  4. Install and start Axiom 3.0.0. It creates a new database.
  5. Recreate your configuration: secrets, event sources, action types, tools, workflows and subscriptions. The Workflow Workbench is the quickest way to rebuild automation as workflows. Declare the secrets each action type needs in its Environment (see Secrets).

From 3.0.0 on, schema changes ship as incremental migrations that are applied automatically at startup.

Requirements

  • Java 25.
  • Node.js on the PATH (Axiom runs its MCP tool servers and Node.js action types with it).
  • At least one AI engine CLI for agent work: Claude Code, OpenCode or the GitHub Copilot CLI.
  • Start with java -jar apitomy-axiom-3.0.0.jar; the UI and API are served on http://localhost:9191.

Known Limitations

  • No authentication. Axiom is intended for local, single-user use. The release build listens on 127.0.0.1 only; if you set quarkus.http.host to accept connections from other machines, protect access yourself (for example behind an authenticating reverse proxy).
  • The Workflow Workbench cannot test a draft workflow end to end; test action types and tools individually and run the published workflow (#469).
  • The workbench cannot delete or disable published items (except enabling and disabling its subscriptions), and existing subscriptions cannot be added to a composition.
  • Retrying failed event routing re-runs rules that already succeeded (#341).
  • Jira polling can skip changes when ingestion fails part-way (#342).
  • Tasks interrupted by a restart are not resumed (#343).
  • Workflow scripts and Node.js actions enforce their timeout, but the Tools page's tool test and a few setup commands can run past theirs, and process output is not size-limited (#344).
  • Schedule triggers assume a single Axiom instance.

Notable Fixes

  • Deleting a subject workspace never follows symbolic links out of the workspace (#340).
  • Scripts always run in the subject workspace; placeholder substitution is quoting-aware; stderr is captured separately.
  • Inbox tasks complete correctly after a server restart.
  • Cleanup jobs retry on database deadlocks; orphaned processing entries are recovered at startup.
  • GitHub and Jira pollers use HTTP timeouts and shut down cleanly.
  • "Process events from" compares the event's own timestamp.
  • Orphaned and incomplete traces are closed; retention leaves no dangling references.
  • Invalid requests return 400 instead of 500 across several endpoints.
  • AI assistant: correct cumulative session cost, interruption without killing the process, subagent permission routing, and better chat performance in long conversations.