An AI agent can collect and correlate the evidence for an Exstream production failure in minutes. The safe scope starts with one job, a short time window, and named read-only sources. It widens only when the evidence points elsewhere.
Do not mount a production share and ask the agent to "find the problem." That scope mixes unrelated jobs and exposes correspondence that the investigation may never need.
Let the agent collect evidence, not decide the change
Most production investigations are slow because the evidence sits in different systems. An operator checks a job folder, searches several logs, runs a database query, opens the deployed package, and compares it with the approved Design configuration. The technical work is often less difficult than collecting the facts and putting them in the right order.
An agent can do that mechanical work quickly. Within the access boundary set by the operator, it can:
- filter a large log set to one job and a short time window;
- extract only the database rows and counts needed for the question;
- inspect the deployed PUB and relevant Design objects;
- compare filenames, queue rules, return codes, and record counts;
- produce an ordered timeline with links back to the evidence.
This can reduce hours of tool switching and manual copying to minutes of evidence collection. The operator spends that time checking the conclusion instead of assembling it.
The saving is in triage and correlation. The agent does not approve a production change, invent meaning for an undecoded field, or replace the operator's judgment.
Start with the operator's question
The operator should supply:
- the exact task and job identifier;
- the environment;
- the local timestamp and timezone;
- the reported symptom;
- the permitted read-only sources;
- the boundary for customer and operational data.
The first question is usually narrower than the alert. "Why is this task marked failed?" is better than "Why is production broken?"
Preserve the job before interpreting it
List the exact job folder with filenames, sizes, and timestamps. Do not print full input XML or correspondence documents.
Useful evidence includes:
- engine message files;
- queue reports;
- sort indexes;
- delivery manifests;
- archive metadata;
- ZIP entry names;
- return codes and step results.
Counts and names often answer the question without exposing document bodies.
The agent should record missing files as observations, not failures. A conditional queue can validly produce no file.
Split the production path into failure layers
An Exstream batch status often combines several systems:
composition
-> sorting or post-sort
-> batch orchestration
-> archive
-> channel packaging
-> transfer
The agent should give each layer its own result.
A nonzero engine return code may be below the configured stop threshold. A successful SFTP step does not prove that the manifest was correct. A missing report may be valid while a later reader is defective.
This separation prevents one loud message from becoming the explanation for every symptom in the job.
Read the exact deployed package
The repository describes what may have been packaged. The deployed PUB describes what the engine actually ran.
Use CCMForge Inspect to establish package identity and extract only the required objects:
exstream-package-cli Production.pub \
--format json --out /secure-temp/package.json
Start with the ordinary report. Detailed mode can contain proprietary formulas, mappings, paths, and customer-facing wording. Use it only when the question requires those fields, keep the output in approved storage, and delete it after the investigation according to local policy.
The package can answer questions such as:
- Which queues and reports were shipped?
- Which rule includes a record in a queue?
- Where is a filename or counter generated?
- Which variable receives a fixed-width or input field?
- Does the deployed package contain the approved correction?
Read the decoder coverage before treating an empty field as proof.
Use the Design repository to fill the right gap
The Design repository can expose hierarchy, approved object state, data-file layouts, and version history that the package may not preserve.
Keep the query narrow:
exstream-design-cli object describe \
--kind output_queue 42 \
--config ./inspect.yaml --profile production-design \
--mode approved --json
The repository tool should use a read-only identity. The agent should never approve, package, edit, or deploy an object as part of diagnosis.
Repository state and package state can disagree. Report the disagreement instead of silently choosing the newer value.
Correlate logs with an exact time window
Operational logs establish execution order. Search by the exact job identifier and convert the observed local timestamp to UTC before querying a central log store.
Start with a short window. Expand only if the first relevant event points outside it.
The result should be a step timeline, not a dump of every matching log line:
14:03:11 composition finished, return code 0
14:03:18 archive transfer finished
14:03:24 report reader failed, file absent
14:03:24 task marked failed
The adjacency between the exception and the final task state is evidence. An unrelated warning ten minutes earlier is not.
Use invariants for cross-system failures
Counts expose ownership boundaries.
For a digital-delivery flow, compare:
source documents
physical PDFs
manifest recipients
ZIP PDF entries
transfer acknowledgements
If the ZIP contains every physical PDF but the manifest has one extra recipient, transfer is not the first correction point. If the package rule creates both the counter and manifest row, that application owns the broken invariant.
The agent should state both the supported conclusion and the components it ruled out.
Keep the report public-safe by construction
The final investigation report should normally retain:
- anonymized object and queue names where needed;
- counts;
- file roles rather than internal paths;
- relevant rule fragments with business identifiers removed;
- step IDs, return codes, and relative ordering;
- package generation and decoder coverage;
- proven, rejected, and unknown explanations.
It should omit customer names, policy numbers, addresses, correspondence text, production hostnames, mount paths, session cookies, tokens, and internal URLs.
Do not rely on a cleanup pass after an unrestricted transcript has already captured the data. Limit collection at the start.
End with a reviewable decision
A useful agent report ends with:
- The immediate cause and supporting evidence.
- The component that owns the correction.
- The tempting explanations that the evidence rejected.
- The proposed change.
- The regression cases and invariants.
- Any unresolved uncertainty.
The operator can then approve a small action with the evidence, rejected explanations, and remaining uncertainty visible.
See how CCMForge Inspect supplies structured evidence to agents.