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 of this post follows one workflow through its whole life - from the sentence that creates it to the report it sends on its own every Monday morning.
It starts with a sentence
Almost every team has some version of this job: once a week, someone pulls the numbers, writes up what changed, and sends it around. It's never anyone's favourite hour of the week. Said out loud, the task is one sentence:
“Every Monday at 9:00, pull last week's numbers, write a short summary of what changed, and email it to the team - and if something looks off, ping our Telegram channel too.”
In FlowTrux, that sentence is the input. You type it into the assistant - a chat panel that lives inside the workflow editor.
The assistant turns it into a plan, then a graph
The assistant doesn't silently generate something behind your back. It first answers with a plan card - the workflow it intends to build, step by step, in plain language. If the plan is wrong, you say so in the chat. If it's right, you click Build it, and the assistant starts placing nodes on the canvas, wiring them together, and filling in their configuration.
For this sentence, what lands on the canvas: a schedule set to Monday 9:00, an action that pulls the numbers from where they live - a spreadsheet, a database, an internal API - an agent that reads them and writes the summary, an action that emails it to the team, and a branch: if the agent flagged something unusual, a second action pings the Telegram channel.
Under the surface this is the structure everything in FlowTrux shares: a graph built from five node types. Triggers start runs. Actions do concrete things - fetch data, send a message. AI agents are the reasoning steps. Logic nodes branch, filter, and gate. Aggregatorsmerge parallel branches back together (this workflow doesn't need one). The sentence changes from team to team; the vocabulary never does.
Nothing it built is a black box
Click any node and an inspector opens: the schedule's timing, the data source's address, the agent's instruction and its model dropdown. Everything the assistant configured, you can change by hand - and data flows between nodes through template expressions, so a downstream node can reference exactly what an upstream one produced.
This is also where the two audiences meet. If you never open the inspector, the assistant's draft simply runs. If you write code for a living, the same canvas gives you expressions, raw HTTP calls, direct SQL - nothing is dumbed down. And once a workflow earns its keep, you can save it as a template and start the next one from it instead of from a blank canvas.
Then you run it and watch
The first run is manual - that's how you test. The execution log fills in live: each node appears the moment it starts, its result fills in as it completes, and every node keeps what went in, what came out, and how long it took. You watch the numbers arrive, the summary get written, the email go out.
When a run fails, the log shows exactly which node broke and why - and the same chat that built the workflow debugs it. Ask what went wrong, and the assistant reads the failed run and proposes a specific fix, in plain terms. Building and debugging are one conversation, not two tools.
Then it stops needing you
The test passed, so you activate the workflow - and from now on, Monday 9:00 belongs to the schedule. Not everything runs on a clock, though, and the trigger adapts to how the work arrives: a webhook lets any system that can POST start a run and hand it data; a public form on a branded URL - file uploads included - lets people outside your team feed the workflow without an account; and a manual click is always there.
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 its callback URL. That is what makes drip sequences, scheduled retries, and approval flows single workflows instead of stitched-together pairs: the run posts an approval request, waits, and a human's click resumes it down the approved or rejected path.
And something useful comes out the other end
Monday morning, the team reads a summary a human would have written - because an agent read the numbers, not because someone gave up an hour. The Telegram ping only happens on the weeks it should. And delivery is just the last node, so the output takes whatever shape the process needs: a message where the team already talks, an email, a row written to a database, a POST to another system, or a live web page or dashboardgenerated from the run's data on a URL you can share.
The machinery underneath
Everything above runs on a small set of building blocks. Tools come from 13 MCP servers - typed operations across Slack, Telegram, Gmail, Google Sheets, Calendar and Drive, GitHub, Jira, Notion, and more - plus an HTTP node for any REST API, SQL for PostgreSQL and MySQL, and your own MCP servers for anything internal. Agents run Claude, GPT, or Gemini, chosen per step; bring your own API keys and the provider bills you directly, or use FlowTrux-hosted models metered by credits. Knowledge bases ground agents in your own documents through semantic retrieval (RAG) - no vector database to run. And work is separated into workspaces with per-member permissions, 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, the way that Monday report was described. 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.