Flow Component

A Flow is a standalone executable component that represents a workflow as an explicit graph. It defines the values accepted from the caller, the values
returned at completion, the nodes that perform work, and the connections that describe execution paths and transfer data.

A Flow is appropriate when its permitted operations and transitions are defined in advance. Explicit control-flow edges describe which nodes can execute after each node, while explicit data-flow edges describe how named values move between nodes. JSON member order, matching names, and model-generated instructions do not define these relationships.

Flow Fields

Field	Requirement	Description
component_type	Required	Identifies the component as a Flow.
id	Required	Uniquely identifies the Flow for symbolic references.
name	Required	Provides a human-readable component name.
inputs	Optional	Declares the named, typed values accepted when the Flow begins.
outputs	Optional	Declares the named, typed values returned when a path completes.
start_node	Required	Identifies the StartNode at which execution begins.
nodes	Required	Identifies the nodes that belong to the Flow graph.
control_flow_connections	Required	Describes the possible execution paths between nodes.
data_flow_connections	Optional	Transfers named output values to named inputs.
$referenced_components	Optional	Contains definitions referenced within the Flow's component scope.

A Flow contains exactly one StartNode and at least one EndNode. The start_node field must identify the StartNode included in nodes.

How a Flow Executes

Flow execution follows the structure declared in the graph:

1. Oracle AI Database Agent Engine validates the Flow contract, nodes, references, and connections.
2. Caller-supplied values become available through the StartNode outputs.
3. Execution begins at the StartNode.
4. When a node completes, its applicable outgoing control-flow connections identify the nodes that can execute next.
5. Data-flow connections transfer named output values to the declared inputs of their destination nodes.
6. A node executes after control reaches it and its required input values are available.
7. An EndNode completes the path and maps its values to the Flow output contract.

Control flow and data flow remain independent. A control-flow connection can identify a possible next node without supplying its input values. A data-flow connection can make a value available without causing the destination node to execute.

Graph-Defined Control

The Flow graph defines the set of execution paths that Oracle AI Database Agent Engine can follow. The applicable continuation depends on the declared control-flow connections and the behavior of the current node.

This applies to different Flow structures:

• For a node with exactly one outgoing control-flow connection, that connection identifies its only possible next node.
• A BranchingNode selects one of its declared branches. The outgoing control-flow connection with the matching from_branch identifies the applicable continuation.
• A MapNode applies the same declared subflow to the items in a collection.
• A parallel node executes every declared independent arm. The order in which the arms begin or complete is not deterministic.
• A FlowNode executes a referenced subflow through the FlowNode's declared input and output boundary.

Graph-defined control does not mean that every operation returns the same business value. A model response, external service, database state, or Tool result can vary. The Flow still constrains how that result is received, which declared continuations can follow it, and how execution can complete.

For example, a model response cannot introduce an undeclared destination node. A BranchingNode can select only a branch represented by its mapping, declared branches, and outgoing control-flow connections.

Advantages of a Flow

Advantage	Description
Explicit execution paths	The graph shows which operations can execute and how each path completes.
Typed component boundaries	Named input and output contracts make value movement explicit. Oracle AI Database Agent Engine validates type compatibility when it parses the Agent Spec and when values cross supported execution boundaries.
Controlled model and Tool placement	Model and Tool invocations occur at declared positions in the graph.
Separate control and data movement	Possible execution paths remain distinct from the values consumed by each node.
Composition and reuse	FlowNode and AgentNode contracts allow an enclosing Flow to target declared inputs and outputs without referring to the internal definitions of the reused Flow or Agent.
Repeatable structure	The same validated graph governs each execution even when input values and operation results change.

These properties make a Flow appropriate for business workflows whose execution paths, data contracts, and completion conditions must remain
inspectable. Oracle AI Database Agent Engine also enforces the declared graph, references, and supported type contracts during validation and execution.

Example: Route an Order Return

Consider an online store that receives an order identifier and a return reason. The Flow checks whether the order is eligible for return and then selects one of two declared branches. The eligible branch creates the return and returns a confirmation. The not-eligible branch skips return creation and returns the reason that the request was declined.

Description of the illustration Conditional Flow for Return Eligibility

The branching decision selects one branch. The eligible control-flow continuation includes create-return; the not-eligible continuation bypasses that node. These data-flow connections make values available to their consumers. They do not select either branch.

Execution Walkthrough

1. The caller supplies order_id and return_reason through the Flow input contract.
2. The StartNode exposes both values as named outputs.
3. Data-flow connections supply those values to the eligibility-check ToolNode.
4. When control reaches that ToolNode, it invokes the declared eligibility Tool and publishes decision and explanation.
5. A data-flow connection supplies decision to the BranchingNode.
6. For eligible, the BranchingNode selects the branch leading to the return-creation ToolNode. That node receives order_id, creates the return, and supplies its confirmation to the approved EndNode.
7. For not_eligible, execution follows the branch leading directly to the declined EndNode. The eligibility explanation becomes the Flow result, and the return-creation ToolNode does not execute.
8. The reached EndNode maps its values to the Flow output contract.

The eligibility Tool can return different decisions as order data changes. The Flow remains structurally constrained because either decision can lead
only to its declared branch. The not-eligible branch cannot create a return, and the eligible branch cannot bypass the declared return-creation operation.

Flow Node Topics

The pages in this chapter present focused component fragments from an online order-support scenario. These fragments are independent examples and do not form a single complete or progressively constructed Flow.

Page	Business question answered
StartNode	How does the request enter the graph?
EndNode	How does a completed path return a response?
ToolNode	How does the Flow invoke an order-status Tool?
LlmNode	How does one model invocation summarize a customer request?
BranchingNode	How does the Flow select a support branch?
AgentNode	How does an Agent participate in a Flow?
FlowNode	How does a subflow participate in an enclosing Flow?
MapNode	How does the same subflow process several order IDs?
Parallelism	How does independent order work run concurrently?
End-to-End Workflow Example	How do selected node types fit into one larger Flow?