Architecture Overview | Prompt Tornado

Q: Is this an agent framework?

No - it's a managed orchestration platform. The layers are shipped behavior, not building blocks you assemble.

The pipeline, layer by layer

A request flows top to bottom. Each layer has one job and hands a well-defined artifact to the next.

01 · Planner

Decompose the prompt

Turns a compound request into a typed, ordered plan of tasks with dependencies. Evaluated at 98% planning accuracy across 200 prompts, and 100% deterministic — identical prompts produce identical plans.

02 · Task registry

Know the task types

A catalog of 181 task types across 17 categories, each with detection signals and a recommended model. The registry is the single source of truth the planner and router agree on.

03 · Routing layer

Pick the model

Maps each task to the best-fit model across seven providers, with ordered fallback. See multi-model routing.

04 · Executor

Run the plan

Executes tasks in dependency order, handles retries and failover, and passes outputs between dependent steps. A dependent step only starts once its input is ready.

05 · Run ledger

Record everything

Every run is an inspectable record — models, providers, latency, tokens, cost, status, and a full execution audit log of events with per-event payloads.

06 · Evaluation gate

Guard quality

The CI quality gate blocks deploys on regressions, so routing and prompts can change without silently degrading. See evaluation.

The run ledger, concretely

Every execution emits a structured audit log. Here is the event sequence from a real 3-step run, each event carrying an inspectable payload.

Event	What it records
`run_started`	Run created; input prompt and run ID captured.
`plan_created`	The planner's typed, ordered task plan for this run.
`step_started`	A task begins — its type, chosen model, and provider.
`step_completed`	A task finishes — output, latency, tokens, status, and any fallback.

In the example run, this ledger captured three completed steps in 109.38s for 5,929 tokens at $0.0245. See the full run →

Prompt Tornado run details view showing the execution steps and audit log for a completed workflow.

Design principles

Declarative over ad-hoc. Routing lives in a registry, not scattered through prompt strings — so it stays correct as models change.
Deterministic planning. The same prompt always plans the same way, which is what makes regression testing meaningful.
Everything recorded. If it ran, there's a trace. Debugging a workflow means opening a run, not guessing.
Evaluation as a gate, not a report. Quality is enforced in CI, so reliability is a property of the pipeline.

Frequently asked

What makes the planner reliable?

It's deterministic — identical prompts produce identical plans — and evaluated at 98% planning accuracy across 200 compound prompts for valid schema, correct ordering, and no hallucinated tasks.

Where does the routing "source of truth" live?

In the task registry: 181 task types across 17 categories, each with detection signals and a recommended model. The planner and router both read from it.

Is this an agent framework?

No — it's a managed orchestration platform. The layers above are shipped behavior, not building blocks you assemble. See how it compares to LangChain.

How Prompt Tornado is built.

The pipeline, layer by layer

The run ledger, concretely

Design principles

Frequently asked

See the architecture run a real workflow.