# How I think about agentic work, part two: graphs > Source: > Published: 2026-11-04 00:00:00+00:00 Building · 4 Nov 2026 · 7 min · ~1.5k words # How I think about agentic work, part two: graphs How I structure agent work as a graph of plans, goals, tasks, and notes. 7:45 The audio didn't load. [Download the MP3](https://assets.markphelps.me/content/posts/agentic-work-part-two-graphs/audio/am_puck-02b9b04b4c2a5a05.mp3) instead. How I think about agentic work, part two: graphs 0:00 / 7:45 In [part one](https://markphelps.me/posts/agentic-work-part-one-loops/) I went over the loops I use to fix bugs, implement features, and build entire apps from a plan with agents. This one is about the shape I give the work itself. The mental model that works for me is to treat agent work as a directed acyclic graph (DAG): edges point one way, and following them never brings you back to where you started. I’m not the first to think of work like this, and this specific structure is heavily borrowed (stolen) from my friend and coworker [Michael Dwan](https://x.com/michaeldwan). I’ve since adapted his workflow and built my own set of skills and tools that follow a similar process but seem to work better for me. I’ve used this process on several projects now. ## The model Work you want agents to do fits a DAG well, because most of what you track when you organize work is dependencies. Plans, tasks, and notes are the nodes, and the top-level plan is the root. There are two kinds of edge. Parent and child edges say what belongs to what. Blocking edges say what has to finish before something else can start. A plan also can’t finish until everything under it has. Together those must never loop back on themselves: no task waiting on a task that waits on it, and no plan blocking its own child. That covers the bug fixes, features, and greenfield apps from part one. The vocabulary is small: `plans`, `goals`, `tasks`, and `notes`. ### Plans and goals Plans describe what you’re trying to build or accomplish: a feature, a bug fix, or a plan of plans for an entire application. A plan is made up of tasks, other plans, or both, in a parent and child relationship. A plan with anything under it is never worked directly; the work happens in its children. Nesting plans is how I break down a larger project: the parent plan splits the work into sub-plans, and the ones that depend on each other run in order. Plans that don’t depend on each other can run in parallel, the same as tasks. Most important, a plan has to define how you’ll know it’s done. That matters more when agents write the code, because agents sometimes lie. Maybe lie isn’t the best word, but they overstate what they’ve completed and say something is done when it isn’t, or at least isn’t up to your standards. This is where goals come in. Every plan needs at least one before any work on it starts. I approve the top plan’s goals, and the fresh reviewer approves sub-plan goals during plan review. A goal captures what must be true for the plan to be complete and how to check it. Goals don’t need to be fancy. A checklist on the plan works. Once work starts, nobody changes the goals without me. Agents can rework the tasks however they need to, but if a goal turns out to be wrong, the run stops until I’m back to fix it. Every goal has to be met before the plan can close, and nothing the plan blocks can start until it does. ### Tasks and notes Tasks should be familiar from Linear, Jira, Notion, or most other project management tools. A task is one thing to do, small and focused by design. For example, “set up the data layer” isn’t a task in any non-trivial app. That’s a plan, with tasks under it like “choose a database” and “create table X”. If `task B` doesn’t depend on `task A`, both can be done at the same time, which helps a lot when an agent can hand tasks to subagents. Unlike plans, tasks don’t have goals. Tasks are less ambiguous and usually easy to check: it’s either implemented to spec and passes its checks, or it isn’t. Notes took me a while to appreciate. Unlike tasks, notes can’t be worked. They don’t describe a thing to do, at least not directly. They’re what the name implies: things noticed while executing tasks. If you haven’t looked under the hood lately, open a session in [AgentsView](https://www.agentsview.io/) or a similar tool and read what the agent outputs as it works. It’s constantly mentioning things that “look strange”, things to “keep in mind”, and things “we should get back to later”. Most of the time those observations are lost as the agent moves on to its next item and the context compacts. So the agent is instructed to capture anything that looks off as a note, along with anything that doesn’t fit the current scope but is worth coming back to. Like tasks, notes are filed under the plan the work belongs to. A note isn’t actionable on its own, but with a bit of planning it can become a task. Here’s the whole model on a made-up small app, much simpler than a real project. Solid lines are parent and child, dashed lines are blocking edges. ## Planning and verifying I think of planning in two stages: 1. Create a product requirements document (PRD) that defines what you want to build and how it should work, look, and feel at a high level. 2. Turn that PRD into plans, then break those into sub-plans and ultimately tasks. Plenty has been written about creating a PRD with AI. Some people prompt Claude directly, some use skills. I use both, with some back and forth between different models until a strong PRD shakes out. The graph comes in at stage two. In my experience, frontier models are very good at breaking a document into plans and tasks and ordering them so the dependencies come out right. Constraining them to the graph helps, because dependencies and blockers surface as the tasks get filed. I still wouldn’t one-shot this stage, because models can create tasks that are too high level or generic. So once the plan is filed, a fresh agent with zero context reviews it, walking the graph and asking two questions: 1. Could a fresh implementation agent execute this plan and its tasks without any additional context? 2. Can the finished work be verified against the goals, to prove it accomplishes the agreed outcome? If both answers are yes, the plan is accepted. Otherwise it needs changes and another fresh review. Verification comes once the work is done. A fresh agent that didn’t build anything rereads the plan and checks every goal against the finished work. By then, every task under it is already closed. The graph makes this quick, because it’s a walk through the plan and its sub-plans. Then it’s my turn. That’s the delivery step from [part one](https://markphelps.me/posts/agentic-work-part-one-loops/#on-the-loop), less code review and more execution review: does the software do what I wanted? I also go through every open note filed under the plan and decide what happens to each one: fix it now, plan it as more work here, split it off as separate work, or close it. That’s where the notes pay off. ## Leaf node If I could keep only one rule from all of this, it would be the one about goals: no plan closes until they’re met, and once work starts, they don’t change without a human. Next time I’ll get into the skills I use to run this workflow: what each one does, and where it hands off to the next. I’m making them public too.