
From dependencies to execution
Graph engineering and orchestration: what an arrow means, which work can overlap, why a ready task still waits, what survives an interruption, and who decides a finished result can be used.
Graph engineering, dependency graphs and scheduling for multi-agent work: what can run, what waits and who decides it is done.

Graph engineering and orchestration: what an arrow means, which work can overlap, why a ready task still waits, what survives an interruption, and who decides a finished result can be used.

A valid model answer became a chatbot failure because its response format had changed. The repair shows how a small interface assumption can spread through a system—and how a work graph helps carry the change.

Choosing tools is not the end of design. After a graph-shaped way of working is available, something still has to hold the drawing, advance the pieces that are ready, and decide whether what came back was acceptable.

A dependency graph can expose eligible work, but it cannot schedule a worker, define material completion or grant human authority. Here is how to separate the DAG, node contracts, runtime and revision lifecycle.

A folder of documents is still crawling through its queue hours after the result stopped needing human attention. The delay is a quieter decision: each item waits, although the items do not depend on one another.

A recoverable orchestration system for multi-step production work, using dependency state, material evidence and human review to decide what can proceed.

A review-gated campaign workflow that keeps related creative work recoverable as dependencies, evidence, and decisions change.

A historical reasoning prototype separated per-request context from batch coordination while making its incomplete branching, persistence, and consensus boundaries explicit.

A persistent messaging layer for durable, searchable handoffs between independent working sessions.