Step logic and AI
Step logic connects your journey brief to each customer decision: which records to read, which branch to take or how long to wait. Describe the behavior to maxinja, then inspect the generated explanation and inputs. Some steps use compiled logic; others call an AI model on each run.
Some of that AI work happens once, while you are building. Some of it happens on every single run. Distinguish generation during setup from model calls during execution when estimating a journey's ongoing usage.
Describe what you want
Select a step and its logic box is labelled for what it produces.
| Label | Steps that have it |
|---|---|
| Condition | Record Created or Updated, Record Deleted, Event Fired, Email Event, If/Else |
| Filter | Find Records, Delete Records |
| Value | Set Value |
| Query | Query |
| Case selection | Switch |
| Delay | Delay |
| Records | Create or Update Records |
| Event data | Fire Event |
Write one plain sentence in it. The greyed example in the box shows the register to aim for: "Customers who purchased in the last 30 days" on a Find Records filter, "The count of contacts created this month" on a Query, "Route by the order's plan tier: free, pro, or enterprise" on a Switch.
An optional filter left empty can include every record of the selected type. Required decision and value fields still need configuration; an empty If/Else condition does not mean every customer takes the true branch.
That default is destructive on a Delete Records step: with no filter, it permanently deletes every record of the schema you picked. Scope the filter deliberately before you publish.
Eight step types have no generated logic box: Scheduled Timestamp, Trait Threshold, Incoming Webhook, AI, For Each, HTTP Request, Send Email and Note. Neither does the empty placeholder. You configure those with ordinary fields.
The info button beside the label explains what that particular box controls. It is also where warnings live: errors appear under the box, warnings only inside that info card.
Point at the data the run carries
Type @ in the box and a picker opens listing everything the run carries at this point, with the step that produced each value. Choosing one drops a reference like {{ contact.email }} into your sentence. An amber marker means two earlier steps pass on the same name.
Computed fields do not appear in the picker, even though the logic maxinja writes can read them. Ask for them by name in your sentence.
Send it to maxinja
Press Enter, or the round arrow button beside the box. maxinja opens with your sentence and the step attached, works through it, and reports what it changed.
Typing in the box saves nothing on its own. Sending the sentence to maxinja is the only thing that stores it. Type a sentence, click away without compiling, and it is gone.
maxinja may rename the step and rewrite its description in the same pass, so a step can retitle itself after you compile it.
Read back what it wrote
When it is done the box header reads Compiled with a green dot and opens to show three things:
- A plain-English description of what the logic actually does. This is what you check, not code.
- Depends on, listing the Schemas, Attributes and Segments the logic touches. A red Unknown schema, Unknown attribute or Unknown segment badge means something it relied on is gone.
- Reads, a read-only view of the data the step takes in and the related records it loads with it.
The generated logic itself never reaches your browser. There is nothing to view, copy or hand-edit: it stays on the server, and only maxinja can write it. What you review is the description and the dependency list.
Refine it
The box always shows the sentence that was saved, and you can edit it in place. While your edit is unsent, Not compiled yet and a Revert button appear under the box, and the header keeps reporting the state of what is actually saved rather than what you are typing. Send it again and maxinja replaces the whole thing, so rewrite the sentence rather than appending a correction.
Two things to know about the box:
- You cannot empty it to remove logic. An empty box will not compile. To drop a filter, ask maxinja, or pick a segment on the steps that offer one (Find Records, Delete Records, Record Created or Updated, Record Deleted), which replaces the box entirely and discards the sentence.
- The arrow greys out for a moment right after you change another field on the step, because maxinja reads the saved step. Wait for the save to settle.
For a smaller nudge, use the maxinja box at the top of the sidebar instead. It talks about the same step without replacing your sentence wholesale.
Compile once, or decide on every run
This is the distinction worth understanding before you build anything that runs at volume.
| Compiled once | Decided on every run | |
|---|---|---|
| When the AI works | Once, while you build the step | Every time a run reaches the step |
| What happens on a run | maxclicks runs the saved logic. No model involved. | Your sentence and the run's data go to a model, which answers |
| Execution | Evaluates saved logic over the configured data | Waits for a model result before continuing |
| Cost per run | The step fee only, no AI cost | The step fee plus the model's tokens |
| Repeatability | Same logic over the same inputs gives the same decision; time and live data can change the inputs | Separate model evaluations can differ |
| Which steps | Every step with a logic box | If/Else, Switch and Delay only |
| Publishing | Required, except on those three | Allowed, with a warning, once you pin a model |
Compile a measurable rule such as an order-value comparison. Reserve a model evaluation for a decision that actually needs interpretation, and provide the evidence and permitted outcomes in the step's instructions. Compiled execution still has a step fee and can include the cost of obtaining its configured data.
What puts a step in each mode
There is no switch to flip. A step decides on every run when it has a sentence and no compiled logic behind it. maxinja prefers to compile, and falls back only when the logic genuinely cannot be reduced to a rule. When it makes that choice it says so in its report.
The visible signal is a required field group titled AI on every run appearing under the logic box. When a step is compiled, that group is not there. Its disappearance confirms that this controller no longer requires a model evaluation on each run; the step execution fee remains.
Only three steps can decide on every run
If/Else, Switch and Delay. On those, leaving the logic uncompiled is a publish warning, not a blocker, and the workflow ships:
The condition is not compiled yet, so AI evaluates it on every run, adding latency and cost.
Switch and Delay show the same sentence for their case selection and their delay. Every other step type refuses to publish until its logic is compiled, with a hard error such as The filter is not compiled yet. or The query is not compiled yet.
A Switch has no fallback path. If the model lands on something that is not one of your cases, the run fails outright. Make the cases exhaustive, or add an explicit catch-all case and say so in your sentence.
Pick the model and thinking depth
The AI on every run group holds two required pickers, Model and Thinking (Off, Low, Medium, High). Both start empty, and the workflow will not publish until you set them:
Pick the model for the runtime AI call.
Pick a thinking depth for the runtime AI call.
There is deliberately no workspace default behind them. Changing the model in your workspace AI settings can never move what a published workflow does or what it costs. The trade-off, as the field itself puts it: "Deeper thinking gives better judgment, but makes every run slower and pricier."
Choose from the models currently offered by the step. Use representative input and output complexity to compare speed and usage; model choice alone is not a fixed per-run price.
Decide from customer event history
If/Else offers Customer event history as an explicit alternative to generated condition logic. Choose the event collection, Has occurred or Has not occurred, Look back (days), and the Timing and matching settings.
The window is captured when the step reaches the decision and does not slide forward on every retry. Allow late events (seconds) waits beyond the captured window end before deciding. An absence condition requires at least 60 seconds of grace; the UI supports a lookback of 1–30 days and grace up to one day.
Match can be Events for this customer or object, or Same correlation ID as the triggering event. The latter requires that the trigger actually supplied a correlation ID. The run also needs exactly one authoritative customer or object; an ambiguous subject is an error, not permission to check everybody's activity.
If event storage is behind, the run waits for usable evidence. A decision that cannot be completed within its permitted lifetime fails rather than silently deciding that no event occurred. Once accepted, the decision and evidence are preserved for that step occurrence. Use this when the distinction between no activity and missing data matters to the email you are about to send.
What it costs
Every step of every type charges an operation fee of $0.00005 when it runs. A compiled step charges that and nothing else. A step that decides on every run charges that fee plus the model's tokens, on every run, multiplied by every record the workflow processes.
For example, 100,000 executions of a compiled step at a 0.00005-credit operation fee consume 5 credits for that step execution. That is an arithmetic example, not a complete workflow quote. Multiply all executed steps across the parent and child runs, then add runtime AI, personalization and other applicable usage.
An AI step's cost depends on its input and output tokens, model, thinking and tools. A fixed per-recipient price inferred from one example is not reliable for a different journey. See workflow billing for the full charging model and the cap on concurrent runs.
Everything the run carries is handed to the model each time, so the cost scales with how much data the step reads. A step reading a full contact record with its computed fields is materially more expensive per run than one reading a single number.
Billing has its own Usage tab: a spend chart at daily, weekly or monthly granularity over any date range, a summary, and breakdowns you can group by category or by member, with Workflows among the categories. What it will not tell you is which workflow, which run, or which step. Publish a workflow with a step deciding on every run and you will see the Workflows category move without being told what moved it.
The runtime records the result of a model evaluation for its step occurrence. A completed If/Else, Switch, Delay or AI evaluation can be reused during safe recovery. An interrupted evaluation with an unknown outcome is not blindly rerun: the step requires reconciliation. A Delay also keeps its saved deadline rather than starting the wait again.
Choose between them
- Compile anything you can state as a rule over data the run already carries. "The order total is over $50" is a rule. Compiled, it avoids an AI interpretation on each execution and gives a repeatable decision over the same inputs. Its step fee remains.
- Leave it to a model only for genuine judgment. "This product fits the customer's interests" is not a rule. That is what the per-run mode is for.
- Supply the evidence. Ordinary controller logic evaluates the data configured for that step. Use Query or Find Records to bring other context into the run. If/Else also has a dedicated Customer event history mode for a bounded event-history decision, described below.
- Start cheap. A fast model with Thinking set to Off fits most per-run work. Raise the model or the depth only for nuanced multi-factor reasoning, long or messy context, or an outcome the rest of the run leans on heavily.
- Compiling is a one-time cost. It runs a strong model working through your workspace's data while you wait, which is why it is not instant. Later executions avoid that interpretation cost, while the per-step fee and any data or action usage remain. The benefit depends on how often the workflow runs and how complex the rule is.
The AI step always calls a model
The AI step is the deliberate exception: it has no compiled mode, because calling a model is the point. It runs your prompt over the run's data and adds a structured answer.
You configure Expected data, Prompt, Result shape, then an AI settings group with its own required Model and Thinking. All four are required to publish. Like the controller steps, its model is pinned to the step and no workspace default sits behind it.
Three settings on this step multiply what a run costs, every run, not just the first.
- Web search is billed per search by the AI gateway, on top of the tokens the step already spends.
- Workspace data access hands the model read-only query tools plus a written description of your data, which it reads every time. In the product's own words, it "makes every run markedly slower and pricier".
- Granting any tool at all turns one call into an agentic loop of up to 15 model turns per run instead of a single answer.
Without tools, the step requests one structured answer. With tools, it can make several model turns and tool calls, up to the configured 15-turn bound. That is a limit, not a cost estimate. MCP tools may act on connected systems according to their permissions; review those capabilities as part of publishing the journey.
Personalized email bills per recipient
A Send Email step has no AI on every run group, but it can still call a model: if its content carries Adaptyle instructions, each message is personalized by a model as it is sent. That call is billed per recipient, not per run, and its model and thinking live on the email itself rather than on the step.
Content with no Adaptyle instructions in it renders with no model call and no AI cost. Ordinary Liquid substitution does not itself call a model; workflow fees, any configured data calculation and email allowance rules remain separate.
Keep your steps compiled
Compiled logic is dropped when the thing it was built against changes. After any of these, the step goes back to uncompiled and needs a new compile:
- Editing the sentence and saving it.
- Changing the schema the step is bound to.
- Adding, removing or renaming a Switch case. Reordering them is safe.
- Picking a segment, which replaces the box and discards the sentence.
Renaming a Switch case can invalidate its compiled selection. Recompile and inspect the mode before publication. A controller left in runtime AI mode needs explicit model settings; do not treat a successful save as confirmation that the decision still runs the way it did before.
maxclicks protects you from the destructive half of this. A schema, attribute or segment your step logic depends on cannot be deleted, and a segment that something references cannot have its condition edited. What it does not protect you from is quieter drift: renaming an attribute or changing its type is allowed, and nothing regenerates itself. Recompile the steps that depend on it after you change your data model.
Related
- Workflows: the canvas, runs, versioning, and the trigger API.
- Workflow block library: every step type and what you configure on it.
- Workflow billing: per-step charges, credits, and the concurrent run cap.
- Workflow runs: what a run did, and why one failed.
- maxinja: the assistant that compiles your step logic.
- Segments: reusable contact filters you can pick instead of writing a condition.
- Evaluated attributes: computed fields your step logic can read.