A workflow run view and a run log view solve different problems. The run view helps users understand business execution: which steps ran, which paused, which failed, and what decision is needed. Run logs help builders and operators investigate the system underneath.
Run logs should answer lower-level questions. Was a job dispatched? Did a worker start? Did it complete? What failed? Was there a retry? Which workflow, run, step, and job does this event map to?
This matters because AI-assisted workflows combine business behavior with infrastructure behavior. A failed run might come from a tool error, model error, validation issue, worker problem, approval rejection, or bad workflow definition.
Without logs, operators often see only a red status. With logs, they can trace the execution path and decide whether to retry, cancel, fix configuration, adjust a tool, or change the workflow design.
Run logs should include status, errors, outputs, timings, worker activity, request IDs, and references to related records. They should preserve failed history instead of overwriting it during retries.
The logs should not replace the user-friendly workflow run view. Business users should not need to read worker events to approve a generated output. Builders and operators should have that lower-level view when they need to debug.
This split keeps the product approachable. The main workflow run screen can show an Airflow-style matrix of steps and runs, while the run log screen provides the operational trail behind a selected execution.
Run logs also help support the platform itself. When a customer reports that a workflow did not continue, the team needs to know whether the workflow was waiting for approval, a worker failed, a continuation job was created, or a retry was attempted.
Operational trust comes from being able to inspect the path after the fact. AgentGrid should make every meaningful execution event traceable without turning every user into a backend engineer.