Field Notes: AI Agents Are Learning to Manage Dependencies, Not Just Tasks

Most AI agent designs still treat work as a sequence: interpret the request, create a plan, call tools, and report completion. That model is adequate for isolated tasks. It is weak for operational work, where every action depends on conditions that may change while the agent is working.

A renewal proposal depends on current pricing, approved discount authority, accurate usage data, and the account owner’s strategy. A hiring workflow depends on an open requisition, a valid compensation band, interviewer availability, and candidate consent. Completing the visible task is not enough. The agent must know whether the foundations beneath it still hold.

The important change is that agents are beginning to treat dependencies as first-class operational objects rather than incidental context. This is not merely better planning. It changes when an agent may start, pause, invalidate, resume, or declare work complete.

What changed: dependencies moved into the execution layer

Earlier agent workflows commonly encoded prerequisites inside prompts or procedural checklists. The agent might be told to confirm inventory before promising a delivery date. That instruction helped, but the inventory value remained ordinary text: no expiry rule, no owner, no event subscription, and no explicit connection to the resulting commitment.

More capable orchestration patterns now represent the relationship itself. An action can be blocked by an approval, supported by a data snapshot, or invalidated by an event. The system can then react when that dependency changes.

Several technical developments made this practical:

• Structured tool outputs let agents consume status, version, timestamp, and source identifiers instead of extracting meaning from prose.
• Event-driven orchestration allows a workflow to respond when a record changes rather than repeatedly asking whether it changed.
• Durable execution lets an agent pause for hours or days without pretending one continuous model session owns the process.
• Explicit workflow state distinguishes waiting, blocked, invalidated, resumed, failed, and completed work.
• Provenance records connect an action to the evidence and approvals that justified it.

The practical advance is not that the model reasons longer. It is that the surrounding system preserves dependency state beyond a single inference.

The distinction operators need: inputs are not dependencies

An input helps produce an output. A dependency determines whether that output remains valid or whether an action may proceed. Confusing the two creates deceptively polished automation.

Consider an agent preparing purchase orders. The supplier address is an input. Available budget is a dependency. If the address changes after the draft is produced, the document needs an edit. If the budget is withdrawn after approval but before submission, the action must stop.

This classification prevents a common failure: checking every condition once at the beginning. Some facts only need to be read. Others must be true at the exact moment of action.

What this means in practice: plans become dependency graphs

A task list says what happens next. A dependency graph explains what must be true for each step to happen safely. The difference matters whenever work branches, waits, or crosses systems.

Suppose an agent is asked to launch a customer credit. A simplistic plan might read: validate request, create credit, notify customer, update account notes. A dependency-aware plan is more precise:

1. Verify that the requester is authorized for the account.
2. Confirm the invoice is eligible and has not already been credited.
3. Determine whether the amount falls within delegated authority.
4. If additional approval is required, pause with a bounded approval request.
5. Before issuing the credit, recheck invoice status and approval validity.
6. Create the credit using an idempotency key so a retry cannot duplicate it.
7. Confirm the ledger entry exists before notifying the customer.
8. Publish the outcome to downstream account records.

Several mechanisms are doing real work here. The second check closes the gap between validation and execution. The idempotency key protects against duplicate action after a timeout. The ledger confirmation separates an attempted tool call from a verified business result. Publishing the outcome prevents downstream teams from operating on stale assumptions.

The graph also reveals parallelism. Authorization and invoice eligibility may be checked simultaneously. Customer notification cannot begin until the credit is confirmed. Good dependency modeling therefore improves both safety and speed; it avoids sequential work where no true dependency exists.

The new failure mode: dependency drift

Once workflows last longer than a single interaction, dependencies can drift. An approval expires. A policy changes. A customer cancels. A source record is corrected. A human completes the step manually while the agent is paused.

The agent needs more than a generic instruction to “use current information.” It needs a revalidation policy tied to the consequence of drift.

Use validity windows deliberately

A shipping address may remain usable until the order is released. A fraud assessment may need to be refreshed immediately before a high-impact transaction. An approved message may remain valid only while its factual claims and audience are unchanged. There is no universal freshness interval; validity follows the business condition, not the age of the record alone.

Subscribe to decisive events

Polling every dependency wastes resources and still leaves gaps. Where possible, the workflow should listen for events that change executability: approval revoked, record locked, payment received, case closed, policy version replaced. Events should mark affected work for reevaluation rather than automatically restarting it.

Define invalidation scope

Not every change requires discarding the entire plan. If a recipient’s title changes, regenerate the salutation. If the contract amount changes, revisit approval, tax treatment, and payment terms. The system needs a map from changed dependency to affected decisions. Otherwise, agents either overreact by restarting everything or underreact by editing only the visible field.

How to build a dependency-aware control model

The minimum useful design is a dependency record attached to each consequential action. It should answer five questions:

• What condition matters? State it as a testable proposition, such as “invoice remains unpaid.”
• Who or what owns the truth? Name the authoritative system or accountable role.
• When must it be true? At planning, approval, execution, completion, or throughout.
• What invalidates it? Identify events, version changes, expiry, or conflicting evidence.
• What happens if it fails? Block, recompute, request approval, compensate, or escalate.

Operators should also distinguish read dependencies from write dependencies. Reading a customer tier influences a decision. Writing a refund changes shared state and may trigger accounting, notification, and reporting. Write dependencies require concurrency controls, duplicate protection, and outcome verification.

A useful execution rule is: verify late, but discover early. Identify dependencies while planning so the workflow can gather evidence and approvals efficiently. Recheck decisive conditions as close as possible to the irreversible action.

Where humans still belong

Dependency management does not remove judgment. It makes the location of judgment clearer. Humans are most valuable when the dependency is socially constructed, contested, or costly to encode.

For example, an executive’s verbal support may not equal formal budget approval. A customer’s lack of objection may not equal consent. A manager listed in a directory may not be the effective decision-maker during a reorganization. The system can expose these ambiguities, but converting them into authority is a governance decision.

Human review should focus on three cases: conflicting sources of truth, changes that alter the business bargain, and missing conditions for which no safe fallback exists. The escalation should name the blocked action, the dependency, the evidence already checked, and the smallest decision needed. Sending the entire workflow history merely transfers analysis back to the operator.

What remains unresolved

The hardest open problem is semantic dependency discovery. Systems can reliably track a declared link between an approval record and an action. They are less reliable at noticing an undeclared relationship, such as a campaign launch depending on an unresolved legal interpretation hidden in meeting notes.

Cross-system identity is another weakness. The same customer, contract, product, or employee may have different identifiers and ownership rules across tools. An agent can create a logically coherent graph that joins the wrong records. Entity resolution therefore remains part of operational control, not a data-cleaning afterthought.

Compensation is also uneven. Some actions can be reversed cleanly; a reservation can be cancelled. Others leave residue: a recipient may read an incorrect email, a supplier may begin work, or a public statement may be copied. Dependency-aware agents need to model not only rollback procedures but also irreversible external effects.

Finally, there is a governance question around inferred dependencies. If an agent suspects that a finance approval is needed, should it block work even when policy does not explicitly say so? A conservative system creates friction. A permissive one normalizes silent risk. The workable answer is usually tiered: enforce explicit dependencies, flag strongly inferred ones, and route recurring ambiguities into policy maintenance.

The operating test

To assess an agent workflow, do not ask only whether it can complete the happy path. Change one upstream condition while it is running. Revoke an approval, update a record, complete the task manually, or replace the governing policy. Then observe whether the agent detects the change, identifies the affected decisions, and resumes from the correct point without duplicating work.

An agent that understands a task can produce the next step. An agent that understands operations can explain what that step depends on, whether those conditions still hold, and what must happen when they do not.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.