COMPLETE TEARDOWN

Seven architectures.
One agentic spectrum.

Data Agents, Execution Backbones, and Substrate Governance - each tackles agentic workflows from a distinct angle. Understand the patterns once, and the confusion disappears.

🤖 Oracle DS 📊 Julius AI 🔍 DeepAnalyze ⚡ Agno ⚙️ Airflow 🚀 Hermes 🛡️ Omnigent
THE TAXONOMY

How these systems differ

Think of it as a spectrum. At one end, you have conversational data agents that orchestrate classical ML. In the middle, frameworks that compile LLM plans into deterministic execution DAGs. At the far end, governance layers that police the boundaries of fully autonomous sub-agents.

1. Oracle Data Science Agent

Tier A: Data Agent

Conversational, in-database data-science agent inside Oracle Autonomous AI Database 26ai (Oracle Machine Learning). Covers the full lifecycle - profile → feature-engineer → train → validate → explain - without moving data out of the database.

Architecture & Components Workflow Diagram
flowchart LR U(["User query"]) --> UND["Understand + clarify
(LLM)"] UND --> PLAN["Plan lifecycle
(LLM)"] PLAN --> EXEC["In-DB: profile → engineer → train
(no-LLM, classical ML)"] EXEC --> EXP["Explain results
(LLM)"] EXP -->|refine| UND EXP --> OUT(["Insights"]) classDef llm fill:#f0f6ff,stroke:#0071e3,color:#0071e3 classDef det fill:#f5f5f7,stroke:#e8e8ed,color:#6e6e73 classDef io fill:#ffffff,stroke:#e8e8ed,color:#1d1d1f class U,OUT io class UND,PLAN,EXP llm class EXEC det
Decomposition (Q1)
Lifecycle decomposition - the fixed DS skeleton (profile → features → train → evaluate → explain) is broken into steps; interactive mode externalizes the plan for the user to validate.
Ordering (Q2)
Determined by the lifecycle order plus the Conversation Objects Catalog scope. The user can validate interactively, then hand the remaining steps to autonomous execution.
State / Memory
Persistent conversation history, logs, and SQL snippets for reproducibility, audit, onboarding, and resuming a project later.
Where AI/LLM is used
The LLM drives the conversational interface, intent parsing, planning, in-DB SQL/code generation, and result explanation. Model training itself is classical in-DB ML, not an LLM.
Fitment
If your "execute the plan" must include model training, this is the strongest commercial proof a conversational planner→executor can own training end-to-end. Copy the interactive→autonomous escalation for your ambiguity stage.
Pros
Genuinely trains+validates models conversationally; data never leaves the DB (governance, security); interactive↔autonomous toggle is a clean ambiguity-resolution pattern.
Cons
Oracle-DB-bound; very new; algorithm set limited to in-DB options; closed/managed.

2. Julius AI

Tier A: Data Agent

Standalone "AI data scientist" chat + notebook product. Writes and runs Python/R, pulls external data, calls external APIs, runs full EDA, and trains ML (PyTorch/TensorFlow) inside one session.

Architecture & Components Workflow Diagram
flowchart LR U(["Prompt + data"]) --> PLAN["Plan / choose action
(LLM)"] PLAN --> GEN["Generate code
(LLM)"] GEN --> EXEC["Execute in sandbox
(no-LLM)"] EXEC --> CHK{"Done?"} CHK -->|"error / more"| GEN CHK -->|done| INT["Interpret + visualize
(LLM)"] INT --> SAVE{"Reuse?"} SAVE -->|"save as Notebook"| REUSE["Persist reusable workflow
(no-LLM)"] SAVE -->|one-off| OUT(["Answer"]) REUSE --> OUT classDef llm fill:#f0f6ff,stroke:#0071e3,color:#0071e3 classDef det fill:#f5f5f7,stroke:#e8e8ed,color:#6e6e73 classDef io fill:#ffffff,stroke:#e8e8ed,color:#1d1d1f class U,OUT io class PLAN,GEN,INT llm class EXEC,CHK,SAVE,REUSE det
Decomposition (Q1)
User- or agent-defined step plans / notebook cells. More a guided plan executor than an autonomous decomposer.
Ordering (Q2)
Plan/notebook order, or the agent follows a custom step plan.
State / Memory
Notebooks persist; Custom Agents carry a knowledge base; Scheduled Runs persist analyses; per-user sandboxed storage.
Where AI/LLM is used
LLM plans steps, writes Python/R, and interprets results. Code execution is deterministic; ML training uses libraries (PyTorch/TF), not the LLM.
Fitment
Study Custom Agents + Scheduled Runs as the product shape for "save a plan, parameterize it, re-run it" - i.e. turning a one-off plan into a reusable, schedulable workflow.
Pros
Explicitly covering external APIs + ML training + EDA in one session; R support.
Cons
Chat-first (reasoning can be opaque); credit pricing; not built for hardened multi-agent orchestration.

3. DeepAnalyze-8B

Tier A: Data Agent

Open-source research system from Renmin University - the self-described first agentic LLM for autonomous data science. The architectural opposite of the others: there's no external workflow - the model itself is trained to plan, act, observe, and iterate.

Architecture & Components Workflow Diagram
flowchart TD U["Instruction Q + data environment
(input)"] --> GEN["Model generates next action token
(LLM)"] GEN --> SW{"Which action?
(LLM)"} SW -->|Analyze| AN["Plan, reason, reflect, self-verify
(LLM)"] SW -->|Understand| UN["Inspect data sources
(LLM)"] SW -->|Code| CD["Generate Python code
(LLM)"] SW -->|Answer| ANS["Produce final analyst-grade report
(LLM)"] AN --> GEN UN --> GEN CD --> EXq["Execute code in environment
(no-LLM)"] EXq --> FB["Collect feedback, append to trajectory
(no-LLM)"] FB --> GEN ANS --> OUT["Output A with full interaction process
(output)"] classDef llm fill:#f0f6ff,stroke:#0071e3,color:#0071e3 classDef det fill:#f5f5f7,stroke:#e8e8ed,color:#6e6e73 classDef io fill:#ffffff,stroke:#e8e8ed,color:#1d1d1f class U,OUT io class GEN,SW,AN,UN,CD,ANS llm class EXq,FB det
Decomposition (Q1)
Fully autonomous planning done directly by the LLM using the <Analyze> token.
Ordering (Q2)
Dynamic runtime ordering decided solely by the model's next generated token.
State / Memory
In-context memory within the prompt window, storing execution feedback and intermediate steps across ~30 reasoning rounds.
Where AI/LLM is used
Everywhere except the pure Python execution block. The LLM controls the entire loop autonomously via extended vocabulary tokens.
Pros
Truly autonomous workflow built into the model weights; no complex external orchestration code needed. Open-source.
Cons
Highly dependent on context window limits; harder to govern or inject deterministic guardrails into the loop.

4. Agno Dash

Tier A: Data Agent

Open-source (built on the Agno framework) self-learning data agent, explicitly modeled on OpenAI's internal data agent. The cleanest open codebase that separates planning (a Leader) from execution (Analyst/Engineer specialists) and persists corrections as reusable learnings. Runs in Slack, terminal, or the AgentOS web UI over PostgreSQL.

Architecture & Components
  • Team (coordinate mode): Leader coordinates + answers; Analyst introspects schema and writes read-only SQL on the public (company) schema; Engineer builds reusable views in the agent-managed dash schema.
  • 6 layers of context: (1) schema/relationships, (2) human annotations, (3) proven SQL patterns, (4) institutional knowledge, (5) machine-discovered error patterns, (6) live runtime introspection. Retrieved via PgVector hybrid search.
  • Self-learning: success → save validated query as Knowledge; failure → Agno Learning Machine diagnoses, fixes, and saves a Learning so the mistake isn't repeated.
  • Guardrails (infrastructure, not prompts): Analyst connects with default_transaction_read_only=on; Engineer writes scoped to dash schema.
Workflow Diagram
flowchart LR U(["Question"]) --> LEAD["Leader routes
(LLM)"] LEAD -->|"data question (default)"| ANA["Retrieve context + Analyst SQL
(mixed)"] LEAD -->|"explicit: create a view"| ENG["Engineer builds dash view
(LLM)"] ANA --> RUN["Execute SQL
(no-LLM)"] RUN -->|"error: learn + retry"| ANA RUN --> INT["Synthesize insight
(LLM)"] ENG --> INT INT --> OUT(["Insight"]) ANA -.->|"repeated pattern, user-approved"| ENG ENG -.->|"reused next time"| ANA classDef llm fill:#f0f6ff,stroke:#0071e3,color:#0071e3 classDef det fill:#f5f5f7,stroke:#e8e8ed,color:#6e6e73 classDef mixed fill:#f5f3ff,stroke:#6d28d9,color:#6d28d9 classDef io fill:#ffffff,stroke:#e8e8ed,color:#1d1d1f class U,OUT io class LEAD,INT,ENG llm class RUN det class ANA mixed
Decomposition (Q1)
The Leader routes each question to the Analyst by default, and separately triggers the Engineer to build a reusable asset when it detects a recurring pattern across queries.
Ordering (Q2)
The Leader sequences; the standout is the self-learning loop — failed steps become permanent learnings (replanning memory that compounds over time).
State / Memory
PostgreSQL holds Knowledge (curated/validated) and Learnings (discovered); sessions/traces live in AgentOS. Memory is the context layer, not model weights.
Where AI/LLM is used
LLM reasons about intent, generates grounded SQL, and diagnoses/fixes errors. SQL execution, read-only enforcement, and schema isolation are deterministic infrastructure.
Fitment
Read this to copy two things directly: planner/executor separation and a replanning loop that persists corrections as reusable learnings. Plus the idea that data-access guardrails belong in infrastructure, not in prompts.
Pros
Clear planner/executor separation; concrete replanning-as-memory pattern; DB-level guardrails.
Cons
Postgres-centric; tightly coupled to Agno; steep context-curation setup.

5. Airflow 3 + Astronomer Otto

Tier B: Execution Backbone

The execution backbone, not a data planner. Apache Airflow 3 is the deterministic orchestrator (DAGs, scheduling, retries, HITL); the Common AI Provider lets you put LLM and agent calls inside DAGs as named, logged, retryable tasks; Astronomer Otto is a data-engineering agent that authors DAGs.

Architecture & Components
  • Airflow 3 engine — DAG versioning, event-driven scheduling, human-in-the-loop operators, remote execution.
  • Common AI Provider — built on Pydantic AI; decorators @task.llm, @task.agent, @task.llm_branch; AIBudget cost caps per task/DAG/team.
  • Astronomer Otto — reads task logs, traces dependency chains, checks run history; returns root cause + proposed fix; produces fleet-wide upgrade plans.
  • astronomer/agents plugin — Airflow MCP server + installable skills for coding agents.
Workflow Diagram
flowchart LR NL(["NL request"]) --> AUTH["Author: Otto / human writes DAG
(LLM, build-time)"] AUTH --> DAG["DAG: tasks + dependencies
(no-LLM)"] DAG --> RUN["Scheduler runs tasks; retries + HITL
(no-LLM)"] RUN -.->|"@task.llm / @task.agent"| AI["LLM task
(LLM)"] RUN --> OUT(["Outputs + logs"]) classDef llm fill:#f0f6ff,stroke:#0071e3,color:#0071e3 classDef det fill:#f5f5f7,stroke:#e8e8ed,color:#6e6e73 classDef mixed fill:#f5f3ff,stroke:#6d28d9,color:#6d28d9 classDef io fill:#ffffff,stroke:#e8e8ed,color:#1d1d1f class NL,OUT io class AUTH,AI llm class DAG,RUN det
Decomposition (Q1)
Not an autonomous NL decomposer at the engine level — you or an authoring agent (Otto) define tasks. Within a DAG, @task.agent can decompose its own sub-steps over tools.
Ordering (Q2)
The DAG is the ordering — explicit dependencies, retries, event triggers, parallelism. This is the deterministic ordering layer your emergent LLM plan should compile down to.
State / Memory
XComs + metadata DB for run state and full agent/LLM logs; Otto Memory in git for team conventions and corrections.
Where AI/LLM is used
The core engine has no LLM. LLMs enter only through AI-SDK tasks you add, and Otto (DAG authoring, failure diagnosis). Scheduling and retries are deterministic.
Fitment
Strong candidate for the layer that runs your generated plan. The pattern: planner LLM emits a plan → materialize it as an Airflow DAG → inherit retries, observability, HITL, and per-task cost caps.
Pros
Mature, deterministic ordering + retries + observability + HITL; AI now native (typed outputs, cost caps, per-task logging).
Cons
Heavy if self-hosted; not designed to decompose NL on its own; Otto is Astro-tied.

6. Hermes Agent (Nous Research)

Tier C: Substrate Governance

Open-source (MIT) general-purpose personal agent by Nous Research. Not a data-analytics product, but its substrate mechanisms (subagent delegation, persistent skill-memory, multi-backend sandboxing, multi-model routing) are exactly the pieces your build needs underneath the data layer.

Architecture & Components
  • Multi-surface, one memory — Telegram, Discord, Slack, CLI; a single agent + shared memory across every surface.
  • Persistent memory + auto-generated skills — learns your projects, auto-generates reusable skills.
  • Subagent delegation — isolated subagents, each with its own conversation, terminal, and Python RPC scripts.
  • Isolated sandboxing — five backends (local, Docker, SSH, Singularity, Modal) with container hardening + namespace isolation.
Workflow Diagram
flowchart LR U(["Message"]) --> CORE["Reason + plan
(LLM)"] CORE --> ACT["Tools / subagents
(mixed)"] ACT --> SBX["Execute in sandbox
(no-LLM)"] SBX -->|loop| CORE CORE -->|done| MEM["Update memory + respond
(mixed)"] MEM --> OUT(["Reply"]) classDef llm fill:#f0f6ff,stroke:#0071e3,color:#0071e3 classDef det fill:#f5f5f7,stroke:#e8e8ed,color:#6e6e73 classDef mixed fill:#f5f3ff,stroke:#6d28d9,color:#6d28d9 classDef io fill:#ffffff,stroke:#e8e8ed,color:#1d1d1f class U,OUT io class CORE llm class SBX det class ACT,MEM mixed
Decomposition (Q1)
Subagent delegation — the parent decomposes work and spawns isolated children (supervisor-style), each with its own context/terminal/RPC.
Ordering (Q2)
LLM-driven within a session; NL scheduling sequences unattended runs. No deterministic/symbolic planner.
State / Memory
The standout — persistent cross-surface memory plus auto-generated skills that accumulate as reusable capabilities.
Where AI/LLM is used
LLM-driven throughout (planning, subagent reasoning, tool/browser use, skill generation), with multi-model routing across many models.
Fitment
Not your data planner, but a useful reference (possibly a base) for the execution substrate — specifically its subagent-with-own-terminal-and-RPC delegation, its auto-generated skills memory, and its five-backend sandboxing.
Pros
Open MIT; strong on the substrate concerns you'll hit anyway — subagent isolation, multi-backend sandboxing, multi-model routing.
Cons
General-purpose — no data semantic layer, no warehouse-native governance, no EDA specialization; planning is LLM-emergent.

7. Omnigent (Databricks)

Tier C: Substrate Governance

Open-source (Apache 2.0), alpha meta-harness from Databricks — a layer above coding agents (Claude Code, Cursor, custom) for composition, control, and collaboration. Not a data agent: it doesn't decompose or order data tasks; it governs the agents that do.

Architecture & Components
  • Runner + server split — a runner wraps any agent in a sandboxed session; a server provides policies + sharing.
  • Uniform API — swap Claude Code ↔ Codex ↔ Cursor ↔ Pi with one-line changes; compose multiple harnesses via YAML.
  • Stateful contextual policies — enforce cost budgets and permissions at the meta-harness layer (not via prompts).
  • Omnibox OS sandbox — locks down filesystem access and intercepts/transforms network requests with kernel-level enforcement.
  • Live collaboration — share a running session via URL; teammates see messages, subagents, terminals, and files in sync.
Workflow Diagram
flowchart LR U(["Task"]) --> HARNESS["Select harness + policies
(no-LLM)"] HARNESS --> SBX["Omnibox sandbox
(no-LLM)"] SBX --> AGENT["Wrapped agent runs
(LLM)"] AGENT --> CHK{"Policy OK?"} CHK -->|violation| HARNESS CHK -->|ok| OUT(["Result"]) classDef llm fill:#f0f6ff,stroke:#0071e3,color:#0071e3 classDef det fill:#f5f5f7,stroke:#e8e8ed,color:#6e6e73 classDef mixed fill:#f5f3ff,stroke:#6d28d9,color:#6d28d9 classDef io fill:#ffffff,stroke:#e8e8ed,color:#1d1d1f class U,OUT io class AGENT llm class HARNESS,SBX,CHK det
Decomposition (Q1) / Ordering (Q2)
Neither — it composes and governs sub-agents; the wrapped agents do any decomposition/ordering.
State / Memory
Per-session sandbox state; policy state is stateful/contextual across the session.
Where AI/LLM is used
Omnigent itself calls no LLM for data work — it wraps agents that bring their own models. Its policy/budget/sandbox logic is deterministic infrastructure.
Fitment
Only relevant if your executor spawns multiple specialized sub-agents and you need cost/permission guardrails + sandboxing + collaboration across them. Conceptual peers: LangGraph supervisor graphs, CrewAI, AutoGen.
Pros
Clean control plane — swap models/harnesses, enforce cost/permission limits, sandbox OS access, collaborate live; open Apache 2.0.
Cons
Alpha — enterprise RBAC/identity are on the roadmap; irrelevant unless you're running multiple agents; not a data tool.

8. Side-by-side & What to borrow

System Tier Decomposition (Q1) Ordering (Q2) Trains models? Standout to steal
Oracle DS Agent A Lifecycle skeleton Lifecycle + scope catalog Yes (classical, in-DB) Interactive→autonomous escalation
Julius AI A Notebook/agent step plan Plan/notebook order Yes (PyTorch/TF) Save-plan-as-reusable-workflow
DeepAnalyze-8B A In-model <Analyze> Autoregressive act→observe Yes (end-to-end) Forced execute-after-code; trainable planner
Agno Dash A Leader delegates Leader + self-learning loop No (SQL) Planner/executor split + learnings-as-memory
Airflow 3 / Otto B DAG / @task.agent DAG dependency graph Orchestrates Compile the plan to a DAG; per-task cost caps
Hermes Agent C Subagent delegation LLM-driven + scheduling No (general) Subagent-with-RPC isolation; auto-generated skills
Omnigent C n/a (governs) n/a (policies) n/a Cost/permission policies + OS sandbox over multiple agents
The composite blueprint these seven imply for your build:
  • Planner/executor separation with the planner emitting typed subtasks — Agno Leader, Genie supervisor.
  • Interactive→autonomous intent/ambiguity handling — Oracle.
  • Reusable, parameterized, schedulable plans — Julius notebooks, Airflow DAGs.
  • Forced act→observe + reflection loops for reliability — DeepAnalyze, Agno.
  • Compile the emergent LLM plan to a deterministic DAG for ordering, retries, HITL, and per-task cost caps — Airflow 3.
  • Persist corrections as first-class, versioned memory (learnings/skills) so the system improves without retraining — Agno, Otto, Hermes.
  • Reserve the LLM for reasoning/codegen; keep execution, model-training, scheduling, and guardrails deterministic — every system here draws this boundary.
  • Add a meta-harness only if you go multi-agent — Omnigent / LangGraph.