Semantic Graphs Explain the Request—Execution Graphs Constrain What the Agent May Do

Agent frameworks increasingly expose workflows as graphs. Nodes call models or tools, edges control routing, and persisted state makes long-running work resumable. At first glance, Abstract Meaning Representation seems made for this moment: it also turns language into a graph.

But the two graphs answer different questions.

AMR describes meaning. An execution graph prescribes computation. Connecting them requires a compiler boundary, not a shared diagram format.

AMR Is a Semantic Graph

Abstract Meaning Representation converts a sentence into concepts and relations while abstracting away from much of its surface wording. For a request such as:

Review the contract, and if the renewal clause is risky, ask legal for approval before sending the response.

An AMR-like analysis can expose the important semantic structure:

review
├── ARG0: agent
├── ARG1: contract
└── purpose/condition
    ├── assess: renewal clause
    ├── property: risky
    ├── request: approval
    └── precedes: send response

This is useful because the system no longer has to infer every entity and relation from an unstructured prompt at every step. Yet the graph remains a representation of what the instruction means. It does not define a legal production process.

AMR itself is symbolic. The parser that proposes an AMR graph may be probabilistic, and several interpretations may be plausible, but the selected graph is normally represented as discrete concepts and labeled relations.

Execution Graphs Are Programs

An execution graph has operational semantics. In LangGraph, state is the current application snapshot, nodes perform work or side effects, and edges determine which node executes next. Microsoft AutoGen’s GraphFlow similarly uses directed graphs to control sequential, parallel, conditional and looping agent interactions.

The contract example might become:

START
  → resolve_contract
  → retrieve_current_version
  → analyze_renewal_clause
  → validate_analysis
  → [risk_high?]
       yes → legal_approval → compose_response
       no  → compose_response
  → final_review
  → send_response
  → END

Unlike the semantic graph, every node needs an implementation contract. Every edge needs a routing condition. External actions need permissions, idempotency rules and observable outcomes. Interrupts need persisted state so a human can approve the exact artifact that will continue through the graph.

Calling both structures “graphs” does not make them interchangeable.

The Missing Layer Is a Compiler

The valuable architecture is not:

natural language → AMR → execute

It is:

natural language
→ probabilistic semantic parse
→ normalized intent graph
→ entity and policy resolution
→ candidate execution graph
→ static validation
→ approved executable plan
→ runtime with checkpoints and guards

The compiler maps semantic predicates to capabilities registered by the production system. review-01 may map to a document-analysis node. approve-01 may require a human interrupt assigned to a particular legal role. A temporal relation such as “before” becomes an ordering constraint. A condition becomes a guarded edge only after the system defines how that condition will be evaluated.

Anything that cannot be grounded should remain unresolved. The model must not silently invent a tool, permission or state transition merely because the sentence implies an action.

Four Graphs, Four Responsibilities

A robust agentic architecture may use several graph-shaped structures simultaneously:

The semantic graph says that approval is required. The knowledge graph resolves which contract, policy and approver are relevant. The execution graph places an approval node before publication. The run graph records who approved which version and what happened next.

Collapsing these views creates subtle failures. A parser output is not authoritative domain state. A knowledge-graph edge is not automatically executable. A workflow definition is not evidence that a step actually ran.

Where the Model Should Remain Probabilistic

Models are valuable where the system must interpret language, compare ambiguous evidence or propose a plan. They can:

• generate candidate AMR or intent structures;
• resolve likely references for later validation;
• suggest an execution subgraph from an approved node library;
• classify a clause or tool result; and
• explain why a routing condition may apply.

The surrounding architecture should own the invariants:

• node and tool allowlists;
• input and output schemas;
• permission checks;
• maximum loops and budgets;
• approval boundaries;
• state-transition preconditions; and
• acceptance of external side effects.

This follows the broader production principle: the model proposes; the system decides what becomes executable and what becomes true.

Static Checks Before Runtime

Treating the generated workflow as an intermediate representation makes familiar engineering checks possible. Before execution, validate that:

1. every node resolves to a registered capability;
2. every edge has a defined activation rule;
3. side-effecting nodes have authorization and idempotency behavior;
4. cycles have explicit exit conditions and budgets;
5. required approvals dominate the protected action;
6. sensitive values cannot reach prohibited tools; and
7. the graph has valid start, completion and failure paths.

Framework compilation can catch structural problems such as orphaned nodes. Domain compilation must go further: it checks whether this particular plan is permitted for this user, entity and current world state.

Why This Is Graph Engineering

The emerging opportunity is larger than selecting a graph-based agent framework. It is graph engineering across representations: translating meaning into candidates, grounding candidates in domain truth, compiling them into bounded execution and recording the resulting run.

AMR contributes a useful semantic intermediate representation, especially when roles, negation, conditions or temporal relations matter. Execution graphs contribute explicit control flow, persistence and inspection. Knowledge graphs contribute identity, provenance and policy context.

Together they produce an agent architecture in which natural language can shape a workflow without becoming executable authority by itself.