Both OSOP and the Oracle Agent Specification are YAML-based, open-source formats for defining AI agent workflows. They occupy similar territory but take fundamentally different approaches. This article breaks down the differences for teams evaluating which format fits their needs.
Overview
Oracle Agent Specification
Released by Oracle under Apache 2.0. Focuses on agent definition — what an agent is, what tools it has, and how tasks form a directed acyclic graph (DAG). Agent-centric: the primary object is the agent, with tasks as a property of the agent. Backed by Oracle, with integration into Oracle Cloud Infrastructure.
OSOP
Defines two complementary formats: .osop for workflow definition and .osoplog for execution records. Focuses on process definition — what should happen, what actually happened, and how to improve. Process-centric: the primary object is the workflow, with agents as one of 16 node types. Independent open standard, runtime-agnostic.
Key Differences
| Dimension | OSOP | Oracle Agent Spec |
|---|---|---|
| Primary focus | Workflow process | Agent definition |
| Format | .osop + .osoplog (two files) | Single agent definition file |
| Execution records | .osoplog captures full history | Not included in spec |
| Node types | 16 types across 4 categories | Tasks with agent/tool types |
| Edge modes | 13 modes | Sequential and conditional |
| Risk analysis | Built-in per-node risk levels | Not included |
| Human-in-the-loop | First-class human node type | Not a primary concept |
| Self-optimization | Compare .osoplog against .osop | Not addressed |
| EU AI Act | .osoplog satisfies Article 19 | Not addressed |
| Visual editor | osop-editor (live) | No public visual tooling |
Execution Records: The Core Differentiator
The most significant difference is that OSOP treats execution records as a first-class part of the standard. The Oracle Agent Spec defines what an agent is and what it should do. After execution, there is no standardized format for recording what happened.
This means every runtime produces different log formats, logs are not portable between tools, auditing requires custom tooling per runtime, and there is no standard way to compare intended vs actual behavior.
OSOP's .osoplog solves this by standardizing the execution record:
osoplog_version: "1.0"
run_id: "a1b2c3d4"
workflow_id: "code-review"
status: "COMPLETED"
duration_ms: 180000
node_records:
- node_id: "ai-review"
status: "COMPLETED"
duration_ms: 95000
ai_metadata:
model: "claude-opus-4-6"
prompt_tokens: 12000
completion_tokens: 2500
tools_used:
- { tool: "Read", calls: 8 }
- { tool: "Grep", calls: 3 }Philosophy: Agent-Centric vs Process-Centric
The Oracle Agent Spec models the world as: agents have capabilities and execute tasks. OSOP models the world as: processes have steps, and agents are one type of step.
The process-centric view is broader. Not every step in a workflow is an AI agent. Many workflows include CI/CD steps, API calls, human gates, timers, webhooks, and data transformations alongside agent steps. OSOP represents all of these natively.
Neither philosophy is inherently better — they serve different needs. If your primary concern is defining individual agents, the Oracle Agent Spec is a natural fit. If your concern is end-to-end processes that include agents alongside other step types, OSOP provides more expressive power.
Interoperability
OSOP plans to build a bidirectional converter between formats via the osop-interop project. The goal is not competition but complementarity. Teams using Oracle Agent Spec can adopt .osoplog for execution records. Teams using OSOP can export agent definitions in Oracle Agent Spec format.
Conclusion
Oracle Agent Spec is the right choice if you need a clean format for defining individual AI agents, especially within the Oracle ecosystem.
OSOP is the right choice if you need end-to-end process definitions that span agents and non-agent steps, with standardized execution records, risk analysis, and regulatory compliance.
The key question is whether execution records should be part of the standard or left to individual runtimes. OSOP argues they should be standardized, because the value of a workflow format compounds when you can compare what was intended against what actually happened.