Graph Engineering: Making the Connections Reliable

Module 4 · Lesson 7 of 8

Our event workflow looks sensible on paper. Then a venue search times out, the catering quote excludes delivery, and a reservation request loses its connection before returning a result.

The real design becomes visible when a step does not go as expected.

Engineer what each connection means

In this series, graph engineering means designing and maintaining the workflow graph of an AI system: its steps, connections, information, and execution rules. The term is used in different ways, so this is our working definition.

An arrow from “compare” to “book” is incomplete. Does it mean a recommendation is enough to book? Does approval have to name a specific venue and price? What happens if that price changes?

For our event, the rule can be concrete: a booking request must match an approved proposal, and a changed price returns to review. The graph expresses that requirement; execution checks must enforce it.

Decide what each step promises

A venue-search step should return either usable candidates or a clear result such as “no match” or “service unavailable.” Those outcomes lead to different next steps.

The budget step should receive all required cost categories. It should identify missing amounts rather than pretend that partial information is a complete total. These input and output expectations are sometimes called a contract.

Retries should match the problem

A brief service outage may justify trying again after a delay. A venue that is fully booked requires a different choice. Asking the same unavailable venue repeatedly does not repair the problem.

Set a retry limit and a fallback. For example, after a small number of unsuccessful directory requests, return the known candidates and explain that availability could not be confirmed.

Timeouts and retry policies are explicit runtime mechanisms; a framework example is LangGraph fault tolerance.

A missing response does not prove an action failed

Suppose the booking service creates a reservation, but the response is lost. Blindly repeating the request might create a second reservation.

A unique request identifier can let a supporting service recognize the same operation. This is one use of idempotency: repeating the request does not create an additional effect. If the service does not support it, the workflow may need to look up the reservation status or ask for help before trying again.

Saved progress needs careful recovery

A checkpoint saves enough state to resume work. After an interruption, the system might recover its shortlist and approval record. But a saved record is not proof that an external venue is still available.

Recovery therefore includes deciding which information remains valid and which external actions need reconciliation. Saving state alone cannot guarantee that every action happens exactly once.

For an implementation of checkpointed workflow state, see LangGraph persistence.

Test the journey and inspect the result

Try the normal case, no available venues, missing prices, rejected approval, changed quotes, and an uncertain booking result. Check both the answer and what the system actually did.

Record observable steps: tool requests, results, transitions, timings, and approval status. You do not need a transcript of private model reasoning to see that a booking happened before approval.

Measure task success, unsupported claims, prohibited actions, elapsed time, and cost. A polite final response can still conceal an incomplete task.

For evaluating agent behavior and outcomes, see Demystifying evals for AI agents.

---