Vectorbea Docs

Vectorbea is a control plane for durable AI workflows. You compose agents, tools, and connections into workflows on a visual canvas, run them with full observability, and govern them with human approval gates. Every run is checkpointed — when something fails or waits, the workflow resumes from the last checkpoint instead of restarting.

• Visual canvas — drag-and-drop builder for triggers, agents, LLM calls, tools, branches, parallel fan-outs, approval gates, and checkpoints.
• Durable runtime — Kotlin workers execute runs from a queue with leases, retries, timeouts, and crash recovery.
• Observability — every run produces an event timeline, structured logs, token/cost accounting, and failure diagnosis.
• Governance — approval gates, risk-leveled tools, read-only connections, and a full audit trail.
• BYOK — bring your own LLM provider keys (OpenAI, Anthropic, Azure, Gemini, Bedrock); secrets are AES-256-GCM encrypted.

Real AI automation is long-running. A renewal pipeline waits days for a manager's decision. A research agent makes fifty LLM and API calls. A data workflow processes thousands of records. Stitching this together with scripts or basic agent frameworks breaks down fast:

• Crashes lose everything. A timeout at step 9 of 10 means re-running steps 1–8 — repaying every token and re-firing every side effect.
• Side effects are unsafe to retry. Naively re-running a workflow can send the same email twice or double-write to your CRM.
• Humans can't intervene. There is no first-class way to pause a pipeline for sign-off and continue exactly where it stopped.
• No visibility. When an agent misbehaves you need the exact prompt, tool calls, outputs, latency and cost — not a print statement.
• No governance. Teams need risk controls before agents touch production databases and customer inboxes.

Vectorbea treats the workflow run as a durable, event-sourced entity rather than a process in memory — so waiting, failing, retrying, and resuming are normal, cheap operations.

When you start a run, the API enqueues it and a worker picks it up under a lease. The worker walks the workflow graph node by node. After every node, outputs are persisted — that is the checkpoint. The run's entire history is an append-only event stream.

Approval gates take this further: a run that reaches a gate is parked — it consumes no compute while waiting hours or days. The moment a human approves, the worker resumes from the checkpoint before the gate. Rejections end the run cleanly with a full audit trail. If a run does fail, the recovery engine classifies the failure (auth, network, rate limit, data…) and offers one-click Retry / Resume from checkpoint on the run page.

Every node in a workflow has a typed input and output contract. Tools declare JSON schemas, agents produce structured outputs, and triggers define the fields a run starts with. Because every output is checkpointed with its shape, downstream nodes can reference upstream data without writing any JSON or template code — Vectorbea's unified I/O system wires it visually.

Working with mappings in the builder:

1. 1

   Define the trigger's input fields

   Select the trigger node → its config shows an input field builder — add fields as name + type + required rows (no JSON Schema editing). These become the run's starting data and are what the Run dialog asks for.
2. 2

   Connect nodes, then open Inputs

   Drag an edge between two nodes, select the downstream node, and open the Inputs tab in the inspector. Every required input field is listed with its type.
3. 3

   Auto-map the obvious matches

   When upstream outputs match input names/types, a green "N inputs can be mapped — Map all" banner appears. One click applies every confident match. Individual fields also show a one-click suggestion chip (source → field · Use) when a likely match exists.
4. 4

   Pick the rest from the field list

   For anything not auto-mapped, click the field and choose from a typed picker of all upstream outputs — grouped by node, filtered to compatible types. Static values can be typed in directly.
5. 5

   Validation catches gaps before you run

   The inspector's issue counter and the Valid badge flag unmapped required inputs and type mismatches. A workflow with unresolved required inputs won't pass validation.

At runtime the worker resolves each mapping against the checkpointed step outputs — so even after a crash-resume or an approval wait, downstream nodes see exactly the same upstream values. The same fields appear in approval-gate messages and in the run's debug view, where you can inspect every resolved input per node.

1. 1

   Add a connection

   Go to Connections → New Connection. Pick LLM Provider, paste your API key (encrypted on save), and run Test & save. Repeat for your database or API if the workflow needs data.
2. 2

   Register a tool

   Go to Tools → New Tool. For a database read: choose Database (Read), bind the DB connection, browse the schema, and let Vectorbea generate the SQL template and input/output schemas. Set an honest risk level.
3. 3

   Create an agent

   Go to Agents → New Agent → Native LLM Agent. Choose the LLM connection and model, write the system prompt, and tick the tools it may call. Set retry/timeout policies (the defaults are sane).
4. 4

   Compose the workflow

   Go to Workflows → New → blank canvas. Add a Trigger (manual, schedule, or webhook), then your tool and agent nodes from the palette (or press ⌘K). Connect nodes by dragging between handles.
5. 5

   Map inputs — no JSON required

   Select a node → Inputs tab. Vectorbea suggests mappings from upstream outputs ("Map all" applies every confident match); each field can also be picked manually from a typed field list.
6. 6

   Add governance

   Place a Human Approval step before anything irreversible (sending email, writing data). Add a Checkpoint node after expensive stages to make resume points explicit.
7. 7

   Simulate, then run

   Hit Test for a simulation run — no real side effects. Inspect the run timeline and logs. When it looks right, Run for real execution (subject to your workspace execution mode).
8. 8

   Observe and operate

   Open Runs to watch executions live. If something fails, the Recovery tab explains why and offers Resume from checkpoint. Add a Schedule to run it automatically.

The Architect turns a plain-English goal into a runnable workflow. Describe the outcome — "every Monday, pull contracts renewing in 30 days, score churn risk, and email the account owner a summary; ask me before anything is sent" — and it does the rest.

1. 1

   Describe the goal

   One or two sentences. The Architect asks up to a handful of clarifying questions only when the goal is genuinely ambiguous.
2. 2

   Review the plan

   It proposes the node graph, agents (with drafted system prompts), tools, and a confidence meter. You approve the plan before anything is created.
3. 3

   Wire connections

   It detects which connections the plan needs, shows readiness, and lets you pick existing connections or create missing ones in place.
4. 4

   Build & refine

   Agents, tools, and the workflow are created and laid out on the canvas. From there it's a normal workflow — edit any node, remap inputs, add gates, simulate, run.