Core Concepts

These are the fundamental concepts that power Tensorify. Read this page when you want to understand how the pieces fit together.

A workflow is a directed graph of nodes and edges that defines an automation. Workflows:

• are created and edited in the canvas editor at app.tensorify.io
• are compiled to Python by Tensorify at runtime
• are executed by a runner on your infrastructure or by the Tensorify managed executor
• are uniquely identified by a workflow ID (visible in the URL)

Nodes are the steps in a workflow. Each node has a type that determines what it does. There are four categories:

Every workflow must begin with exactly one trigger node.

Edges connect node outputs to node inputs. Data flows through edges as the workflow executes.

Each node produces output variables that downstream nodes can use. For example:

• A Webhook trigger produces a webhook variable containing the full request envelope (body, headers, query, method)
• An HTTP Request node produces an http_request variable with status, data, and headers
• A Code node produces a code variable containing whatever your Python function returns

You reference upstream values in node settings using {{ }} expressions. For example, to pass the webhook body as the HTTP request body, set the body binding to {{ webhook.body }}.

A runner is a long-lived CLI process (tensorify runner start) that connects your machine to Tensorify. One runner can handle multiple workflows — you assign workflows to it from the Deploy dialog in the web app.

Setup flow:

tensorify init
tensorify runner start

While the runner is connected:

• Canvas tests — click Test in the editor; executions run on your machine
• Production triggers — deploy a workflow from the UI with CLI or Auto execution mode; real webhooks and API calls route to your runner

On a VPS or server, daemonize the runner with tensorify runner install (systemd or launchd) instead of keeping a terminal open.

Testing does not require a separate CLI command. With tensorify runner start running:

1. Open a workflow in the canvas editor
2. Click Test and select a target node
3. Click Run to Selected
4. Tensorify routes the signal to your runner; outputs appear in the editor and terminal

You do not restart the runner when you change node settings — edit the canvas and run Test again.

Production deployment happens in the web app, not on the command line:

1. Choose your execution mode. If using CLI or Auto, ensure your runner is connected (Runners page in the sidebar)
2. Click Deploy in the canvas toolbar
3. Choose execution mode (CLI, Managed, or Auto) and copy your trigger URL

When execution mode is CLI or Auto (with a connected runner), incoming requests are forwarded to your runner via WebSocket and executed locally.

When you deploy a workflow, you choose an execution mode:

You set the execution mode in the Deploy dialog for each workflow.

You can see all connected runners on the Runners page in the sidebar. Each entry shows status, last heartbeat, and which workflows are assigned.

When execution mode is CLI, Tensorify routes incoming requests to a connected runner for that workflow. If no runner is connected, the request waits or fails depending on your timeout settings.

Every workflow execution creates a job record. Jobs are visible on the Jobs page and contain:

• execution status (running, completed, failed)
• start time and duration
• trigger details (which endpoint was hit, what payload was received)
• per-node output snapshots (available during and after execution)

Jobs are your primary debugging tool for production issues.

Team-level environment variables are managed on the Env Vars page. They are injected into workflow execution at runtime and accessible from Code nodes as standard Python environment variables:

import os
db_url = os.environ["DATABASE_URL"]

See Environment Variables for details.

Tensorify includes an AI Agent plugin that adds autonomous LLM-powered reasoning to workflows. An agent uses a ReAct (Reasoning + Acting) loop: it receives a message, reasons about it, optionally calls tools, and produces a response.

Key concepts:

• Tools: Any action node (HTTP Request, Code, MCP Server) connected to the agent's Tools handle becomes a callable tool. The agent decides when and how to use each tool.
• Memory: Connect a Window Memory or Qdrant Memory node to the agent's Memory handle for conversation history across messages.
• Streaming: Agents can stream tokens and tool call events in real-time via SSE, providing a responsive chat experience.
• OpenAI Compatibility: Deploy an agent with an API Endpoint trigger and any OpenAI SDK client can connect using the standard chat/completions protocol.

See Build an AI Agent for a step-by-step walkthrough.

• CLI Reference — full command reference
• Deploying Workflows — how execution modes and runners work in production
• Plugins — browse all available nodes
• Build an AI Agent — create an agent with tools and memory