An agent has generated a report on declining new-customer conversion. The task is not finished. A business leader needs to know whether the conclusion supports a decision, an analyst needs to recompute material values, and an operations team may need an investigation ticket. They require different artifacts and may have different data rights.
Delivery is complete when an authorized recipient can understand, verify, and use the result. Recommendation, approval, submission, confirmed effect, and business impact must remain separate states.
Two separations matter: report state from action state, and execution success from business effectiveness.
Define completion by recipient
| Recipient | Primary artifact | Completion condition |
|---|---|---|
| Business leader | Conclusion, evidence, limitations, risk, and decision needed | Can distinguish fact, hypothesis, and recommendation and knows who decides |
| Analyst | Result tables, method, query/code, data and semantic versions | Can recompute material values; limitations are explicit |
| Business system | Structured action draft, approval, execution, and read-back | Target state is confirmed; partial and unknown outcomes remain visible |
The same analysis may require several versions with different visibility. The author’s access to detail does not grant every report recipient permission to download it. Reauthorize the artifact for its actual audience.
Bind claims to evidence
Every material factual claim should point to a result, query or code, data snapshot, semantic version, and validation record. A minimal output contract might be:
{
"task_id": "conversion-review-demo",
"report_version": 1,
"status": "partial",
"claims": [{
"kind": "observation",
"text": "conversion declined across the covered channels",
"evidence_refs": ["result/channel-comparison"]
}],
"semantic_ref": "conversion/v3",
"data_snapshot_ref": "snapshot/demo",
"limitations": ["regional analysis incomplete; no causal evidence"],
"artifact_refs": ["report/v1", "table/v1"],
"action": {"state": "draft", "type": "create_investigation_ticket"}
}
partial must not become “all causes identified” in the title. A draft action must not be described as a created ticket.
Validate charts and files
Tables disclose units, time, definitions, numerators and denominators, pagination, and truncation. Charts do not render missing values as zero or exaggerate movement with an undisclosed axis. Narrative values and visuals should derive from the same result object.
Reports place material uncertainty beside the conclusion, not in a remote appendix. Notebooks and applications disclose environment, inputs, permissions, and cost. Opening an artifact should not trigger expensive or side-effecting work.
The W3C guidance for complex images recommends short alternatives plus detailed descriptions of a chart’s core information. For a Data Agent, writing that description is also a useful test of what the chart actually supports.
Reproducibility does not require copying all raw data
An evidence package can connect data snapshot, query execution, result table, and report claim. The W3C PROV overview provides a vocabulary of entities, activities, and agents. A team need not implement the full standard on day one, but the provenance relationships should be queryable.
Reproducibility has levels: locate method and source, rerun in the same environment, and obtain an equivalent result within tolerance. Dynamic data, expired dependencies, and external services can limit the last two; state the limit. Copying sensitive raw data into every report is neither necessary nor safe.
An action is a separate submission workflow
- Draft: specify action type, target, parameters, evidence, and likely impact; default to no side effect.
- Preflight: validate identity, recipient, classification, version, budget, and expected change.
- Authorize: an entitled person or policy approves exact parameters and an expiration; material changes require reapproval.
- Submit: use an action gateway, stable logical operation ID, and downstream idempotency.
- Read back: query the target, distinguishing accepted request from final effect.
- Recover: handle partial success, unknown state, and irreversible operations differently.
Amazon’s Builders’ Library article on making retries safe with idempotent APIs explains client request identifiers and safe retry behavior. After a timeout, query by operation ID before resubmitting.
Example: from channel decline to investigation ticket
The report confirms a decline among covered channels and links the result table. A landing-page change may be related, but causation is unproven, so it remains a hypothesis. The agent drafts a ticket containing the observation, sources, gaps, and suggested checks.
After approval, the gateway creates the ticket and reads back its ID and status. If the call times out, it checks whether the logical operation already succeeded. Creating the ticket does not resolve the incident and does not authorize a budget change.
Feedback needs governance too
Acceptance, editing, sharing, export, action success, and business outcome are different signals. A thumbs-up measures experience, not truth. A metric-definition correction requires a semantic owner; a confirmed factual failure belongs in regression. Sensitive feedback examples need minimization and access control.
Measure evidence support for material claims, artifact access success for intended users, recomputation under stated conditions, confirmed success of authorized actions, duplicate effects, and unknown outcomes. Do not attribute business improvement to the agent without a baseline and comparison design.
A safe progression is verifiable read-only artifacts, then templated delivery and feedback, and finally controlled actions. Final prose cannot remove unknowns created upstream. Good delivery makes limits, ownership, and next steps as clear as the conclusion.