Builder Basics Copied!
The Visual Agent Builder is where you build and edit agents. You add steps to a canvas, write instructions for each one, and test as you go. This article covers the fundamentals: how building works and how to write instructions that generate reliable scripts.
If you haven't read What is FloQast Transform? yet, start there. It explains the one concept everything below builds on: each step's instructions get converted into a fixed script, and that script is what runs every period.
How Building Works Copied!
Your agent appears on the canvas as a series of connected steps, so you can see the whole process at a glance: which steps exist, what order they run in, and how data flows from one to the next. To build, you add a Skill Block to the canvas, connect it to the flow, and configure it.
An example agent on the canvas. Each step hands its output to the next.
What configuration looks like depends on the block. Action blocks like Upload to Reconciliation ask you to set parameters, such as the period and folder. Data blocks like Transform Data are where you write instructions, and where most of your build time goes. The rest of this article is about writing those instructions well.
Selecting a step opens its configuration panel, where you write and edit its instructions.
One Job per Step Copied!
The most common building mistake is packing too much into one step. The more you ask a single step to do, the more likely script generation is to fail or produce something subtly wrong. When in doubt, split it up.
A good step has one job you can describe in a sentence: clean the input file, filter to the rows that matter, build the summary table, populate the template. If your description needs the word "then" more than once or twice, that's usually two steps.
A PO accrual agent broken into single-job steps. Each one is easy to describe, easy to test, and easy to fix on its own.
Splitting steps pays off later, too. When a run fails or a number looks off, small steps make it obvious where the problem is. And when your process changes next quarter, you can edit one step without rebuilding the whole agent.
Make your first step a cleanup step. Remove empty rows and columns, get headers into the first row, and make sure each column holds one data type. Every step downstream gets more reliable when the data coming in is predictable.
Write Complete, Self-Contained Instructions Copied!
Writing a step can feel like chatting with an AI assistant, so it's natural to want a back-and-forth: give it part of the task, see what it does, add the rest. That approach works against you here.
A complete instruction covers the input it works on, exactly what to do with it, and what the output should look like. Numbering the parts of the task helps, both for you and for the AI:
1) Create a new tab called 'Benefits Data'
2) Copy all data from the 'Active' tab into 'Benefits Data'
3) Remove all empty rows and columns in 'Benefits Data'
4) Add a new column at the end of 'Benefits Data' named 'TOTAL'
5) In 'TOTAL', sum the values of the preceding columns for each row
Be Specific Copied!
Vague instructions force the AI to guess, and a wrong guess gets baked into the script. A few habits remove most of the guesswork:
- Name your data, in quotes. Instead of "copy the name column from the raw data," write "copy column 'First Name' from the 'Raw Data' tab." Quoted names tell the AI exactly which tab, column, or input you mean.
- Spell out dates and data types. "Filter out invoices received after the 28th" leaves too much open. Better: "Filter out rows where 'Received' is after 2026-02-28. 'Received' is a date formatted YYYY-MM-DD."
- Show an example of the output you want. If the result needs a specific layout, paste a sample row with the exact headers and formatting. The AI will follow the pattern.
- Describe formats in concrete terms. "Make it look nice" doesn't translate to a script. "Bold the header row and format values as Accounting Number with two decimal places" does.
Don't Hardcode What Changes Copied!
You build an agent once, but it runs against new files every period. Next month's file will have a different number of rows, and someone may add a column that shifts everything over. Instructions that point at fixed positions break the moment that happens.
So avoid instructions like "sum rows 2 through 150" or "use column C." Refer to data by its header names, and ask for logic that finds the data wherever it lands:
The same thinking applies to your build files. Build with a sample that represents what real files will look like, including the edge cases, and the script you generate will hold up when the real thing arrives. More on preparing inputs in Agent Inputs & Files.
Test as You Go Copied!
Run a test after every step or two rather than building the whole agent and testing at the end. A test run shows you each step's output, so you can confirm the data looks right before you build on top of it.
This matters because steps depend on each other. If step 2 produces something slightly off and you don't catch it until step 6 fails, you're debugging backwards through four steps. Catching it at step 2 costs you a minute.
Test runs are safe: they won't post anything or touch your close. When a test doesn't come out the way you expected, Transform Tips & Troubleshooting covers the common causes and how to fix them.