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-customer by email to load their order history.
  • shopify list-orders filtered 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.

Learn More

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.