SaveMyToken logosavemytoken.
All knowledge base guides

AGENTS & ORCHESTRATION / FIELD GUIDE

Choose a RAG workflow or agent, then set its boundaries

Separate the answer model from its workflow, compare direct orchestration with LangGraph, and study a bounded multi-search example.

9 min read · SaveMyToken editorial · Documentation reviewed 2026-10-05 · Build in your own stack

STEP 01

Draw the fixed path first

In a workflow, code defines the sequence. An agent can decide its next tool call based on the task and previous results. Many FAQ lessons can start with question → retrieve → answer → citation check; needing retrieval does not by itself require an autonomous agent.

  1. Trace the printer question through the fixed path. Identify the returned passage, answer instruction, and citation check.
  2. For a two-document comparison, write down whether two predetermined searches are enough. If so, study a fixed multi-step workflow first.
  3. Consider an agent when the next search depends on what earlier evidence reveals. Keep the same questions to test whether this extra flexibility actually helps.
You should see

You can state what decision an agent would make that a fixed route cannot already make for your task.

STEP 02

Choose orchestration separately from the model

A model generates text or tool requests; an orchestration framework manages how steps execute. Direct application code is an inspectable starting point for a short fixed path. LangGraph provides a lower-level runtime for stateful workflows and agents, including persistence and human intervention.

  1. For a simple route, study the local retrieval lesson and write down the search, answer, and validation functions without adding a framework first.
  2. If you need resumable state, branching, or review checkpoints, inspect the LangGraph documentation and map those needs to its capabilities. Record the framework version before following API-specific examples.
  3. For any visual platform, check that it exposes retrieved passages, model inputs, and tool traces. Evaluate the same printer and parking questions rather than treating its Agent label as a quality guarantee.
You should see

Your notebook lists the workflow style, optional framework, and answer model as three separate choices.

STEP 03

Make tool use finite and observable

Use a fictional research question: compare the booking rules in two document versions. The example below is a learning contract, not executable configuration. Its search budget is an editorial trial, not a universal optimum.

  1. Expose a read-only search tool returning passage text, IDs, and versions. Derive access scope from the authenticated application, not model-supplied arguments.
  2. Define success: evidence from both requested versions, a supported comparison, and citations. If one source is missing, say which part cannot be established.
  3. Define a maximum tool-call budget, per-call timeout, and an overall token or cost budget. Stop repeated searches that yield no new evidence.
  4. Record each query, result IDs, and stopping reason. Compare this trace with the fixed two-search workflow before deciding which to use.
Illustrative agent contract — adapt in your chosen framework
Allowed tool: search_knowledge (read only)
Goal: compare v1 and v2 booking rules with citations
Trial budget: at most 3 search calls
Stop when: both versions have supporting evidence
Also stop when: budget expires or searches repeat without new evidence
Missing evidence: identify the missing version; do not infer its rule
Timeout and token budget: set from your own service limits

If it does not work

If the loop repeats, inspect query changes and returned IDs. Raising the iteration limit is not a substitute for a clear stopping rule.

Give your changes a fair test.

Use the same questions, inspect the evidence, and record what changed.

Open comparison worksheet