Two agent tasks can both start at 10:00. One may be the other’s prerequisite. They may be independent. One may have read a task state that the other later replaced. A third may have been queued in response to a result that neither task knew about at the moment it began.
A timestamped log alone cannot explain the difference.
This is the central observability challenge for parallel agent systems. When several workers research, plan, use tools, hand off artifacts, and react to updates, chronological order is useful but incomplete. To review a decision, recover after a failure, or apply a user correction, a team needs to know the relationships among those events.
The question is not only “What happened next?”
What work caused this action, what state did it depend on, and what becomes stale if that state changes?
Observability needs causal information
Distributed tracing already addresses a version of this problem. OpenTelemetry’s context-propagation documentation describes how trace context can correlate work across arbitrarily distributed services and process boundaries. A parent operation can propagate a trace and span identifier to a downstream operation so that the end-to-end flow remains visible.
The model becomes especially useful when work is asynchronous. OpenTelemetry’s tracing documentation explains that span links can associate causally related operations across traces, including queued asynchronous work whose start time cannot be predicted.
Agent systems have the same shape:
- a planner delegates independent research;
- a queued task begins after an earlier task produced evidence;
- a reviewer receives an artifact from a worker that has already finished;
- a user correction changes the governing task state while parallel work is active; or
- an agent prepares a proposed effect whose origin lies in more than one prior task.
None of these relations are visible from time alone. A late event may depend on an earlier state version. A current event may be causally linked to work that began much earlier. Two tasks may overlap in time while being independent enough to merge without conflict.
The Causal Task Record
The Causal Task Record is a proposed minimal record for each meaningful work unit in an agent workflow. It is not a full transcript, a model-reasoning trace, or a mechanism for storing raw sensitive inputs. It is a durable description of why the unit exists and what it depends on.
- Record element: Work identity — Question it answers: Which task, subtask, or review unit is this? — Why it matters: Lets systems link work without relying on title text or timestamps
- Record element: Purpose — Question it answers: What bounded outcome was this unit meant to contribute? — Why it matters: Distinguishes a useful dependency from incidental activity
- Record element: Parent or trigger — Question it answers: Which user request, task, event, or decision caused the unit to begin? — Why it matters: Preserves direct causal origin
- Record element: Dependency links — Question it answers: Which prior artifacts, facts, task states, or decisions did it rely on? — Why it matters: Enables targeted revalidation when a predecessor changes
- Record element: State version — Question it answers: Which version of the governing task state did it read? — Why it matters: Prevents a later merge from treating a stale result as current
- Record element: Relationship type — Question it answers: Was this work a child, an asynchronous follow-on, an independent parallel branch, or a review? — Why it matters: Avoids forcing every relationship into a false hierarchy
- Record element: Effect lineage — Question it answers: Did this unit only observe, produce a draft, propose an effect, or reconcile an effect? — Why it matters: Connects action review to the work that justified it
- Record element: Outcome and disposition — Question it answers: What did the unit produce, and is it current, stale, partial, held, or superseded? — Why it matters: Makes later orchestration and user communication more honest
The record can point to a task state, artifact, or permitted evidence reference without copying the underlying private content. The goal is to preserve dependency meaning, not to retain everything an agent saw.
Why timestamps cannot carry the whole explanation
Timestamps answer when a system observed or emitted something. They do not necessarily answer:
- whether one task saw another task’s result;
- whether an artifact was based on a task state later replaced;
- whether two agents acted on the same prerequisite independently;
- which task should be re-run after a correction; or
- why a proposed effect entered the queue.
Chronology still helps show recorded order, subject to clock and collection semantics. Causal links add the dependency edges that explain whether that order matters.
Imagine two workers drafting alternatives. If neither depends on the other, their overlap is healthy parallelism. Now imagine a third worker synthesizes those alternatives and the user corrects a requirement that both drafts used. The synthesis is not merely a later timestamp. It is a dependent work unit and should be marked for revalidation, even if the drafts themselves are retained for inspection.
This is the same general idea behind event histories in durable systems. Temporal’s workflow-execution documentation explains that Workflow Commands request actions and that the Temporal Service records the actions it takes in response as Events in Event History. For agents, the useful extension is to retain the task-level relationship between the event, its parent decision, and the state it relied on.
Use parentage and links deliberately
Not every relationship should be called a parent-child relationship.
A child relationship is useful when a task directly delegates work and waits for it as part of the same bounded outcome. An asynchronous link is more accurate when one task produces a result that later triggers an independently scheduled follow-up. An evidence link is useful when a worker used an artifact but did not derive its mandate from that artifact. A review link connects a proposed result to the unit that evaluates it.
- Relationship: Parent-child — Use it when: The parent directly delegated a bounded subtask — Example: A planner asks a worker to verify one acceptance condition
- Relationship: Asynchronous follow-on — Use it when: Earlier work triggered later work without a live parent — Example: A queued review begins after a draft enters the review queue
- Relationship: Evidence dependency — Use it when: A task relied on an artifact or verified fact — Example: A synthesis uses a source package from a completed researcher
- Relationship: State dependency — Use it when: A task read the governing task version — Example: A worker follows the current objective and data boundary
- Relationship: Effect link — Use it when: A proposal or external result stems from prior work — Example: A change proposal is tied to the evidence and approval that justified it
Using different relationship types keeps the graph honest. The system does not need to expose this entire graph to every user. It needs enough structure that its review, recovery, and user-control surfaces can explain meaningful changes.
Make corrections and retries targeted
Causal history becomes most valuable when the task changes.
If a user corrects the objective, the system can traverse from the corrected task state to the work units that depended on it. Those units can be marked stale, held, or re-planned. Independent research that did not rely on the corrected condition can remain available.
If a tool result is invalidated, the system can identify which plans or effects used it. If a worker retries, the new attempt can be linked to the prior attempt without being mistaken for a separate task. If a handoff occurs, the successor can see the current branch, its dependencies, and its unresolved edges.
This does not require perfect causal reconstruction of every model token. It requires explicit references at the decision boundaries that change what an agent may claim or do next. Targeted revalidation also depends on sufficiently complete dependency records; when links are missing or uncertain, widen the revalidation set rather than assuming other work is unaffected.
Review the causal graph alongside the transcript
A causal work graph enables better questions:
- Which active work units still rely on an earlier task version?
- Which proposed effects have no current evidence or approval link?
- Which result is a duplicate follow-on rather than new work?
- Which subtask is blocked by a dependency outside its control?
- Can a reviewer explain why this result exists without reading a long transcript?
Useful measures include:
- Causal coverage: What share of consequential work units have a purpose, trigger, and dependency record?
- Orphaned-effect rate: How often does a proposed effect lack a current causal link to task state and evidence?
- Stale-dependency detection time: How quickly can the system identify work affected by a correction or invalidated artifact?
- Explanation time: How long does it take a reviewer to explain why a result exists and what it relied on?
These measures assess system reviewability, not model intelligence alone.
A practical adoption path
- Assign a durable identity to the root task and each consequential work unit.
- Record the task-state version and primary dependencies whenever a unit begins.
- Use explicit links for asynchronous follow-ons, evidence use, reviews, retries, and effects.
- Mark outputs with a current, stale, partial, held, or superseded disposition.
- When a task state changes, revalidate only the dependent region rather than restarting all work.
- Keep records minimal and privacy-conscious by storing references and categories instead of raw private prompts or payloads.
The result is not a more complicated transcript. It is a system that can account for parallel work when it matters.
A general lesson for parallel agent work
A reviewable agent workflow needs explicit dependency relationships alongside its chronological history. The Causal Task Record is a proposed educational framework, not a description of a shipped Virillio Code capability.
Sources and further reading
- Context propagation — OpenTelemetry — Context propagation links signals across process and service boundaries to build causal information about a distributed system.
- Traces — OpenTelemetry — Span context is immutable, and span links can associate causally related operations across traces, including queued asynchronous work.
- Workflow Execution — Temporal — Workflow Commands request actions, and the Temporal Service records the actions it takes in response as Events in Event History.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.