How to Chain Multiple AI Steps for Complex Analysis
Build multi-step AI pipelines where each step builds on the previous one's output.
What This Integration Does
One giant AI prompt that does everything in a single call is brittle: you can't inspect intermediate reasoning, you can't swap a step for a cheaper model, and one bad output poisons the whole result. Chaining AI steps splits the problem into focused stages - extract, enrich, analyze, act - with structured data passed between them. Each stage is independently testable, replaceable, and observable.
The workflow runs end-to-end on a single input (an email, a ticket, a row from a database) and produces a final decision plus the full reasoning trail. Because every intermediate result is captured as a workflow variable, you can replay any step with a different prompt or model without re-running the entire pipeline.
Prerequisites
- An AI Agent enabled in Spojit (ideally with access to multiple models so you can mix-and-match per step).
- A Knowledge Base if you want enrichment from indexed company data.
- Source and destination connections appropriate to your use case (e.g. front, shopify, monday).
Step 1: Trigger and Stage Input
Drop a Trigger node - a Webhook from your support tool, a Schedule over a backlog, or an Email trigger. Use a Transform node to normalize the input into a stable shape so the rest of the chain doesn't care about the source format.
Step 2: Extract - Pull Out the Facts
Add a Connector node in Agent Mode. Use a fast, cheap model (Haiku or Flash). With Structured Output, extract the bare facts:
{
"customerEmail": { "type": "string" },
"intent": { "type": "string", "enum": ["refund", "exchange", "complaint", "question", "praise"] },
"productsMentioned": { "type": "array", "items": { "type": "string" } },
"sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] }
}
Step 3: Enrich - Add Context from Your Systems
Run a Parallel node with several enrichment branches:
- shopify
get-customerby email to load their order history. - shopify
list-ordersfiltered by the customer to get recent purchases. - Knowledge node querying internal docs for policies relevant to the intent.
Merge the results with a Transform node into a single context object the analysis step can consume.
Step 4: Analyze - The Heavy Thinking Step
Add a second Connector node in Agent Mode. Use a stronger model (Sonnet or Opus). Give it both the extracted facts and the enriched context. Ask for a recommended action with reasoning:
Given the customer message, their order history, and our refund policy,
recommend the best action. Cite the policy clause that supports your
recommendation.
Extracted: {{ extract }}
Context: {{ context }}
Schema:
{
"recommendedAction": { "type": "string", "enum": ["full-refund", "partial-refund", "exchange", "decline", "escalate-human"] },
"amount": { "type": "number" },
"reasoning": { "type": "string" },
"policyCitation": { "type": "string" }
}
Step 5: Decide - Branch on the Recommendation
Add a Condition node that routes based on recommendedAction. Self-serve outcomes (refund under $50, exchange) auto-execute via the next step. Anything labeled escalate-human or above your auto-approval threshold goes to a Human node where an agent confirms before the action runs.
Step 6: Act - Execute the Decision
Each branch ends in a Connector node that does the real work: stripe create-payment-intent for a refund, shopify update-order for an exchange, or monday create-item to open an escalation. Always finish with front send-message (or your channel of choice) to reply to the customer with the outcome.
Tips
- Match model size to step difficulty - extraction is Haiku/Flash work, analysis is Sonnet/Opus work. Mixing models cuts cost by 60%+ versus using your strongest model everywhere.
- Persist every intermediate output to MongoDB or a log - this is your audit trail when a customer disputes a decision.
- Build each step as a Subworkflow once it's stable so other pipelines can reuse the same extract or analyze stage.
Common Pitfalls
- Drift between steps - if step 2's schema changes, step 3 silently breaks. Treat each step's output schema as a contract and version it.
- Stale enrichment - if you cache customer data, make sure the analysis step knows how fresh it is, or you'll auto-refund a customer based on last month's status.
- Cascading hallucinations - if step 1 invents a product name, step 3 confidently reasons about a thing that doesn't exist. Validate extracted entities against your real data before passing them downstream.
Testing
Run a small batch of 10-20 historical cases end-to-end with auto-execution off. Compare each step's output against what a human would have done. If extraction is reliable but analysis disagrees with humans often, the fix is in step 4 - not your whole pipeline. The structure makes it cheap to iterate.