5.3 Runtime

The Synaptika Runtime is the first derivative product built on the protocol. It consumes VPIs in the same way any third-party application would -- through the standard API, with no privileged protocol access.

The Runtime is an AI agent orchestration platform. Where existing workflow tools require users to manually wire together services, triggers, and logic, the Runtime lets users describe what they want in natural language, then assembles the agents, services, and infrastructure automatically. It can do this because every workflow step maps to a VPI provisioned from the Synaptika network, giving the Runtime access to a globally distributed pool of inference capacity without requiring users to manage GPUs, configure infrastructure, or commit to a single provider.

Who Is This Product For?

The Runtime serves anyone who would use a workflow automation tool but prefers to prompt instead of build. Rather than dragging nodes onto a canvas and wiring them together manually, users describe their desired outcome and the Runtime decomposes it into tasks, identifies the required services, and executes across the network.

This includes operations teams automating business processes across tools like Gmail, Slack, CRMs, and databases; founders and small teams who need powerful automation without dedicated engineering resources; and anyone already using N8N, Zapier, or Make who has hit the ceiling of what manual workflow construction can achieve.

Workflows

The core abstraction of the Runtime is the Workflow -- a composable, stateful sequence of AI operations that can be created, managed, and executed against one or more VPIs.

Creating a Workflow

Users describe a goal -- "every morning, summarize my unread emails, draft responses to anything urgent, and post a digest to Slack" -- and the Runtime decomposes it into a directed graph of tasks: model calls, service integrations, data transformations. Each step is bound to one or more VPIs from the network. Users see the estimated cost of a workflow before it runs.

A workflow definition includes the VPI(s) to execute against, the sequence of operations and their dependencies, input/output schemas for each step, and retry policies, timeout thresholds, and fallback behavior. These are assembled by the Runtime from the user's prompt, not configured manually.

Managing a Workflow

Once deployed, workflows are versioned and manageable through the Runtime's control plane. Users can update workflow definitions, roll back to previous versions, and monitor execution metrics in real time. The Runtime maintains an audit trail of all workflow executions, including inputs, outputs, latency, and token consumption.

Running a Workflow

Workflows can be triggered through three execution modes:

Scheduled Workflows: Execute on a defined cadence (e.g., hourly batch summarization, nightly report generation). The Runtime's scheduler manages execution timing and handles retries for failed runs.

On-Demand Workflows: Triggered by an API call or user action. Designed for real-time use cases where a user prompts a workflow and expects immediate execution.

Event-Driven Workflows: Triggered by external events -- a webhook, a message queue event, a file upload, or a state change in an external system. Event-driven workflows enable reactive automation that responds to the world without polling.

Access to Artifacts

Production workflows operate on user data -- documents, databases, APIs, and file stores. The Runtime provides a secure artifact access layer that allows VPIs to interact with user resources without exposing raw credentials to the network.

The artifact access model works through scoped access tokens: the user defines which resources a workflow can access and with what permissions (read-only, read-write, time-bounded). The Runtime issues a scoped access token bound to the specific workflow execution and VPI. The token is automatically revoked upon workflow completion or expiration.

This model ensures that decentralized inference nodes never hold persistent access to user data -- access is always scoped, temporary, and auditable.

Runtime FAQ

<details> <summary>How does the Runtime differ from existing workflow tools like N8N or Zapier?</summary>

The Runtime is purpose-built for AI inference workloads on decentralized infrastructure. Unlike general-purpose orchestrators, it natively understands VPI capacity bindings, token-based billing, inference-specific retry semantics (e.g., model fallback across pools), and the security constraints of executing on untrusted nodes. It uses workflow orchestration primitives internally but exposes an AI-native interface.

</details> <details> <summary>Can I use the Runtime without holding a VPI?</summary>

No. The Runtime is the execution layer for VPI capacity. To run workflows, you must hold or lease VPIs that provide the underlying inference capacity. This creates a direct economic link between Runtime usage and VPI demand.

</details> <details> <summary>What happens if a node fails mid-workflow?</summary>

The Runtime leverages the Pool’s failover mechanics. If a node becomes unresponsive during a workflow step, the Pool redistributes the request to another node. The Runtime handles step-level retries and state recovery, ensuring workflow completion even under node failures.

</details>