The graph beneath the conversation

I recently read Graph-Based Agentic AI with LangGraph: Workflow Pathways for Long-Running Stateful Business Processes, a paper built around three small examples: a SQL agent that repairs failed queries, a retrieval system that checks its evidence, and a policy assistant that can pause for human review before continuing.

The paper is deliberately modest. It offers working examples and a guide for deciding when graph-based orchestration is useful, without claiming better accuracy, lower cost, or production reliability. As research, the contribution is fairly thin.

Still, one idea stayed with me. Pauses, retries, branches, and approvals are easier to understand when they exist as explicit parts of the system. A prompt can ask a model to be careful, but a workflow can record where the work stopped, why it stopped, and what must happen before it continues.

This connects directly to something I have only just started building: Hermes Relay.

Hermes is the agent system I already use every day. It can research, write code, delegate work to other machines, wait for authorization, recover from failures, and bring in a separate verifier before treating a result as complete. Until now, I have mostly interacted with it through Telegram.

Telegram has been useful, but only as a makeshift tool. It is built for messaging, not for supervising work that may continue for hours or days. Relay is meant to replace it with a control surface designed specifically for agentic work, where tasks, decisions, approvals, evidence, and interruptions have a clear place.

Most tasks still begin as conversations, but they stop behaving like conversations once they move through the system. A request may branch, return with a question, fail verification, and continue through a revised plan. The transcript preserves what was said, yet when I return two days later I still have to reconstruct the task before I can make the next decision.

That reconstruction is the part I want Relay to remove.

Chat works beautifully when the unit of interaction is a turn. I ask something, the model answers, and we continue.

Long-running agent work has a different shape. Imagine asking an agent to investigate a hardware purchase. It finds two viable options, verifies one, and discovers that the cheaper one has uncertain compatibility. It then asks whether price or certainty should guide the choice. Once I answer, it completes the research, produces a wiring plan, and checks the result.

A transcript records all of this as a sequence of messages, which means the current state can end up scattered across the history: the original goal may sit far above the latest reply, the criteria may have changed after a correction, and a verifier may have invalidated something that previously looked final.

That is the mismatch at the heart of chat. The conversation unfolds in time, but the task develops through cause and effect, as each decision changes the available routes, each authorization expands what the system may do, and each failed check sends the work back for revision. Those relationships determine what happens next, yet a transcript does little to reveal them.

This is why a very communicative agent can still feel opaque. More narration creates more material to search through, while the actual state of the work remains hidden inside it.

The LangGraph paper offers a useful threshold for adding structure. Durable workflow machinery becomes worthwhile when state must survive across steps, the next action depends on a branch, the process may pause for human review, or someone will later need to understand how it reached its current state.

That maps closely to how I want Relay to behave.

A quick question should remain a quick question. If I ask for a calculation, a status check, or an opinion on a paper, the answer can live comfortably in the conversation. Turning every exchange into a formal task would only make the interface heavier.

Structure becomes useful when the work needs to persist. Research that continues over time needs an identity. Delegated code work needs a clear owner. A protected action needs a recorded scope of authority. Any step that may have changed an external system needs proof of what happened and a safe way to recover.

This transition should be almost invisible. I should be able to keep talking to Hermes in the same way, while Relay quietly gives durable work a state, a history, and a place to return to. The interface should show me only what I need in order to understand the situation and act.

The user should never have to learn the internal model before the product becomes usable.

Graphs make sense to developers because they expose control flow. Most people have no reason to look at one while trying to make a decision on a phone.

The graph can stay underneath. The interface should translate it into something immediately understandable.

One concept I am exploring is the Cue, a full-screen handoff that appears only when Hermes needs human judgment. Instead of showing the entire history, it would explain the goal, describe what changed since my last interaction, and make the next decision clear.

The hardware example might return like this:

The supporting evidence should remain close without crowding the decision. I can open the comparison, sources, confidence level, commands, or receipts when I need them, but the first screen should make sense on its own.

The task history could become a Path made from the moments that actually changed the work: the original request, a new route, a human decision, a verifier objection, a recovery, or the final outcome. Routine tool activity can stay in the technical trace.

After a long absence, the Path should tell me how the task arrived here without forcing me to reread the conversation.

That clarity depends on strict state management underneath, so a Cue updates or disables itself when the task changes elsewhere, an interrupted task can tell whether retrying is safe, and every result remains connected to the exact attempt and evidence that produced it.

A calm interface is only possible when the system behind it is precise.

The examples in the paper all follow the same basic pattern: each workflow carries structured state, each step performs a limited job, and the system chooses what happens next by inspecting what has already happened. Retries, human review, and resuming after interruption are therefore part of the workflow rather than instructions buried in a prompt.

That makes the behaviour easier to inspect and easier to trust. When a SQL query fails, the system sends it through a repair route. When the available evidence is too weak, the answer cannot move forward until retrieval improves. When a case requires human judgment, the workflow pauses with enough state preserved for the person reviewing it to understand what they are deciding.

The same structure also makes failures easier to test. Instead of checking only the final answer, you can verify that weak evidence never reaches a confident conclusion, that retries eventually stop, and that a resumed review still contains the original work and the reviewer’s feedback.

The paper is equally sensible about when not to use graphs. A linear sequence should remain linear, and graphs only earn their complexity when branching, interruption, and durable state have become part of the product itself.

That restraint is probably its most useful contribution.

The paper’s three small workflows are useful because they isolate the basic mechanics, but they stop before the problems of running this kind of system in production begin.

An in-memory checkpoint can show how pause and resume work, but it disappears when the process restarts. Moving the state into a durable database fixes that problem while creating others, including competing updates, partial failures, and the need to recover cleanly when different parts of the system disagree.

External actions raise the stakes further. Imagine that an agent sends a payment request but never receives confirmation. Repeating the step could create a duplicate payment, while doing nothing could leave the task permanently uncertain. The workflow therefore needs a durable receipt and a way to check the external system before deciding whether to retry, reconcile, or ask for help.

My Hermes setup also spans several machines. The Mac Mini runs the always-on agent and Telegram gateway, while coding agents may work elsewhere inside isolated repository branches. A task can move between the orchestrator, a delegated worker, a verifier, and me. Relay needs to make that movement understandable without exposing all of the machinery behind it.

Authorization has its own boundary. A task can request permission for a protected action, but it cannot grant that permission to itself. Relay can show what is being requested, what it will affect, how long the permission lasts, and whether the action can be reversed. The actual authority must remain separate from the task asking for it.

Because Relay is only just taking shape, I want these boundaries to be clear from the beginning. Hermes already owns model sessions, runtime control, approvals, and agent execution. A graph library may eventually help inside a bounded service, but it should remain an implementation detail rather than becoming another source of truth.

Relay should open to a direct input area for new thoughts, links, or instructions. I call it Capture because its only job is to let me send something to Hermes quickly, without first choosing a project, creating a task, or understanding where the request will go.

If I share a link from another app, Relay should attach it to a new request and let me return to what I was doing. Brief conversations should remain conversational for as long as they can.

When Hermes needs me, a notification should open the exact task and the exact decision waiting for me. Within a few seconds, I should understand what the task is trying to achieve, what changed, and what Hermes needs from me. More detail should always be available, but understanding the first screen should never depend on opening it.

Protected actions should feel different because they carry different consequences. Their effect, scope, expiry, reversibility, and source of authority should stay visible while I decide.

Running work can remain quiet in the background. When I do choose to inspect it, Relay should offer only actions that the system can carry out honestly, such as adding guidance at the next safe point, requesting an interruption, stopping an attempt, or opening the task history.

Ordinary completions can settle into their projects without demanding attention. Failures, uncertainty, and real decisions deserve to interrupt me because my input can still change what happens next.

The moment I care about comes when I return to something Hermes and I were working on earlier and no longer remember the latest state or all the decisions that led there. Relay should restore that context in one clear view, showing what changed, why it matters, what Hermes recommends, and what my response would allow it to do next, so I can continue without reconstructing the entire conversation.

The LangGraph paper describes graphs as a way to make workflow behaviour inspectable, but the idea reaches beyond the framework itself.

An agent should be able to work without constant supervision and return with exactly the context a person needs to continue. That requires durable state, explicit transitions, causal history, and recovery paths that survive more than the happy path. Good interface design then turns all of that structure into a handoff that feels obvious.

Chat still matters. It is where intent arrives, where ideas develop, and where many useful exchanges can end. Durable work simply needs somewhere to live between those messages.

This is where agent UX becomes interesting. As the system becomes more capable, the interface should ask less from the person using it. It should hide internal complexity, preserve orientation, and make the next useful action easy to see.

The result may feel surprisingly uneventful: when I return to an older task, Relay should show me enough to understand where things stand and make the next decision without rereading the entire history.