The Commitment Graph: How AI Detects the Decisions Hidden Inside Conversation

Business decisions rarely arrive as clean records. They emerge through fragments: “Let’s use the existing vendor,” “Finance can absorb it this quarter,” “I’ll confirm with legal,” and “Assuming the launch stays in May.” Each sentence changes the operating reality, but none necessarily constitutes a complete, authorized decision.

An AI assistant that merely summarizes this exchange will miss the hard part. It must distinguish proposals from promises, conditions from facts, and apparent agreement from actual authorization. The useful internal model is not a transcript or a task list. It is a commitment graph: a structured representation of who has undertaken what, for whom, under which conditions, with which dependencies and evidence.

Why a Task List Is Not Enough

A task list records actions. A commitment graph records the obligations and decisions that make those actions legitimate. That distinction matters because identical actions can have different operational meanings.

Consider: “Maya will send the revised contract Friday.” This may be a firm commitment, a suggestion, a recap of an earlier agreement, or an instruction issued by someone without authority over Maya. A task extractor may create an assignment immediately. A commitment-aware system first asks what speech act occurred and whether its supporting conditions hold.

The graph preserves these differences rather than flattening them into unchecked boxes.

The Nodes: What the AI Must Represent

The basic unit is a claim about changed obligations or operating state. A robust commitment node needs more than a sentence. It should represent several fields, even when some remain unknown:

• Actor: the person, team, or system expected to act.
• Action or state: what must happen or become true.
• Beneficiary: the party to whom the commitment is owed.
• Authority basis: why the actor or speaker may make the commitment.
• Trigger: the event that activates the obligation.
• Conditions: facts that must remain true.
• Deadline: a date, event-relative boundary, or service window.
• Evidence: the source passage, document, or system event.
• Status: proposed, accepted, active, blocked, fulfilled, breached, withdrawn, or disputed.

These fields turn ambiguous language into inspectable operational state. If “after legal signs off” is captured as a condition rather than buried in notes, the AI can prevent downstream execution before approval arrives.

Nodes also need provenance. The model’s interpretation should never replace the original evidence. A reviewer must be able to move from “active commitment” back to the exact message, meeting statement, or signed artifact that supports it.

The Edges: Where Most of the Intelligence Lives

Commitments rarely stand alone. Edges encode relationships among them. One commitment may depend on another, supersede an earlier promise, conflict with a policy, delegate responsibility, or provide evidence that a condition has been met.

Suppose a launch conversation produces these statements:

1. Product commits to a May release.
2. Marketing commits to publish materials five business days before release.
3. Legal approval is required before publication.
4. Legal will review only after Product freezes claims.

A flat task list shows four items. The graph shows a dependency chain: Product’s claims freeze enables legal review; approval enables publication; publication timing depends on the final release date. If the release moves, the system can identify affected commitments rather than blindly shifting every date.

Useful edge types include depends on, blocks, fulfills, contradicts, supersedes, delegates, and evidences. Keeping these relations explicit lets the AI explain not only what is at risk, but why.

How Language Becomes a Commitment

The conversion process is best treated as staged inference, not one model call.

1. Detect candidate speech acts

The AI identifies language that may propose, accept, authorize, promise, cancel, delegate, or report completion. Grammar helps, but context dominates. “Fine” can be approval, resignation, or simple acknowledgment.

2. Resolve participants and references

Pronouns, team names, quoted speakers, and implied objects must be resolved. In “She approved it after his changes,” both people and the relevant version matter. Unresolved references should remain marked as uncertain rather than filled with a plausible guess.

3. Normalize time and conditions

“Next Friday,” “before launch,” and “once procurement clears it” become explicit temporal or event-based constraints. Event-relative deadlines should stay linked to the event; converting them prematurely to a calendar date creates errors when plans move.

4. Test authority and acceptance

A manager saying “Engineering will deliver Monday” is not necessarily evidence that Engineering accepted the obligation. The system should separate the speaker who asserted the commitment from the actor expected to perform it.

5. Reconcile with existing state

The new node may activate, modify, or conflict with an earlier one. “Actually, make it Thursday” is not an independent task; it likely supersedes a prior deadline. The AI needs conversational scope and graph history to make that determination.

A Worked Example: Conditional Approval

Imagine an executive writes: “Go ahead with the pilot. Keep it under the existing budget, and do not send customer data until security approves the environment. Priya can start vendor onboarding.”

A commitment graph might produce three connected objects:

• A pilot decision, authorized by the executive, active under an existing-budget constraint.
• A prohibition on transmitting customer data, active until security approval is evidenced.
• An onboarding authorization assigned to Priya, which may proceed independently of data transmission.

This representation prevents two common failures. First, the AI does not treat approval of the pilot as approval of every execution step. Second, it does not block all work merely because one protected action remains conditional.

If security later writes, “The environment passed review, excluding the analytics connector,” the system must avoid marking the broad condition as fully satisfied. It can activate data transmission only for the approved scope, or escalate because the original commitment did not define whether the connector is essential.

Failure Modes Under the Surface

The first failure is over-commitment: converting discussion into obligation. Brainstorming phrases such as “we could” or “why don’t we” should normally remain proposals until accepted.

The second is speaker-actor collapse. People routinely describe work that others are expected to perform. Without explicit acceptance or governing authority, assignment confidence should remain limited.

The third is condition loss. Summaries favor brevity and often preserve the approval while dropping “subject to,” “unless,” or “only if.” Those qualifiers frequently carry the risk.

The fourth is version drift. An approval may apply to a particular contract, forecast, design, or policy version. If the artifact changes materially, the supporting commitment may require reconfirmation.

The fifth is false fulfillment. A message saying “done” may indicate the sender completed their part, not that the promised outcome occurred. Verification may require a system event, recipient acceptance, or artifact inspection.

Operating Limits and Control Design

A commitment graph is an inference layer, not a legal oracle. It cannot reliably infer undisclosed authority, private side agreements, sarcasm, or organizational norms absent from its context. Even explicit language may be nonbinding under policy or law.

Controls should therefore scale with consequence. Low-risk internal follow-ups may be created automatically with visible provenance. Financial, legal, personnel, or customer-impacting commitments should require stronger evidence and, where appropriate, human confirmation.

The system should expose uncertainty by field. It may be highly confident that a deadline is Friday while uncertain whether the speaker could impose it. A single confidence score hides this distinction and encourages unsafe automation.

Deletion also requires care. Retracting a commitment should not erase its history. The graph should preserve that it existed, when it changed, who changed it, and which downstream actions relied on it.

Open Questions for Agent Design

Several design problems remain genuinely difficult. How long should an unconfirmed verbal commitment remain active? When does repeated behavior establish implied authority? Should silence after a meeting recap count as acceptance? How should the system handle cultures where disagreement is indirect?

There is also a boundary between assistance and surveillance. A system that continuously extracts promises can improve execution, but it can also create a punitive record from informal conversation. Organizations need explicit rules about visibility, contestability, retention, and which channels qualify as commitment-bearing.

The strongest implementation is not the one that extracts the most commitments. It is the one that preserves distinctions: discussion versus decision, assertion versus acceptance, approval versus permission to execute, and completion versus verified outcome. Under the surface, understanding a business conversation means tracking how words change obligations. The commitment graph makes that change visible, reviewable, and operational.

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.