There’s a pattern in enterprise AI adoption that we’ve watched repeat itself over the last two years.
A team needs AI in their workflow. They add an API call to an LLM. They route the response back into their process. It works. Then someone needs the AI to take action — not just reply, but actually do something: query a database, send an approval notification, trigger a sub-process. The LLM gets wired to a tool. Then another tool. Then the “chatbot” starts needing conversation memory, audit logs, and role-based access control.
Six months later, the team has built half an agent framework — except it grew without a design, and nobody is quite sure where the AI ends and the workflow begins.
That’s what we were trying to avoid when we designed Octopus Engine.
The Distinction That Matters: Choreographic vs. Agentic
Traditional workflow systems are choreographic. They route work based on rules.
IF status = "open" → assign to Team A
IF priority = "high" → escalate
The process completes. The ticket moves. Nobody understood why — only that it matched a condition.
Octopus is agentic. The system employs AI agents that understand context, make decisions, plan multi-step actions, call tools, and explain what they did:
[Before] Traditional Workflow:
User Input
↓
[Router] (rules-based)
↓
[Executor] (predefined steps)
Result: Process completes but nobody understood WHY
[With Octopus] Intelligent Workflow:
User Input + Context (history, domain knowledge)
↓
[AI Agent]
- Reads conversation history
- Retrieves knowledge (RAG)
- Calls LLM: "What should we do?"
- Calls tools based on LLM reasoning
- Decides next step
↓
[Execute Plan]
- Tool calls (confirmed)
- Sub-workflows (if needed)
- Human approval gates (if required)
- Full audit trail
Result: Complete process with reasoning, context, and explainability
This isn’t just a philosophical difference. It changes what the system is capable of and what it costs to maintain.
Agents Are ProcessEngine Nodes — Not Bolted On
The most important architectural decision we made: AI agents are first-class ProcessEngine nodes.
In Octopus, an AI agent is just another executor — like “HTTP Request” or “IF Gate” or “Database Query”. When the workflow engine encounters an AIAgent node, it instantiates an AIAgentExecutor, which loads the full AgentComposite, builds the prompt with conversation context and RAG-retrieved knowledge, calls the LLM, executes any tool calls the LLM requested, and returns structured output back into the workflow.
[Start]
↓
[AI Agent: "Analyze Invoice"]
├─ Input: invoice_data
├─ Agent: invoice-analyzer
└─ Output: analysis_result
↓
[IF: "Issues Found?"]
├─ Yes → [AI Agent: "Generate Report"] → [HTTP: POST /approvals]
└─ No → [HTTP: POST /process]
↓
[End]
That workflow lives in the same XML format as every other BizFirst process. The visual designer supports it. The execution engine traces it. The audit log records every step — including what the AI decided and why.
The AI isn’t a wrapper around the workflow. The workflow is a container that the AI participates in, alongside every other node type.
The Six Core Tenets
When we documented Octopus’s design principles, we landed on six that we treat as non-negotiable:
- Agent-First Design — Agents are primary; orchestration supports them, not the other way around
- Context Preservation — Full conversation history shapes every agent response; context is never discarded casually
- Tool-Aware Reasoning — LLMs receive complete tool definitions; they decide when and how to use them
- Process Integration — AI agents live inside ProcessEngine, not alongside it
- Enterprise-Grade by Default — Security, audit, multi-tenancy, and monitoring are built-in, not add-ons
- Pluggable Architecture — Every component — LLM provider, vector database, storage, tools — can be replaced without touching core logic
The sixth one deserves its own discussion (we’ll write about the plugin architecture separately). But the first five explain why Octopus can handle things a bolt-on AI layer never could: persistent context across a 20-turn conversation, mid-workflow human approval gates, multi-agent chains where each agent’s output feeds the next, and complete traceability from user input to final output.
Why This Matters for Enterprise Finance and HR
BizFirst’s platform targets payroll, compliance, and financial operations — industries where a misfire isn’t just inconvenient. A workflow that routes an invoice to the wrong approval chain, or an AI agent that makes a decision without a traceable reason, is a compliance event.
The agentic model gives us something rules-based routing never could: explainability. Every AgentResponse includes a Reasoning list — the step-by-step chain the agent used to reach its conclusion. That reasoning is persisted. It can be audited. A regulator can ask “why did this payment go to this approver?” and get a full answer from the system’s own records.
We didn’t build Octopus because AI is interesting. We built it because enterprise workflows require AI that can be trusted — and trust requires transparency, boundaries, and a clear audit trail.
Interested in how Octopus integrates with our ProcessEngine at the code level, or how the AgentComposite model works? We’ll be posting deeper dives on both. Drop your questions below.
Octopus Engine is part of the BizFirst platform — enterprise workflow automation for finance and HR operations.