Model quality matters, but users experience the reliability of the complete workflow.
An AI product may depend on an API gateway, identity provider, retrieval system, vector index, model provider, workflow engine, tool integrations, policy service, queue, database, and observability stack.
That is a distributed system, even when the interface is one text box.
Define reliability around user work.
Service uptime alone is insufficient. A model endpoint can return 200 while the workflow retrieves stale evidence or produces an unusable result.
Define a successful unit such as:
an investigation completed with required evidence, a valid disposition, and no policy violation within the latency objective.
Then set service-level indicators for:
- workflow completion;
- evidence availability;
- valid structured output;
- tool success;
- end-to-end latency;
- safe action execution;
- freshness;
- cost per completed unit.
Map the dependency budget.
If a workflow makes several sequential remote calls, its reliability and latency inherit every dependency.
Document:
- timeout;
- retry policy;
- rate limit;
- concurrency limit;
- regional dependency;
- data freshness;
- fallback;
- circuit breaker;
- owner.
Do not give every service the full end-to-end timeout. Allocate a budget by step, and preserve time for recovery or a useful failure response.
Make workflows durable.
Production workflows need state that survives restarts and deployments.
Use:
- durable step state;
- idempotency keys;
- bounded exponential backoff;
- retry classifications;
- dead-letter handling;
- cancellation;
- compensating actions;
- resumable approvals.
Never retry a state-changing tool automatically unless the operation is idempotent or its result can be checked.
Degrade deliberately.
A fallback should preserve the user's ability to make a safe decision.
Examples:
- switch to lexical retrieval when embeddings are unavailable;
- use a smaller approved model for extraction;
- return evidence without a generated summary;
- queue nonurgent enrichment;
- require manual review;
- disable actions while retaining read-only investigation.
Do not silently lower quality and preserve the same confidence language.
Observe AI-specific failure.
OpenTelemetry's generative AI conventions support model, token, agent, and tool signals. Combine them with normal traces, logs, and metrics.
Record:
- workflow and step IDs;
- model and prompt version;
- retrieval query and result IDs;
- token usage;
- tool arguments in redacted form;
- policy and approval decisions;
- retries and fallback;
- output validation;
- analyst correction;
- final outcome.
Sensitive prompts and evidence require stricter access and retention than normal service metadata.
Treat data quality as reliability.
Stale indexes, missing telemetry, parser regressions, and entity collisions can produce fast but wrong output.
Monitor:
- ingestion lag;
- source coverage;
- schema rejection;
- duplication;
- freshness by source;
- entity-resolution confidence;
- retrieval empty-result rate;
- citation integrity.
For AI security systems, evidence health belongs on the reliability dashboard.
Control cost and resource exhaustion.
Set limits for steps, tokens, retrieved context, tool calls, wall-clock time, and concurrent workflows. Detect recursive loops and retry storms.
Measure tail cost. A small percentage of pathological cases can dominate spend and capacity.
Cost controls should degrade explicitly rather than truncate work invisibly.
Release the system, not only the prompt.
A prompt update, model change, embedding change, parser deployment, or policy edit can all change behavior.
Use:
- versioned artifacts;
- offline regression;
- adversarial tests;
- shadow traffic;
- canary rollout;
- outcome monitoring;
- rollback.
Preserve replayable cases so the team can compare versions against the same evidence.
Write runbooks before incidents.
Operators need to know:
- how to disable actions;
- how to pin a model version;
- how to drain workflows;
- how to replay failed work;
- how to rotate credentials;
- how to inspect provider and retrieval health;
- how to communicate degraded quality.
The system is not reliable because it rarely fails. It is reliable because failure is bounded, visible, and recoverable.