Validation gates
- Schema check on every output
- Business rules, such as dates in range or totals that add up
- Comparison with the source to catch invented content
- Run stopped when a gate fails twice
AI / Prompt Chaining
Prompt Chaining AI Services for LLM Workflows
One long prompt extracts, decides and writes all at once, and when the answer is wrong nobody can tell which part failed. Agnotic Technologies builds prompt chains: fixed steps with typed hand-offs and a check after each one, so your team can test, trace and fix a single step.
Fixed, testable stepsJSON Schema hand-offsChecks between stepsPer-step tracing
Trusted by global innovators
What are prompt chaining AI services?
Prompt chaining AI services design and build LLM workflows that split one task into fixed steps, such as extract, classify, draft and check, where each step's output is typed, validated and passed to the next. Agnotic Technologies builds these chains for product teams that need AI features they can test and trace step by step.
The order of the steps is set in code, not chosen by the model. That is what separates a chain from an agent, and it is why a chain is easier to test: every run follows the same path.
This page covers fixed-step workflows. Agents that choose their own tools, full evaluation suites, runtime guardrail gateways and retrieval design each have their own pages, linked below.
Decision table
Single prompt, prompt chain or agent: which does your task need?
Choose the simplest shape that does the job. We start every scoping call with this table.
| Question | Single prompt | Prompt chain | Agent |
|---|---|---|---|
| Task shape | One job with one clear output, such as a summary or a label | Several known steps in a known order, such as extract, then classify, then draft | Steps not known in advance; the model decides what to do next and which tool to call |
| Predictability | High for simple jobs, lower as the prompt grows | High: the path is fixed in code and every step is checked | Lower: two runs on the same input can take different paths |
| How you test it | One evaluation set for the whole prompt | An evaluation set per step, plus a few end-to-end cases | Scenario tests over whole runs, including tool use and when to stop |
| Latency and cost drivers | One model call | One call per step; parallel steps cut waiting and retries add calls | Open-ended unless capped, since calls grow with every loop and tool result |
| When a person approves | Before the output is used, if it matters | At a named gate, for example before a drafted message is sent | Before any action that changes records or spends money |
| When to move up | When one prompt carries several jobs and errors are hard to locate | When the steps truly vary by input and cannot be listed in advance | Rarely the place to start; first show that a chain cannot do the job |
Many products use all three: single prompts for small jobs, chains for core workflows and an agent only where the path cannot be fixed.
Which prompt chain patterns do we build?
Most workflows combine two or three of these patterns.
Sequential chain
Steps run one after another, each using the previous step's typed output.
Routing
A classify step sends each case down the branch written for it, with its own prompts and checks.
Parallel steps
Independent steps, such as reviewing each section of a document, run at the same time and merge before the next step.
Draft, review, refine
One step drafts, a second reviews the draft against criteria and a third revises it using the review.
Human gate
The chain pauses at a named step so a person can approve, edit or reject the output.
Map over many items
The same steps run over each item in a batch, such as every line of an invoice, and the results are checked together.
Step decomposition
How do you break a task into chain steps?
We split by job, so each step has one input, one output and one thing that can go wrong.
Extract
Pull the fields the task needs from the source text, with the location of each field, so later steps work from data rather than the whole document.
Classify
Assign the case one label from a fixed list. The label decides which branch of the chain runs next.
Draft
Write the reply, summary or note from the extracted fields and the instructions for that branch, and nothing else.
Check
A separate step tests the draft against rules and the source: required facts present, nothing added that the extract did not contain, length and tone within limits.
Decide
A pass moves forward, a fixable failure goes back to the draft step once with the check's notes, and anything else goes to a person.
Typed hand-offs
What passes between the steps?
Each step returns JSON that must validate against its schema before the next step runs. Output that fails validation never moves forward.
| Code | Name | Typical use |
|---|---|---|
| Extract | Fields with their source locations, and missing fields listed by name | Gate: required keys present, types correct, every location found in the input |
| Classify | One label from an enum, with a short reason | Gate: label is in the allowed list; an unknown case routes to a person |
| Draft | Text plus the IDs of the extracted fields it used | Gate: every cited field exists in the extract output |
| Check | Pass or fail, with a list of issues | Gate: decides between moving forward, one retry and human review |
Gates, retries and fallbacks
What happens when a step fails?
Failure handling is written for each step before its prompt is tuned.
Retries
- One retry with the validator's error message
- A different model only where it has been tested on that step
- No retry for content the check marked unsafe
- Retry count logged per step
Fallbacks
- A simpler prompt or rule-based path for known cases
- A stored answer for repeated inputs
- A partial result marked incomplete rather than a guess
- A clear message to the user when the chain cannot finish
Human review
- Named gate where a person approves the output
- Review queue with the run's trace attached
- Reviewer edits saved as new test cases
- Time limits so cases do not sit unseen
Failure points
Where do prompt chains go wrong?
Splitting a task into steps removes some failures and creates new ones. These are the ones we design against.
Challenge
An early error carried forward
Agnotic approach
A wrong extraction looks like valid data to every later step, so the extract gate compares fields with the source before anything else runs.
Challenge
Context lost between steps
Agnotic approach
Each step receives only what it needs, but the schema lists what later steps rely on, so nothing they need is dropped along the way.
Challenge
Prompt injection passed between steps
Agnotic approach
Text from documents travels as data in its own field, never as instructions, and steps that read untrusted input have no tool access.
Challenge
A model update changes one step
Agnotic approach
Each step pins its model and prompt version, and a change runs that step's test set before it ships.
Testing and tracing
How is each step tested and traced?
A chain is only easier to fix than one large prompt if you can see inside it.
An evaluation set per step
Each step has its own test cases with expected outputs, so a change to the draft prompt is judged on drafting, not on the whole chain.
End-to-end cases
A smaller set of full runs confirms the steps still fit together after any change.
A trace for every run
Each run records every step's input, output, model version, latency, token count and gate result, so a bad answer can be traced to the step that caused it.
Replay of failed runs
Failed runs are stored with their inputs and can be replayed against a new prompt version before it ships.
Scope, cost and latency
What drives the cost of prompt chaining AI services?
We size the work on a scoping call. These factors move build effort, running cost and response time; we do not quote figures before we have seen the workflow.
Steps and branches
Each step needs its own prompt, schema, gate and test set.
Model per step
Small models for extract and classify steps, and larger ones only where drafting needs them, change both cost and latency.
Parallel or sequential
Steps that can run together shorten the wait; strict ordering adds it up.
Retry rules
Every retry is another model call, so retry limits shape running cost.
Input size
Long documents raise tokens per call; extracting early keeps later steps small.
Human gates
Review queues, permissions and notifications add product work beyond the chain itself.
Where it fits
Which workflows suit a prompt chain?
Work with a known sequence of steps and an output someone relies on.
Document intake
Fields extracted from forms, letters or emails, the request classified and routed to the right queue.
Support replies
The ticket classified, the relevant account facts pulled and a reply drafted for an agent to approve.
Report and summary drafting
Structured data and notes turned into a draft report, with a check step for missing or added facts.
Content review
Marketing, policy or product text checked against a rule list, section by section in parallel.
Data cleanup
Names, addresses or product descriptions normalized in batches, with rule checks on each item.
AI product startups
Prompt chaining AI services for startups that need a core feature they can test before every release.
Standards and APIs
Which standards does a prompt chain build on?
Hand-offs use open schema standards, so a step can move to another model without rewriting its contract.
JSON Schema 2020-12Structured outputsOpenAPINIST AI RMF
How we work
How does a prompt chaining engagement work?
Three stages, starting with one workflow.
1.
Scoping call
We take one workflow, write down its steps and decide together whether it needs a single prompt, a chain or an agent.
One workflow
2.
Fixed-scope first release
The chain with its schemas, gates, per-step test sets and tracing, running on your data in a test environment.
Fixed scope
3.
Scale and support
More branches and workflows, model changes tested step by step, and new failures added to the test sets.
Traced
Facts and sources
What do the model and schema docs say?
Short facts behind the step and hand-off design, each linked to its primary source.
Anthropic's Claude documentation says explicit prompt chaining, breaking a task into sequential API calls, is useful when you need to inspect intermediate outputs or enforce a specific pipeline structure, and that running each step as a separate call lets you log, evaluate or branch at any point.
Source: Claude documentation, Chain complex promptsClaude's structured outputs feature uses constrained decoding to return schema-compliant JSON, and the schema it accepts follows JSON Schema with some limitations.
Source: Claude documentation, Structured outputsOpenAI's Structured Outputs feature ensures model responses adhere to a JSON Schema the developer supplies, and it supports a subset of the JSON Schema language.
Source: OpenAI API documentation, Structured model outputsThe current version of JSON Schema is 2020-12. The specification is split into two parts: Core, which defines the basic foundation of JSON Schema, and Validation, which defines its validation keywords.
Source: JSON Schema specification
Frequently Asked Questions
In a prompt chain, the steps and their order are fixed in code. An agent decides its own next step and which tools to call. Chains are easier to test and cheaper to run, while agents fit tasks whose path cannot be listed in advance.
It can be, because each step is a model call. We keep chains fast by using small models for simple steps, running independent steps in parallel and extracting early so later prompts stay short. Latency is measured per step during testing.
Each step's output must pass its schema and rule checks before the next step runs. A failed check retries once with the error message or stops the run, so a bad extraction never reaches the drafting step.
Yes, if text from a document is treated as instructions in a later step. We pass source text as data in separate fields, validate every output against its schema and keep tool access away from steps that read untrusted input.
Yes. The chain runs as a service your application calls, reads documents or records through the access you approve, and writes results back through your APIs or into a review queue.
It depends on the number of steps and branches, the test data available and the systems involved. We fix the scope of a first release for one workflow on the scoping call and plan the dates from it.
Yes. One workflow built as a chain, with its schemas, gates, test sets and tracing, is a complete first release. It shows whether the chain beats your current prompt before you add branches.