FlowTrux is an AI-native workflow automation platform. You describe the work in plain language, and the built-in assistant turns it into a workflow: a visual graph of nodes that pulls data from your tools, analyzes it with AI agents, and delivers the result as a report, a message, or a live web page. Workflows run on schedules, webhooks, public forms, or on demand. You don't need an engineering team to get started - and if you are technical, expressions, HTTP calls, SQL, and custom MCP servers raise the ceiling a long way.
That's the summary. The rest goes through the machinery piece by piece - what each part does and how it behaves when you use it.
The canvas: node types and the data between them
Every workflow is a graph of nodes on a canvas, and every node is one of a small set of node types.
Triggers define how a run starts: a cron schedule, down to the minute; a webhook - the workflow gets its own endpoint, requests are signature-verified, and whatever the caller POSTs becomes the run's input; a public form - a hosted page with typed fields, file uploads, and server-side validation, for people who shouldn't need an account; and a manual click in the editor, which is how you test.
Actions do the concrete work: call an integration tool, send an HTTP request to any URL, run SQL against databases like PostgreSQL and MySQL, reshape data with a transform, or wait out a delay. AI agents are the reasoning steps - each one gets an instruction, a model, and optionally tools and a knowledge base, and earns its place wherever the next step depends on what the content means: triaging a support message, scoring a lead, summarising a week of activity. Logic nodes branch on conditions, filter, and gate on approvals. Aggregators collect parallel branches or loop iterations back into a single result - fan out over a list, process the items concurrently, merge what came back.
Between nodes, data moves through template expressions: a node references the trigger's payload, another step's output, a workspace-level global, or the current loop item. That's the whole contract - each node reads what it needs from what came before, so any node can be rewired, replaced, or hand-edited without breaking the ones around it.
The assistant: build, edit, debug, explain - one chat
The assistant is a panel inside the editor, and it detects what you want from what you write. Describe a goal and it answers with a plan card - the workflow it intends to build, step by step - before touching the canvas; click Build it and it places the nodes, wires them, and fills in configuration. Point it at an existing workflow and the same chat edits it (“add a Slack alert when the amount is over 500”), explains it (“what does this workflow do?”), reviews it for problems, or debugs a failed run - it reads the run, names the node that broke, and proposes a specific fix in plain terms.
Its changes arrive as action cards - each one shows the operation, the target, and a diff, with accept and reject buttons, and an apply-all for a batch. If you'd rather not confirm each step, flip on Auto-apply in the panel header and the assistant applies its edits as it goes - you review the result on the canvas instead of card by card.
Working drafts don't have to start from a sentence either: templates let you save any workflow and start the next one from it, and the assistant will adapt a template to your case on request.
Integrations: MCP tools, HTTP, SQL
Integrations are built on MCP - the Model Context Protocol, an open standard for exposing tools to AI. FlowTrux ships built-in MCP servers for the tools teams already use - Slack, Telegram, Gmail, Google Sheets, Calendar and Drive, GitHub, Jira, Notion, and more - each exposing typed operations with defined inputs and outputs.
Workflows use those tools in two distinct ways, and the difference matters. An action node calls one specific tool with parameters you set - deterministic, same call every run. An agent node gets tools attached, and the model decides which to call and with what arguments while working on its task - that's what lets one agent look something up, react to what it finds, and then act. Tool results flow back into the workflow like any other node output.
The same server can be configured several times under different names - two Slack configs with different bot tokens, say, each assigned to a different workspace. Anything without a built-in server is still reachable: the HTTP node speaks to any REST API, SQL nodes connect by connection string, and external MCP servers let you plug in your own - an internal CRM, a proprietary data source - and its tools appear alongside the built-in ones.
The AI layer: models, keys, knowledge
Each agent node picks its model from a dropdown - Claude (Anthropic), GPT (OpenAI), or Gemini (Google) - so a fast model can classify in one step while a stronger one writes in the next. Out of the box, agent nodes run on FlowTrux-hosted models metered by your plan's monthly credits; add your own API key and calls bill directly with the provider instead, with no credit cap.
Knowledge bases ground agents in your own content. Upload documents and they're split into chunks, embedded, and searched by semantic similarity at execution time - so an agent answering support email quotes your documentation rather than its training data, and a contract reviewer checks clauses against your standards. No vector database or embedding pipeline of your own to run.
Execution: what a run looks like
Every run writes a live execution log: each node appears the moment it starts, and its record holds what went in, what came out, how long it took, any error - and for agent nodes, token usage. Logic nodes even record the condition and its verdict. Past runs keep the same detail in history, so “what did it do last Tuesday?” has an inspectable answer.
Failures are marked on the exact node that broke, and the same chat that builds workflows debugs them - ask what went wrong and you get the cause and a proposed fix, not a stack trace.
Runs can also outlive the moment. A workflow can pause at a delay or callback step - its state saved - and resume hours or days later when a timer fires or an external system POSTs to the run's callback URL. That one mechanism covers drip sequences, scheduled retries, and approval flows: the run posts an approval request, waits, and a human's click resumes it down the approved or rejected path - an expense sign-off, a contract that needs a person's eyes before sending, a deploy gated behind a click.
Delivery: where results land
Delivery is just the last node, so the result takes the shape the process needs. A message where the team already talks - Slack, Telegram - or an email. A row written to a database, a POST handing off to another system, a generated PDF, a file in storage. Or a shared page or dashboard - Markdown, tables, charts - generated from the run's data and served on a URL you can hand to anyone, no FlowTrux account needed on their end.
Teams, permissions, credentials
Work is organised into workspaces. Members see only workspaces they've been added to, with per-member permissions for executing, editing, and deleting workflows - and org-level resources like AI providers, MCP servers, and knowledge bases are enabled per workspace, so one team's credentials never leak into another's. Credentials are encrypted before storage, and data is stored in the EU.
Try it on something real
The fastest way to understand FlowTrux is not a tutorial - it's taking one real task from your team's week and describing it. Pull data from somewhere, have an agent make sense of it, send the result where people will see it. FlowTrux is in public beta and everything is free right now; if the workflow it builds isn't right, tell the assistant what's wrong - that conversation is the product working as intended.