Attio adds workflow history and an agent log for inspecting automation runs

Attio adds run-level history to a broader workflow push

Attio's September 23, 2026 changelog lists a new Workflow history and agent log feature with the description that teams now have full visibility into every run, down to the agent. The same release cycle also adds workflow blocks, Resend and ClickUp apps, and Ask Attio improvements. Attio's workflow product page separately describes triggers from record changes, schedules, webhooks and manual runs, plus branches, loops, fallbacks, custom JavaScript, App SDK extensions and MCP-connected blocks.

The operationally important change is not that more automation is possible. It is that a team can inspect a specific run after the workflow has acted. That helps RevOps distinguish a trigger problem from a data problem, an agent decision from a deterministic branch, and a failed external action from a workflow that never reached that step. Attio's announcement does not establish that a logged run was correct; it gives operators a better place to investigate why it behaved as it did.

Sources: Attio 2026 changelog · Attio workflows

A useful run record starts with the business trigger

A log becomes decision-grade only when the first record in the chain is stable. For a CRM workflow, preserve the record or object ID that triggered the run, the triggering event, the workflow version and the relevant source timestamp. If the trigger was a stage change, owner change or enrichment update, capture the before-and-after state that made the record eligible. Without that boundary, a detailed agent log can show many downstream steps while still leaving the original business reason ambiguous.

This matters when the same record can re-enter a workflow or when a rerun is allowed. A repeated run should carry a stable business-action key or another way to explain whether it represents a new customer state, a retry of the same state or an operator replay for investigation. Otherwise run history can become a list of technically valid executions that does not tell RevOps whether the customer or deal received duplicate work.

Separate what the agent read, decided and changed

Agentic workflows compress several layers into one interface. The model may read CRM fields, notes or connected application data, classify the situation, choose a branch and then call an action. RevOps should keep those layers distinct in review. The source evidence answers what was observed. The agent output answers what was inferred. The action record answers what the system attempted. A destination read answers what business state actually changed.

That separation makes incident review faster. If an owner assignment is wrong because the source territory was stale, changing the prompt is the wrong fix. If the source is correct but the agent selected an unsupported category, the interpretation layer needs attention. If the decision is valid and the destination rejected the write, the integration or permission boundary failed. One combined success or failure label hides exactly the distinction that run history is supposed to expose.

Rerun and pause controls need explicit semantics

Attio's workflow page says operators can pause workflows and rerun individual runs. Those controls are useful, but a rerun can be a new business action unless current state is checked first. Before replaying a workflow that writes to CRM, sends a message or calls another application, determine whether the original action already committed and whether the customer, owner, stage or permission state changed in the meantime.

For consequential actions, treat rerun as a proposal to re-evaluate, not permission to repeat blindly. Re-read material state, apply duplicate protection and preserve the relationship between the original run and replay. Pause behavior deserves the same precision: decide whether queued work drains, stops immediately, remains resumable or requires review. A visible pause button is a control surface; the operating contract is what makes it safe.

Permissions are part of the trace, not a setup detail

Attio says workflows inherit assigned user permissions. That makes identity part of the result. Record which user or service identity the workflow ran as and which external credentials were used for connected systems. A run that succeeded under an administrator may fail or expose too much information when reassigned to a narrower role. Testing only with the builder's access can therefore give a false picture of production behavior.

Use a least-privilege test user for a representative pilot and include one denied action. The desired result is not zero denials; it is an understandable denial that routes to the right owner without losing the run context. When a permission changes after a workflow begins, revalidate before a high-impact action rather than assuming the session's initial access remains appropriate.

What RevOps should measure after enabling the new history

Start with a small sample of successful, failed, retried and manually rerun workflows. For each, ask whether another operator can identify the triggering record, workflow version, source evidence, agent step, external action and verified final state. Record missing links by class. This creates a local traceability baseline without inventing a universal reliability score.

Then use the history to reduce repeated failure modes rather than to maximize automation volume. Track duplicate actions, stale-state holds, permission failures, external API errors, rejected agent outputs and unresolved runs. The feature is most valuable when it shortens the path from an exception to a concrete repair and lets a team prove what happened after the workflow left the CRM.