🔵 Fundamentals: the graph

The node is a thing of your world: a person, a task, a process step, an AI agent. In code, it appears as n or node.

Choosing what becomes a node is the first modeling decision—and the one people get wrong most often. If the node is too large, the graph doesn’t help at all; if it’s too small, you drown in detail.

Node = noun. A node has an identity (you can point to it) and can carry data (label, cost, owner, state).

The edge is the relationship between two nodes. In code, e or edge. “Depends on,” “becomes,” “knows,” “passes the result to.”

In an agent system, the edge is where the decision lives: “if approved, go here; if rejected, go back there.” And the value lies more in the edges than in the nodes.

An edge = a verb. It can have a type (typed edge), direction, and weight. A graph without edges is just a list of disconnected things.

In a graph directed, an edge has an arrow: it goes from A to B and doesn’t go back along that edge. In an undirected graph, the connection works in both directions (like friendship, for example).

Every agent workflow is directed: the researcher hands off to the writer, not the other way around. Direction is what gives the system order.

Directed = arrow = order. If you want to go back, that’s another edge (and it can have its own rule: “go back only if rejected”).

A number attached to the edge: minutes, dollars, tokens, probability, distance. That’s what turns a “drawing” into a “computable structure.”

Without weights, all you know is if you can proceed; with weights, you know which path is worthwhile. And that's where search and optimization come in.

Weight can represent cost (minimize) or gain (maximize). In an agent graph, the weight is usually latency, token cost, or confidence.

A path that leaves a node and returns to it. If a directed graph has no cycles, it is a DAG (directed acyclic graph).

This is the turning point of the entire course: a loop is a cycle. A loop is the simplest graph there is—one node with an edge that points back to itself.

DAG = no way back = ends on its own. With a cycle = can repeat = needs a stopping condition, or it runs forever.

A list = each item has one next item. A tree = each node has just one parent, with no cycles. A graph = anything can connect to anything. Lists and trees are special cases of graphs.

Many people draw a tree (epic → story → task) and think they've solved it—until a cross-branch dependency appears. That's when the tree becomes a graph.

If there's a cross-dependency, it's a graph. Don't force a tree onto a problem that's a graph — you'll only hide the real dependency.

Wake up → get up → brush your teeth → coffee. Each step is a node; the time between them is the edge weight (2 min, 5 min, 3 min).

And the smallest example that already shows everything: nodes, directed edges, weights in minutes — and an alternative path (someone brings you coffee in bed) that skips a node.

Modeling = choosing what is a node and what is a weight. An alternative path = another edge, not another graph.

Each person is a node; each relationship is a weighted edge (friendship, work, shared interests). “You are 3 connections away from Lucas” = 3 edges apart.

And the example that shows that the algorithm navigates the graph for deciding what to show you. The same idea applies to your agent navigating documentation.

Distance in edges = “degrees of separation.” Edge weight = strength of the connection. Recommendation = traversal with criteria.

Campaign → traffic → signup → activation → subscriber → churn → LTV. Nodes are customer states; edges are conversion rates.

And the example that exposes the course’s central problem: optimizing a an edge (lowering CAC) can worsen another (increasing churn) without anyone noticing.

One metric is never enough. The graph lets you see the side effect instead of only the main effect.

An epic contains stories, a story contains tasks, and a task contains subtasks. It looks like a tree — until one story depends on another. Then it becomes a graph.

This is how a PM decides how many people (or agents) can work in parallel: the graph shows which branches don’t block one another.

A dependency edge = a blocker. Independent branches = potential parallelism. Split up the task and design the graph so you don’t block anyone.

Instead of dumping dozens of files .md loose in folders, you link the documents to one another and specify the type of link (“prerequisite for,” “contradicts,” “details”).

The agent stops reading everything and starts navigate: enter through the right node and follow the relevant edges. Less context wasted, more precision.

Warning: this is knowledge graph, a cousin—but not a synonym—of graph engineering. Track 3 separates the two.

Module A imports B, B imports C. The npm, o make, your CI—both build a directed graph and determine the order from it.

It’s the closest example to what you’ll do with agents: the build already handles “what runs in parallel” and “what waits” exactly like a work graph.

Circular dependency = cycle = build error. The tool detects cycles — your agent graph will need to detect them too.

In breadth (BFS) you visit all the neighbors before going deeper; in depth (DFS) you follow one path all the way down before backtracking.

It’s the same choice you make with agents: scan many options shallowly (breadth) or pursue one path to the end (depth).

Breadth finds the closest one first. Depth finds a fast response. Mark who has already visited — otherwise a cycle becomes an infinite loop.

Find the lowest-cost route between two nodes by adding up the edge weights. The path with the fewest hops isn’t always the cheapest.

In an agent graph, the “cost” is tokens, latency, or risk. Choosing a route means choosing how much you'll spend to reach the same result.

Fewer edges ≠ lower cost. If the weight changes over time (API latency), the optimal path changes too.

A valid DAG execution queue: nothing runs before what it depends on. That’s what the make calculates.

It’s literally the scheduler for your agent graph: it tells you what can run now and what has to wait.

A topological order exists only if there are no cycles. If the algorithm can't order it, it has found a circular dependency.

How many nodes are ready at the same time. If two branches don’t block each other, two workers fit—two developers or two agents.

This is how you size the fleet: there’s no point launching 20 agents if the graph only releases 3 nodes at a time.

Parallelism is a property of the graph, not your enthusiasm. Break the task into parts that do not block each other increases the width.

B waits for A, A waits for B: no one moves. In an agent graph, this becomes routing that bounces back and forth between two nodes forever.

And one of the failure modes new that the graph provides and the loop didn’t have. It needs a repetition limit and explicit detection.

Every cycle needs an exit: an iteration limit, a progress criterion, or human approval. A cycle without an exit = an infinite bill.

In practice, a dictionary: for each node, the list of neighbors. {"pesquisa": ["escrita"], "escrita": ["revisao"]}.

Because this is how you’ll write your agent graph in JSON/YAML and hand it off to the orchestrator — without any framework if you don’t want one.

An adjacency list works for almost everything. Store the node data too (model, tools, prompt) — that’s what makes it a graph agentic.