A manifest is a snapshot of your agent’s full configuration at a point in time: which tools, models, prompts, skills, and sub-agents it uses.Manifests can be:
Auto-detected — extracted from incoming traces (zero config)
Manually registered — explicitly declared via the SDK or API (highest fidelity)
Manifest vs Version: A manifest is the data (the full snapshot). A version is the label (v1, v2, v3). Each agent has many manifests over time; each manifest has a unique version label. Version labels are NOT semantic versions (major.minor.patch) — they simply auto-increment.
A surface is one independently-versioned policy-grouping of the manifest — a slice you can write its own compatibility rules for. Components are bucketed into surfaces so that, for example, a breaking tool change can replay while a guardrail change merely gets flagged. There are 10 surfaces:
Surface
What It Groups
prompt_stack
System prompts and instructions
model_runtime
The LLM(s) and runtime params (model, temperature, etc.)
tool_registry
The set of callable tools and their signatures
skill_registry
Loaded skills (SKILL.md modules)
workflow
Orchestration structure and control flow
subagents
Delegated child agents
output_contract
Expected output schema
guardrails
Input/output safety and validation rules
context_config
Context-window and retrieval configuration
environment
Runtime environment and external dependencies
Each surface carries its own on_minor / on_moderate / on_major action under the agent’s compatibility policy — see the matrix below.
When the engine diffs a single component across old and new manifests, it assigns one of four per-component outcomes. (This is distinct from the per-traceCompatibility Verdict of keep/repair/replay/drop.)
Component Verdict
Meaning
COMPATIBLE
The component is unchanged, or changed only cosmetically — no action needed.
REPAIRABLE
The component changed in a way that can be deterministically fixed (e.g. a renamed parameter).
INCOMPATIBLE
The component changed in a breaking way that cannot be auto-fixed.
MISSING
The component was present in the old manifest but no longer exists in the new one.
A SHA-256 fingerprint of the manifest’s structural components (tools + models). Two manifests with the same hash for the same agent are considered identical — the second registration is idempotent. Prompt changes alone do NOT change the hash — they’re tracked separately via content hashing for drift detection.
When a trace arrives with a manifest hash matching a previously superseded manifest, DecimalAI detects this as a rollback. It re-activates the old manifest and supersedes the current one — no duplicate is created. Your version history stays clean.
When a manifest changes, the compatibility engine classifies every existing trace to determine if it’s still usable. This is what makes DecimalAI’s training data lifecycle possible.
Each surface has its own rules, but the shape is the same across presets. Here is the tool_registry surface — for each component severity, the action each preset takes:
Severity
strict
default
permissive
none
keep
keep
keep
minor
keep
keep
keep
moderate
drop
repair
keep
major
drop
replay
flag
The five possible actions are keep, repair, flag, replay, and drop. A severity of none always maps to keep (nothing changed). Other surfaces shift the actions — guardrails, context_config, and environment are softer (a major change only flags under default), while prompt_stack and model_runtime are stricter.→ See Compatibility Policies for policy configuration.
The manifest, the diff, and the compatibility-decision format are all defined by agentversion — the open spec the platform is built on. You can produce the same manifests and verdicts outside DecimalAI with the agentversion package on PyPI.
