What Is a Manifest?
A manifest is a snapshot of your agent’s contract — the tools, model, prompts, subagents, and output schema that define how your agent behaves:How Auto-Detection Works
Detection is framework-specific. Each integration extracts the maximum available information:| Framework | Init flag | Tools | Model | Prompts | Schema Depth |
|---|---|---|---|---|---|
| LangChain | langchain=True | ✅ Auto + full schema | ✅ Full config | ✅ System/user | Full |
OpenAI Agents (install(agent=...)) | openai_agents=True + explicit install | ✅ Full JSON schema | ✅ Name | ✅ Instructions | Full |
| OpenAI Agents (auto) | openai_agents=True | Names only | ✅ Full config | ❌ | Names |
| LlamaIndex | llamaindex=True | Names only (OTel) | ✅ Full config | ❌ | Names |
| CrewAI | crewai=True | Names only (OTel) | ✅ Full config | ❌ | Names |
| AutoGen / AG2 | autogen=True | Names only (OTel) | ✅ Full config | ❌ | Names |
| Generic OTel | otel=True | Names only | ✅ Full config | ❌ | Names |
Generic + @tool decorator | (no flag) | ✅ From type hints | ✅ Full | ❌ | Full |
Explicit register_manifest() | (no flag) | ✅ Whatever you pass | ✅ | ✅ | Full |
Two calling forms — when to use which:
- Flag form (
decimalai.init(api_key=..., langchain=True)) auto-installs the integration. Use this by default — it’s what the Quickstart shows. - Explicit
install(...)form is for when you need to pass advanced arguments — e.g., anAgentobject for OpenAI Agents to capture full schemas, orprompts={...}to override dynamic prompts in LangChain. Calldecimalai.init(api_key=...)first, theninstall(...).
install() separately — pick one form per integration.- LangChain
- OpenAI Agents
- OTel / CrewAI
- Generic
on_chat_model_start, and prompts from system messages.Manifest Hashing
Manifest hashing is deterministic and noise-resistant:Hashing implementation details
Hashing implementation details
| Rule | What it does | Effect on drift |
|---|---|---|
| Per-surface hashing | Tools, prompts, models, subagents, skills, and output schema each get their own hash; the overall hash is the hash of all surface hashes sorted alphabetically | Isolates where drift came from |
| Temperature quantization | Small changes (0.70 → 0.71) are quantized to the nearest 0.1 | No drift for tweaks; 0.7 → 0.8 will trigger a new manifest |
| Runtime settings excluded | max_retries, timeout, and operational settings are stripped before hashing | These never cause drift |
| Tool order invariant | Tools are sorted by name before hashing | Reordering doesn’t create false drift |
| Hash dedup | If the same hash already exists, no new version is created | Deploying the same config to multiple pods won’t create duplicates |
Compatibility Scoring
When a new manifest is detected, DecimalAI classifies every existing trace against the new config:| Verdict | Meaning | Example |
|---|---|---|
| Keep | Trace is fully compatible | Model temperature changed slightly |
| Repair | Trace can be adapted mechanically | Tool schema added an optional field |
| Replay | Trace should be re-run with the new agent | System prompt changed significantly |
| Drop | Trace is incompatible — exclude from training data | Tool was removed entirely |
| Surface | Minor (keep) | Moderate (flag) | Major (drop) |
|---|---|---|---|
prompt_stack | Whitespace change | Content changed | Complete rewrite |
model_runtime | Temperature tweak | Model changed | Provider changed |
tool_registry | Schema field added | Schema field changed | Tool removed |
skill_registry | Skill added | Skill content changed | Skill removed |
workflow | Parameter change | Handoff added | Step removed |
subagents | Sub-agent added | Sub-agent reconfigured | Sub-agent removed |
output_contract | Optional field added | Field type changed | Required field removed |
guardrails | Threshold relaxed | Rule changed | Rule removed |
context_config | Window grew | Retrieval source changed | Source removed |
environment | Non-semantic var added | Value changed | Var removed |
Repair: Fix Traces Mechanically
Traces classified as repair can be fixed with a deterministic data migration — no LLM calls, no re-running your agent. The platform rewrites tool call data inside the trace records so they conform to the new manifest.What Repair Does
| Rule Type | What It Fixes | Example |
|---|---|---|
tool_rename | Rewrites tool name in trace records | check_inventory(...) → lookup_stock(...) |
param_rename | Renames parameter in tool call args | product_id → item_id |
param_remove | Strips deprecated parameter | Removes legacy_flag from args |
param_add_default | Adds new optional parameter | Adds region: null |
manifest_id is updated to point to the new manifest — it’s now “compatible” with v2.
Repair Flow
Preview
See what rules would be applied, with before/after examples:Response shows each rule with confidence level and sample trace diffs.
Approve
Review the rules. You can apply all rules or select specific ones:
- Apply All — repairs every eligible trace with all generated rules
- Selective — pick which rules to apply (e.g., approve the tool rename but skip the param removal)
Dashboard Quickstart
In the dashboard, the Impact Report banner appears automatically when your agent has 2+ manifest versions. From the banner you can:- Click “Repair All” to preview repair rules (before/after examples for each affected trace)
- Review the rules, then click “Apply Repairs” to execute
- Or click “Repair & Build” for a combined flow: repair all eligible traces, then build a clean SFT dataset from keep + repaired traces — one click, end to end
REST API
Repair vs Replay: Repair is instant (deterministic DB rewrite, zero LLM cost). Replay re-runs the full agent on original prompts (minutes/hours, full LLM cost). Use repair for schema changes; use replay when the agent’s behavior changed.
Compatibility Policies
How aggressively traces are classified when a manifest changes (strict / default / permissive presets, per-surface overrides, distillation mode, impact preview) is covered in its own guide:Compatibility Policies
Preset reference, per-surface overrides, impact preview before applying, and the distillation override for fine-tuning workflows.
What Happens When a Manifest Changes
The Manifest Timeline
The agent dashboard shows a timeline of all manifest versions with:- Version label (v1, v2, v3, or custom labels)
- Date registered
- Diff view — which surfaces changed between versions
- Trace count — how many traces were recorded under each version
- Compatibility summary — keep/repair/replay/drop counts
When Manifests Are Registered
| Framework | Timing |
|---|---|
| LangChain | On first trace completion (lazy) |
OpenAI Agents (with Agent) | Immediately at install() time |
OpenAI Agents (without Agent) | On first trace completion |
| OTel | On first trace batch export |
| Generic (explicit) | When register_manifest() is called |
| Generic (auto-deduce) | On first trace completion |
Best Practices
- Use static prompts. Dynamic content (RAG chunks, dates) in system prompts causes false drift. Pass dynamic content as user messages instead.
-
Use
@decimalai.toolfor full schema tracking. The decorator generates JSON schemas from Python type hints — enabling schema-level drift detection, not just name-level. - Start with the default policy. The balanced preset works for most teams. Switch to strict when you need training data purity guarantees.
-
Label important versions. Use
version_label="v2.1-prod"when deploying significant changes so you can find them in the timeline.
Next Steps
Regression Check
Get manifest impact analysis as a PR comment on every change.
Manifests API
REST reference for register, list, get, diff.
Versioning & Compatibility
Conceptual model — manifest hash, component verdict, severity, repair.
Compatibility Policies
Tune how the engine maps severity to verdicts.
Troubleshooting
False drift, or the action says “no manifest”? Common fixes.