System Architecture

How Jinba Flow components work together

Jinba Flow consists of four main components that work together to enable workflow automation.

Component Overview

Flow Editor

Visual interface for creating workflows using Chat, Graph, or YAML

Manifest

YAML representation of your workflow definition

Runner

Execution engine that processes manifests and runs steps

API / MCP

External interfaces for triggering and integrating workflows

Data Flow

Component Details

1. Flow Editor (Design Time)

The Flow Editor provides three methods to create workflows:

Method	Interface	Best For
Chat Panel	Natural language	Quick prototyping, non-technical users
Graph Editor	Visual drag-and-drop	Understanding flow structure
YAML Panel	Direct code editing	Precise control, version control

All three methods produce the same output: a Manifest.

2. Manifest (Bridge)

The Manifest is a YAML document that defines your workflow:

steps:
  - id: step_id
    tool: TOOL_NAME
    input:
      - name: param
        value: "{{reference}}"
    needs: [dependency_step]
    when: "condition"
    forEach: "{{collection}}"

Field	Purpose
id	Unique identifier for the step
tool	The tool to execute
input	Parameters passed to the tool
needs	Dependencies on other steps
when	Conditional execution
forEach	Loop over a collection

3. Runner (Execution Time)

The Runner interprets manifests and executes workflows:

1. Parse

   Load and validate the manifest YAML

2. Resolve

   Build dependency graph from needs fields

3. Execute

   Run steps in topological order, parallelizing when possible

4. Handle

   Manage errors, retries, and conditional skips

5. Return

   Collect results and return to caller

Key Capabilities:

• Parallel execution of independent steps
• Variable resolution ({{steps.*.result}})
• Credential injection from workspace secrets
• Timeout and retry management

4. API / MCP (Deployment)

Published workflows expose two integration interfaces:

Interface	Endpoint	Use Case
REST API	POST /api/v2/external/flows/{flowId}/published-run	Programmatic integration
MCP Server	Model Context Protocol	AI agent tools

Authentication:

• API Key required for all external calls
• Keys scoped to workspace
• Rate limiting applied

Execution Flow

1. Trigger

   API call, schedule, MCP invocation, or manual run starts execution

2. Load

   Runner loads the published manifest version

3. Validate

   Input parameters validated against defined schema

4. Execute

   Steps run according to dependency graph

5. Return

   Results returned via API response or MCP result

Security Boundaries

Boundary	Protection
Editor → Manifest	Schema validation prevents invalid YAML
API → Runner	API key authentication required
Runner → Tools	Credential isolation per workspace
Runner → External	Secure sandbox execution environment

Workspace Isolation

Each workspace maintains:

• Credentials: API keys and OAuth tokens
• Flows: Workflow definitions
• Versions: Published snapshots
• Execution History: Run logs and artifacts

Workspaces are completely isolated from each other.

What’s Next?

Execution Model

Deep dive into how steps execute

API Reference

Learn about API endpoints