How it works
Per-call attribution creates an identity and context envelope around each model or tool invocation. The record describes who initiated the call, which agent actually executed it, what authority applied, and which run, task, or parent call caused it. It should be emitted at the invocation boundary, where the harness still knows both the caller and the target.
A useful record usually connects:
- the run, task, and call identifiers
- the initiating operator, service, or agent
- the executing agent and its current role
- the parent call or delegation chain
- the model, tool, or operation invoked
- the permission scope or credential reference in effect
- the relevant policy decision, approval, or exception
- the input and output artifact references, including redacted or hashed forms when raw values should not be retained
- timestamps, outcome, and failure classification
The harness propagates this envelope through nested calls and creates a new record at every boundary. It does not copy one session owner onto all descendants. If identity, permissions, task purpose, or approval state changes, the new call records that change explicitly. This produces a causal chain that can be queried without treating the full transcript as the only source of truth.
Why it matters in an agent harness
A session can contain several materially different actors. An operator starts a run, an orchestrator delegates research, a worker retrieves context, and another worker invokes a write-capable tool. Calling all of this “the operator's session” erases the boundaries that determine responsibility and permitted behavior.
Per-call attribution makes those boundaries inspectable. When a tool changes state, the harness can show which agent requested the change, which policy allowed it, which credential was used, and which upstream decision led there. That supports incident analysis without requiring an operator to reconstruct causality from prose logs.
It also improves permission enforcement. A delegated worker should not inherit authority merely because its parent belongs to a privileged session. The harness can evaluate each invocation against the actor, purpose, permission scope, and approval state attached to that call. This helps expose confused-deputy failures, where a component with broader access performs work for a caller that was not entitled to request it.
Evaluation becomes more precise as well. A failed run may contain a sound planning call followed by an unsafe tool call, or a weak retrieval call that contaminates otherwise reasonable downstream work. Per-call records let evaluators isolate those decisions, compare paths across runs, and distinguish model behavior from orchestration or permission failures.
Attribution does not make an action safe by itself. It must connect to authoritative identity and policy data, and it must be durable enough to survive retries, resumptions, and partial failures. Otherwise it becomes decorative logging: detailed in appearance, but unable to support a control or recovery decision.
Per-call attribution vs session-level attribution
The distinction changes how much trust an operator can place in an audit record.
| Concern | Per-call attribution | Session-level attribution |
|---|---|---|
| Identity | Records the effective actor for each invocation | Assigns one identity to the broader session |
| Delegation | Preserves parent-child call relationships | Often collapses delegated work into the initiator |
| Permissions | Captures the scope applied at execution time | Suggests that session ownership implies authority |
| Diagnosis | Isolates the decision or call that failed | Requires reconstruction from aggregate logs |
| Cost | Produces more records and propagation work | Is simpler and cheaper to retain |
Session-level attribution is adequate for coarse usage accounting or navigation. It is not adequate when calls can cross permission boundaries, change external state, use different credentials, or delegate to agents with distinct roles. In those cases, the invocation is the unit that matters.
The Rifty take
We treat attribution as part of the control path, not an analytics feature added after execution. We accept the extra storage and propagation work because a state-changing call should remain attributable after delegation, retry, compaction, and recovery. If the harness cannot identify the effective actor and authority for a call, that call should not cross a consequential permission boundary.
Implementation checks
- Give every invocation a stable call ID and link it to its run, task, and parent call.
- Record both the initiating actor and the executing actor when they differ.
- Capture the effective permission scope and approval state at execution time, not only at session creation.
- Represent delegation as a chain rather than replacing the original actor with the latest worker.
- Keep attribution records durable across retries, resumptions, and process restarts.
- Prevent retries from creating misleading duplicate actions or disconnected attribution records.
- Store artifact references or integrity hashes when retaining raw prompts, outputs, or credentials would be unsafe.
- Make redaction visible so an operator knows which decision context is unavailable.
- Test nested delegation, credential changes, approval expiry, partial failure, and unknown outcomes.
- Reject or visibly block consequential calls when required attribution fields cannot be established.
Frequently asked questions
What should a per-call attribution record contain?
A per-call record should identify the run, task, invocation, initiating actor, executing actor, parent call, effective permission scope, invoked operation, policy or approval decision, outcome, and relevant artifact references. Retain enough context to explain the action while redacting secrets and sensitive payloads deliberately.
Is per-call attribution the same as agent tracing?
No. Agent tracing describes execution flow, timing, inputs, outputs, and dependencies, while per-call attribution establishes who acted and under which delegated authority. The two should connect through stable identifiers, but a detailed trace can still be inadequate if it assigns every action to one session owner.
How should attribution work for subagents?
Each subagent call should record both its immediate caller and its own effective identity, then link back through the delegation chain. Do not flatten the chain into the original operator. Permission checks should use the subagent's effective authority for that invocation, including any narrower scope imposed during delegation.
Does per-call attribution require storing full prompts and outputs?
No. Attribution requires durable decision context, not unrestricted transcript retention. A harness can store redacted summaries, artifact references, integrity hashes, policy inputs, and access-controlled payloads. The record must state when material context was omitted so operators do not mistake a partial account for a complete one.
What happens when the harness cannot determine the caller?
The call should be marked unattributed and prevented from crossing consequential permission boundaries. Assigning a plausible session identity would create a silent control failure. Read-only or low-risk handling may follow an explicit policy, but the missing identity must remain visible in the execution record.