Give an n8n AI Agent real video tools

An n8n AI Agent is only as useful as the tools you hand it. Out of the box it can reason and it can call an HTTP endpoint, which means every media operation becomes a hand-built request with hand-built error handling and no idea what a job costs.

Short version, so you can leave if that is all you needed. Install @rendobar/n8n-nodes-rendobar, drop the Rendobar node onto an AI Agent’s tool port, and the agent gets ten typed actions covering job submission, status, logs, output download, file upload, connected storage and account balance. The interesting part is not the install. It is the three design decisions that separate an agent which can process video from an agent which quietly burns your credits.

Why the node appears as a tool at all#

n8n decides what an AI Agent may call from a single flag on the node description:

export class Rendobar implements INodeType {
  description: INodeTypeDescription = {
    displayName: "Rendobar",
    usableAsTool: true,
    // ...
  };
}

With usableAsTool: true, n8n exposes the node on the AI Agent’s tool port and generates the tool schema from the node’s own parameters. There is no separate tool definition to maintain and no second place for the parameter list to drift out of sync.

What the agent receives, as of 0.6.0:

Ten actions, five resources. Plus a separate trigger node carrying ten events: job.created, job.started, job.completed, job.failed, job.cancelled, job.delivery_succeeded, job.delivery_failed, job.deliveries_settled, balance.low and balance.depleted.

Decision one: let the agent read its own balance#

This is the one people skip, and it is the one that matters most when an agent is allowed to spend.

Two of the ten trigger events are about money. balance.low and balance.depleted both fire on the account, not on a job. For a while the node could fire on both and had no way to answer the obvious next question, which is how low. A workflow woken by balance.low knew only that something was wrong.

Account → Get closes that. The agent can pre-flight before an expensive job rather than discovering the problem by failing:

AI Agent
 ├── Rendobar: Account → Get        (what is the balance?)
 └── Rendobar: Job → Create         (only if it clears the threshold)

The asymmetry is worth stating plainly, because it generalises past this node. If you give an agent a tool that spends, give it a tool that reads the account. Otherwise the agent’s only feedback signal is failure, and failure arrives after the money is gone.

Decision two: never let an agent poll a long job#

The Rendobar node offers three ways to wait, and only one of them is right for an agent.

Wait for Completion polls until the job finishes. It is the obvious choice and the wrong one for anything long, because it pins an n8n worker for the job’s entire duration. An agent that fires off a ten-minute encode and sits in a poll loop has taken a worker out of circulation for ten minutes.

Callback URL plus a Wait node is the pattern to use. The job carries a callback, the execution parks, and n8n resumes it the moment the terminal event arrives. Nothing is held open in between:

Rendobar: Job → Create  (Callback URL = the Wait node's resume URL)
        ↓
Wait (On Webhook Call)  ← execution parks here, no worker held
        ↓
AI Agent               (reasons about the finished job)

The Trigger node is the third option, and the right one when the workflow is the reaction. Fire on job.completed and there is no waiting at all, because the workflow starts when the job ends.

The node refuses Wait for Completion and Callback URL together rather than silently preferring one. Hiding a conflicting field does not clear its value in n8n, and getNodeParameter still returns it, so a hidden field is a bug waiting to happen rather than a fix.

Decision three: let the agent diagnose its own failures#

An agent that reports “the job failed” has wasted the run. Pair the job.failed trigger with Job → Get Logs and it can read the actual FFmpeg stderr and decide what to do:

Rendobar Trigger (job.failed)
        ↓
Rendobar: Job → Get Logs
        ↓
AI Agent  (reads stderr, fixes the command, resubmits)

FFmpeg failures are usually specific and legible: an unknown encoder, a filter graph that will not build, an input the demuxer rejects. That is exactly the kind of error an LLM is good at reading, provided you actually give it the text. Without the logs it is guessing.

What a job actually costs#

Agent loops make cost concrete in a way scripted workflows do not, because the agent decides how many jobs to run.

A real transcode, submitted on 20 August 2026: H.264 to VP9 with libvpx-vp9 at CRF 34 and libopus audio. It held 2.2 CPU cores for 6.1 seconds, used 387 MB of memory, finished 22.3 seconds after submission, and cost $0.0071.

At that rate the $5 signup grant covers several hundred short transcodes, which is a comfortable budget for letting an agent experiment. It is also why Account → Get is worth wiring up before you hand an agent a spend tool rather than after. The free tiers across the category differ by more than 100x in real work, so the grant is worth comparing before you commit an agent to one vendor.

Setting it up#

1. In n8n, press + on the canvas, search for Rendobar and install it from More from the community. The node is verified by n8n, so this works on n8n Cloud. A self-hosted instance can still take the older Settings → Community nodes route with @rendobar/n8n-nodes-rendobar.
2. Create a Rendobar API credential with a key from the dashboard.
3. Add an AI Agent node, then attach Rendobar to its tool port.
4. Add a Rendobar Trigger if you want the workflow to react to job events rather than drive them.

The node is published with npm provenance attestations, so the package on the registry is verifiably built from the tagged commit in the public repository.

If you are still choosing the underlying service rather than the n8n wiring, the category map is the place to start, and the eight-service comparison covers which ones run the literal FFmpeg command an agent writes.

Where this stops#

The trigger fires on every event of a subscribed type across the account, not filtered by job type or client. A captions pipeline and an image pipeline sharing one account will wake each other’s workflows, and the workflow has to discard what it did not want. Filtering at the source needs an API change rather than a node change, so it is honest to call it a current limitation instead of routing around it in the node.

Everything else here is live in 0.6.0 and checked against the production API. An install from the nodes panel gets the version n8n has verified, which can trail the latest npm release. The install step above was rewritten on 9 September 2026 when the node went live on n8n Cloud. Before that it read “open Settings, Community nodes”, which still works on a self-hosted instance.

The same waiting problem, and the same callback answer, applies in Activepieces. That one is written up in Add video processing to Activepieces.