Assisted pilot — evidence-based workflow diagnostics
SDVM turns workflow evidence into structured diagnostics—so you can locate structural friction, prioritize a narrow intervention, and compare PRE / POST / DELTA results instead of guessing.
It works from the traces your existing tools already capture. Conclusions stay proportional to that evidence.
Pilots start with one recurring workflow, comparable runs, and a technical owner ready to test a narrow intervention.
In long-horizon agentic workflows, steps get skipped without errors. Repairs pile up across cycles. Handoffs add noise. Outputs still look plausible. By the time a visible failure appears, the workflow has often already drifted—and output-only evaluation misses these mid-trajectory problems.
The failure signal arrives late. The drift started earlier. SDVM is built to surface that earlier path.
Stable execution
Skipped steps, repair pressure and handoff noise accumulate while the run still looks plausible.
The failure signal appears late
Agentic workflows are moving into production. Reliability, governance, and failure diagnosis have not caught up. Recent research and enterprise analysis describe the same gap SDVM is built to examine.
Aggregate success metrics can hide critical operational failures—inconsistency, weak robustness, unpredictability, and unsafe error behavior.
Towards a Science of AI Agent Reliability arXiv preprint
Agentic systems no longer stop at outputs. They trigger actions, call tools, and affect downstream systems—raising the cost of weak monitoring and governance.
State of AI trust in 2026: Shifting to the agentic era McKinsey
Observability answers what happened?
SDVM helps answer the next question: where is the workflow degrading, and what should we change first?
It sits on top of your existing tools and turns workflow evidence into decisions you can act on:
Diagnostic depth grows with instrumentation quality. Thin evidence stays marked as thin—so you know when to refine capture before drawing a stronger conclusion.
From evidence to a comparable decision cycle.
The point of the report is not to show more data. It is to make the next decision obvious: which edge to retune, and whether the change improved the workflow.
Synthetic example — not client data PRE/POST/DELTA excerpt
| Signal | PRE | POST | DELTA |
|---|---|---|---|
| Repair pressure | 3.1 repairs / cycle | 1.2 repairs / cycle | −61 % |
| Handoff noise | 4 of 7 handoffs flagged | 1 of 7 handoffs flagged | −75 % |
| Step skip rate | 4 skips observed | 1 skip observed | −75 % |
| Evidence strength | 0.51 | 0.74 | +0.23 |
| Interpretation limit | Medium | Low-medium | Stronger, not definitive |
Decision: retune the checkpoint/handoff edge before expanding scope.
You act on the edges where signals concentrate—then verify the effect with a comparable POST run instead of guessing across the whole workflow.
Example only. Real reports depend on capture quality, workflow structure, and available evidence.
Canonical variables are computed with fixed, reproducible rules. That is what makes PRE / POST comparison meaningful: the same method before and after the intervention.
Interpretation sits on top of those results. AI is not the origin of a diagnosis. Any future AI assistance is designed to operate on top of that core, never to replace it.
Four dimensions frame how SDVM reads a workflow. Thirteen canonical variables do the measuring underneath.
So the diagnosis stays trustworthy: output stays proportional to the evidence, weak support is flagged, and overclaims are blocked.
Assisted pilots already run on a tested path. The thirteen canonical computation modules exist and are covered by tests—but they are not yet the default integrated diagnostic pipeline.
Executable in assisted pilots today, or implemented as tested modules.
Defined architecturally and being matured now—including integration of the modules above.
Later, downstream layers.
The goal of a pilot is a sharper operating loop: find the friction, choose one intervention, and see whether it moved the signals—without months of trial and error across the whole workflow.
Strong candidates have traceable multi-step runs, observable repairs or handoffs, and a technical owner who can act on findings. Coding and bugfix-style workflows are a preferred early track—but the fit is structural, not domain-specific.
Typical shape: 2–4 weeks, depending on capture and team cadence.
SDVM is workflow-engine agnostic. The current assisted path is Langfuse-first; broader surfaces remain under evaluation. The same framing can also assess workflows still being designed—by checking instrumentation and diagnostic readiness before production.
The goal is a useful decision under real or semi-real conditions: where to act, what to test, and whether the signals moved. Not commercial validation of universal silent-drift detection.
Analysis can run on anonymized traces and metadata. Scope, access, and retention are agreed case by case. NDA support is available when required.
Review the pilot intake template · See a readiness probe example
If the workflow looks only partially ready, email a short summary. We can scope capture quality and a progressive instrumentation path—then decide whether a pilot is the right next step.
SDVM is developed by Ibrahim José Jamhour, an independent researcher working on Distributed Relational Cognition and the operational risks of agentic systems. The work builds on published research, a formal SDVM V3 technical specification, and ongoing assisted pilot work.
Jamhour also brings prior executive experience in institutional finance and risk-sensitive operations, including the Stanford Sloan Fellows program.