Skip to content

Analyze with AI

Analyze with AI is the step that reads the conversation and returns structured data — not loose text. It’s what lets an automation decide based on what was said: whether the customer showed buying intent, which objection came up, what the conversation was about.

The Analyze with AI step, with Model, Instruction and Output fields

Which model does the analysis. By default it follows the model chosen in your organization’s preferences — so swapping the default model applies to every automation at once.

What the AI should do with the content. It accepts variables, and the most used one here is conversation.transcript, which brings the entire conversation history as text.

An instruction that works well usually has three things: what to read, what to decide and what to return. For example:

Read the conversation and say whether the customer showed buying intent
and which objection came up.
Conversation: {{conversation.transcript}}

This is the part that makes the step worth it. Every field declared here becomes a variable the following steps can use:

The output field editor, with name, type and description

Each field has three parts:

  • Name — how the following steps read the value. Use unaccented letters, numbers and _, no spaces.
  • TypeText, Number, Yes or no or One of the options (for the last one you list the options separated by commas; at least two are required).
  • Description — what this field should contain. This is what guides the AI, so it’s worth writing carefully: “yes, if the customer showed buying intent; no otherwise” produces better results than “intent”.

The step needs at least one field to save. An AI step with no output field would burn credits and return nothing usable.

The fields become available in the steps below this one, in their own group in the variable picker. The path is the step’s identifier plus the field name — for example, n5.buying_intent.

The most common pairing is this:

  1. Analyze with AI classifies the conversation;
  2. a Condition splits the flow on the result;
  3. each branch does what it needs — apply a tag, store the value on the contact, notify someone.

The variable is only valid below the step that created it, and only on paths that go through it. A step on another branch can’t see that output — and SquadOS refuses to save a flow that tries, rather than letting the variable come out blank in front of the customer.

This is the only step that consumes credits, and it consumes them on every run.

  • If your organization uses its own key (BYOK), the step costs 1 fixed credit and the call goes out on your key.
  • Without your own key, the call goes out on the platform’s key and the dollar cost is converted into credits.

Each run’s cost shows up in the Cost column of the Activity tab. More about credits in Plans and billing.

“Always” re-entry plus an AI step deserves attention. Every event becomes a run, and every run pays for the analysis. It’s the combination that surprises people on the invoice.

The Test button simulates sends, but it does not simulate the AI: the step executes and charges normally. That’s on purpose — the value of testing is precisely seeing what the model returned.