A run history records one business or workflow execution. A trace follows a request across model hops, tools and services. An audit log records attributable administrative or security-relevant changes. They overlap, but they are not substitutes.
Calling all three “logs” creates avoidable blind spots. The operator, business owner and security reviewer ask different questions and should receive evidence shaped for those questions.
Run history explains the unit of work
A run record begins with a trigger or user request and ends with a business-facing status. Useful fields include the automation or agent identifier, trigger type, start and finish time, ordered tool labels, result summary, error and correlation identifier.
The run is the unit a business operator recognizes. “The daily inbox triage failed” is a run-level statement. A run history should show whether it is waiting, succeeded, failed, partially completed or was manually recovered.
Skybridge records automation runs across scheduled, event and manual triggers. The history shows the actual tools used during that instance, because a tool-using agent does not always follow one fixed step graph.
A trace explains the technical path
A trace represents the path of a request through operations. OpenTelemetry defines a trace as a set of spans, where each span represents a unit of work and carries timing, status and attributes. See the OpenTelemetry trace documentation for the current model.
For an AI agent, one useful trace level is the model hop. Each hop can record duration, input and output tokens, cache use and the tool batch requested. Connector calls and downstream services can become child spans when the architecture supports end-to-end context propagation.
Tracing answers why a run took 48 seconds, which model hop consumed most tokens or where a timeout occurred. It may contain sensitive arguments, so collection, sampling, redaction and retention need deliberate limits.
An audit log explains attributable change
An audit log records who changed a workflow, connection, permission, approval or configuration, when the change occurred and what object was affected. It supports governance and incident reconstruction.
An audit entry that says a user edited an automation does not show what every later run processed. A trace of a connector call does not prove who granted the connection. The records can share identifiers and timestamps while retaining different schemas.
For approval-gated actions, an attributable human decision belongs in the audit model, while the connector attempt belongs in execution evidence. Keeping both prevents “approved” from being mistaken for “completed.”
Add cost and business status as separate views
Cost data is often derived from traces or usage events, but historical reconciliation needs a durable ledger. Live metrics can reset when a service restarts. Aggregate counters also lose the connection between spend and workload.
Business status deserves its own view because a technically successful request can still fail its purpose. A model may respond successfully while omitting the required record update. A connector may return success while the job remains pending downstream.
Skybridge connects run, trace, usage and approval evidence through common context. Operators can inspect the technical path without asking a business user to interpret raw telemetry.
Design an evidence map
For each record, define subject, reader, identifiers, content, retention and access:
| Record | Subject | Main reader | Typical retention question |
|---|---|---|---|
| Run history | One business execution | Operator or process owner | How long can work be replayed or investigated? |
| Trace | Technical request path | Engineer or SRE | How much detail is safe and affordable to keep? |
| Audit log | Attributable change or decision | Security or administrator | What period is required for review and investigation? |
| Cost ledger | Metered usage by owner and period | Finance or platform owner | Which source remains durable after deployments? |
Access should follow the data inside the record. A workflow editor does not automatically need full message bodies. A finance viewer may need cost totals without prompt content.
Use one correlation strategy
Generate a correlation identifier at the boundary where the business request enters. Carry it through the run record, model usage event, tool calls, approval proposal and downstream request where possible.
Do not place personal or secret data inside the identifier. It should be opaque and stable. If an external platform returns its own request or object identifier, store that as an associated field for reconciliation.
Clock consistency matters too. Use a common time basis and record durations separately from wall-clock timestamps. A five-minute clock skew can make a valid sequence look impossible during an incident.
Test the evidence with questions, not screenshots
Give an operator a failed hypothetical run and ask:
- What business request started it?
- Which version and environment handled it?
- Which model and tools ran, in order?
- Who approved the action and which payload did they see?
- Did the destination accept the side effect?
- What did the attempt cost?
- Which administrative change could explain the new behavior?
Every answer should point to an authoritative record. If the answer depends on reading uncorrelated console timestamps, the evidence model needs work.
Skybridge keeps the records distinct and connected
Skybridge uses durable run histories for automation work, per-hop agent traces for technical investigation, attributable records for permissions and approvals, and persistent usage data for cost. The exact retention and visibility follow the delivered system's data boundary.
The design goal is not maximum logging. It is sufficient, protected evidence for operation and review. Use the automation observability comparison to compare platform models, then the durable AI cost ledger for the financial record.
Continue reading: A complete state machine for human approval in AI systems.