A flow that looked simple in the demo becomes six agents, four tool integrations, and three model providers in production. LangChain chains become graphs. CrewAI crews delegate. Handoffs multiply. A defect injected at step two reaches step five before anyone notices.
ValGuard is a runtime validation layer first. Its playbooks are step graphs, built so rules apply at every handoff. A graph holds agents, tool steps, route conditions, and validation gates, with block, re-ask, and escalate on failure. Use a playbook when you want the gate and the route in one place. If you already run LangGraph, CrewAI, n8n, or your own code, keep it. ValGuard enforces rules inside that flow.
For the engineering deep dive, read the multi-agent orchestration pillar. For the architecture argument, read deterministic orchestration as the missing layer.
Why orchestration breaks in production
Demos hide branching. If the ticket is billing, route it here. If it is an outage, page on-call. If a refund is over the threshold, ask a human. That is orchestration: conditions, state, and retries. It exists whether you write it in LangGraph, CrewAI tasks, or plain Python.
Signs you need explicit orchestration:
- More than one model call per user request
- Tool calls with side effects
- Different SLAs per branch
- A compliance requirement for an audit trail per step
The anti-pattern is one mega-prompt that must "classify, route, draft, and check policy." When it fails, you cannot tell which job failed. Split it into typed handoffs and validate the state between them.
What playbooks are, and what they are not
What they are. A graph of agent steps, tool steps, and route conditions. Every handoff can carry validation rules. Execution is OpenAI-compatible.
What they are not. ValGuard has no catalog of SaaS connectors. It has no scheduler and no inbound triggers. HTTP and webhook steps send a JSON POST to a URL you supply, with no custom headers or credentials. For triggers, schedules, app connectors, or multi-day enterprise sagas, use a workflow engine such as n8n or Temporal, and call ValGuard from inside it.
Human approval. A playbook can include an approval node that parks the run until a dashboard admin approves or denies (or the step times out). Clients that execute such playbooks must send X-VG-Approval-Mode: async, receive 202 with a run_id, and poll GET /v1/orchestration/runs/{run_id} (or listen for orchestration.run.completed). Encrypted run state is stored until the decision and deleted when the run finishes. Pending approvals are capped per plan (Free 3, Starter 20, higher plans 100).
| You need | Use | ValGuard's role |
|---|---|---|
| Triggers, schedules, 400+ app connectors | n8n, Make | Validate every LLM step before the next node |
| Agent state machines in code | LangGraph, CrewAI | Validate node outputs on the OpenAI-compatible path |
| Durable long-running execution | Temporal | Validate LLM activity results |
| A rule-enforced multi-step LLM flow with audit | ValGuard playbooks | Owns the graph and the rules |
Playbooks: linear, branch, and fan-out
ValGuard ships 63 production-ready playbooks. Provision one from the playbook marketplace or wire it through the playbooks documentation. Each playbook is a graph of agents, route conditions, tool steps, and validation gates.
| Pattern | When to use | Example |
|---|---|---|
| Linear | Fixed pipeline, same order every time | Triage → compliance → reply |
| Branch | Route on a validated classification | Billing vs outage vs refund |
| Fan-out | Parallel enrichment, merge the results | Multi-source research, KYC bundle review |
The Support resolution template is a three-step linear handoff. Invoice processing adds a fraud gate before confirmation. Policy Answer Guarded pairs retrieval with a compliance step for RAG answers.
Fork a template, simulate it, and publish from the dashboard. For rule-enforced flows you do not need a separate orchestration service.
Deterministic control beats probabilistic branching
If the model decides what happens next, the flow drifts at volume. If code decides from validated output, it does not.
classify → validate JSON → route(classification.team) → draft → validate policy → send
The model proposes team. Route conditions choose the branch. The model never "decides" to call the refund API. Validated state unlocks the allowed tools.
LangChain teams use RunnableBranch on a validated dict. CrewAI tasks define output schemas, with a human or validator gate before the next agent runs. ValGuard encodes the same pattern in orchestration templates you can simulate before you publish.
Guarded tool calls and multi-provider routing
Tools are production APIs. Do not expose the full toolbelt to every agent.
- Role-based tool registry: the support agent sees
create_ticket, the admin agent seesupdate_billing - Pre-execution validator: the Agentic Tool Call Validator playbook
- Post-execution validator: check the response schema before the next agent sees it
- Injection scan on tool payloads: see prompt injection in production agents
Provider outages and price pressure push teams toward several providers. Routing belongs to the orchestration layer. Consistency belongs to the validators. The Smart LLM Fallback Router tries a cheaper model first and escalates only when validation fails. Cost drops, and the guards still run.
Overhead: milliseconds, measured
A model call takes hundreds of milliseconds. Orchestration should not add anything you can feel.
Rule packs evaluate in microseconds. A guarded request through the HTTP layer adds 0.36 ms at p50. A three-step playbook with validation on every step adds about 1.9 ms for the support handoff and 1.1 ms for a retrieval-grounded answer. All three figures come from the latest benchmark snapshot, with the model call mocked. The methodology page explains what each number includes and what it leaves out.
One trade-off matters for latency. Block and re-ask rules buffer the full reply before it is emitted. Token-by-token streaming applies to warn and log rules. Details are in the streaming notes and on Trust.
Integration without rewrites
ValGuard is OpenAI-compatible. Point your existing client at the API URL, attach validators per agent, and publish a playbook when you need a multi-step flow.
LangChain and LangGraph: attach validation as a RunnableLambda between nodes. Keep the validation result in graph state. Route on validation_passed, not on raw LLM text.
CrewAI: define output_json or a Pydantic model on each task. In a sequential process the next task does not start until the validator passes.
n8n and Make: point the LLM node's OpenAI credential at ValGuard, or call the chat-completions endpoint from an HTTP Request node. Then branch on the validation result. See ValGuard + n8n and ValGuard + LangGraph.
Getting started: follow the quickstart to wire your first agent. Then work through the playbook tutorials for graph editing, simulate mode, and the publish checklist.
What to ship first
Teams that succeed start narrow:
- One inbound channel: support email, chat, or a ticket API
- One classification step with a schema validator
- One branch that either drafts a reply or escalates
- Validation logs on from day one
Add fan-out and multi-provider routing once the happy path is stable. The ticket enrichment before routing article shows what fan-out looks like in production.
In ValGuard the playbook carries validation, cost policy, and observability on every step. The handoff that looked simple in the demo behaves the same at 10,000 requests a day. If your flow already lives in another engine, run it there and add ValGuard where an LLM output can do damage. Compare approaches in integrations.
For failure modes, retention, and self-host scope, see Trust.