Talk notes

Graph workflow: AppliedIn

Notes for a short talk on graph workflows for AI agents, using a job application tool as the working example. What a graph is, what each node should control, and where a person keeps authority.

Why this term, and why now

Graph is not a new word. Anyone who has touched data structures has met one, and AWS shipped Step Functions years ago. Every company with a standard operating procedure has been drawing graphs on paper for decades.

What changed is the models. They got capable enough that the harness around them matters more than the prompt inside them. The interesting question moved from what to say to how the work is arranged.

The engineering ladder

Each rung answered a complaint about the one below it.

prompt    say it well
context   feed it facts
skills    follow a fixed procedure
loops     here is a goal, work it out
graphs    some of each

A prompt had no facts. Context meant repeating the same procedure every time. A skill could not handle a job whose steps you cannot know in advance. A loop could, but total freedom leaves nowhere to put a rule and nowhere to stop.

A graph is the mixture: fixed order where the order is known, freedom where it is not. It does not replace the loop. It contains it.

AppliedIn is the example throughout: it finds postings, scores them, tailors a resume, and applies in a real browser. A good test case, because most of it is recoverable and one step is not.

What a graph is

A graph is a representation of the possible paths through a workflow. Three building blocks.

Nodes

Agents, tools, or deterministic operations. A step that does one job.

Edges

Where execution goes next. Fixed, or chosen from the state.

State

The information carried between steps, and what survives a pause.

Real workflows are rarely that linear. A low score should skip. A draft may need another pass. A submission may need approval. Once those decisions and pauses exist, drawing the graph pays for itself.

Job
 ↓
Score fit
 ├── Low fit  → Skip
 └── Good fit → Tailor resume
                  ↓
                Critic
                 ├── Needs work → Tailor again
                 └── Approved   → Ask human
                                  ↓
                              Browser apply
                               ├── Blocked → Ask human
                               └── Complete

How to read the diagram

The colours carry meaning throughout.

Legend: purple is an agent or LLM node, green is a tool or human node, red is a terminal stop node, a black arrow is an edge, a blue arrow is a loop edge, a dashed green arrow is state flow — Purple reasons. Green acts or asks. Red stops. Blue repeats. Dashed green is state moving between steps.

The AppliedIn graph

A deterministic outer flow with loops, branches and a human gate. Score, tailor, apply never changes. What varies is which edges fire.

The AppliedIn agentic graph: a scorer with structured output, a tailor and critic loop, an applier that delegates to a browser tool, an ask human long running tool, and state flowing underneath — One job in, one of several terminal states out. The arrows that go backwards are the design.

The scorer returns a typed score, not a paragraph, so nothing downstream has to read prose to decide what happens next. Below the threshold the job is skipped. Above it, the work moves on.

The applier delegates to a browser tool, and can call a long running tool to ask a person when blocked or before submitting. State runs underneath: the job, the resume, the score, the approved answers.

The bounded loop

Revision genuinely is a loop. The design work is the bound on it.

The tailor and critic loop, bounded at two iterations, with the critic validating alignment, truthfulness and bullet preservation — Two exits: the critic is satisfied, or the iteration cap is reached. Only one of those is the critic's decision.

The critic checks alignment, truthfulness and bullet preservation, and can end the loop early. It cannot create a third round. That cap is not a safety net you hope never fires. It fires.

What each node should control

For every node, five things are worth writing down before any code exists.

Responsibility

What is this node allowed to do?

Input and output

What state does it consume, and what structured state does it produce?

Routing

Which conditions determine the next node?

Failure behaviour

Does it retry, stop, skip, fall back, or ask a person?

Authority

Can it read data, change data, or take an irreversible action?

Authority is the one people skip, and it matters most:

The tailor can edit a resume draft but cannot submit an application.
The browser agent can fill a form but cannot invent an unknown answer.
The critic can request another edit but cannot loop indefinitely.
The human can approve submission.

Every one of those is a sentence you can check code against.

Properties of this graph

Key properties: deterministic outer flow with explicit branches, a bounded improvement loop, a human in the loop before irreversible actions, durable state for pause and resume, and deterministic validations — Five properties, and each one is a decision rather than an accident.

Deterministic guards

The model proposes. Code decides whether the proposal becomes an effect.

A check is not a gate until every path to the effect runs through it. Trace every route that reaches the action. If one goes around, it is a check.

What to take away

Graph engineering is deciding where the model may reason, where software must decide, where execution may repeat, and where a person must keep control.

A reliable agentic system is usually not one highly autonomous model. It is probabilistic reasoning where flexibility helps, deterministic checks where correctness matters, bounded loops, persistent state, and human gates before consequential actions.

The graph is not there to look sophisticated. It is there to make behaviour understandable, testable, recoverable and safe. That is the move from an agent demo to an agent system.