AI Nodes

Why a dedicated node

Calling an LLM from a hand-written backend usually means picking a provider SDK, handling its specific request/response shape, and wiring retries and error handling around it — for every different call site. The AI node does that once: configure a provider, model and mode, and every downstream node just sees a normal output, the same as if a Database node had produced it.

The AI node

Three fields configure a call:

• • aiProvider — openai, anthropic, google or custom for any OpenAI-compatible endpoint.
• • aiModel — the specific model id, e.g. gpt-4o, claude-3-5-sonnet.
• • aiMode — what kind of call this is:

• • chat — conversational, multi-turn responses.
• • completion — free-form text generation from a single prompt.
• • embedding — vector representations of text, for similarity search.
• • classification — sort input into a fixed set of categories.
• • extraction — pull structured fields out of free text.

The node's output feeds the rest of your workflow exactly like any other node — transform it, store it in Database, or return it directly in a Response.

Example: classifying a support ticket

API Endpoint  (POST /tickets)
   ↓
AI            provider: anthropic, model: claude-3-5-sonnet
              mode: classification
              categories: ["billing", "bug", "feature-request", "other"]
   ↓
SQL           INSERT INTO tickets (category, body) VALUES ({{category}}, {{body}})
   ↓
Response      201 { ticketId, category }

One extra node — no separate service to deploy, no provider SDK to import into a hand-written handler.

Bring your own AI

Use Fimaflow's built-in AI credits, or connect your own API key for a provider and pay them directly — set it in the node, or reference one stored as an Environment Variable. Useful once you have production volume or an existing contract with a provider.

Vector search

Pair an AI node in embedding mode with the Search node to build semantic search over your own data — embed content on write, then query by similarity instead of exact keyword match. Store embeddings in a vector-capable database (Postgres with pgvector, or a dedicated vector store) the same way you'd store any other column.

Interactions with the rest of the platform

• • An assistant connected via MCP can trigger a workflow containing an AI node the same way it triggers any other — the credits it consumes are still billed to your project.
• • Chain several AI nodes for multi-step reasoning — classify first, then generate a response conditioned on the category, without a single monolithic prompt trying to do both.

Errors & edge cases

• • A provider outage or rate limit surfaces as a normal node failure — wrap the AI node in a Try/Catch if the rest of the request shouldn't fail when the model is briefly unavailable.
• • classification/extraction modes return structured output — a response that doesn't match the expected shape fails the node rather than passing malformed data downstream silently.
• • Running out of AI credits mid-workflow fails only the AI node — everything else in the chain still executes.