Andrew Ng's Agentic Design Patterns, Mapped to Graphs

Andrew Ng published reflection, tool use, planning, and multi-agent collaboration as design patterns for agentic workflows. His March 2024 post does not present them as an ordered progression from loop engineering to graph engineering. This article keeps his source claim intact and adds a separate implementation view: how we at AI Builder Club might place those patterns inside an agent graph.

The distinction matters because two widely shared X posts describe an Andrew Ng PDF that neither post links. Their loop-to-graph packaging can still prompt a useful architecture discussion, as long as it is labeled as someone else's synthesis rather than Ng's method.

What Ng actually published

In his March 2024 post, Ng called reflection, tool use, planning, and multi-agent collaboration "four design patterns for AI agentic workflows." He described agentic work as prompting an LLM multiple times so it can build toward a better result.

His reflection example also rules out a narrow one-node interpretation. Ng wrote that tools such as unit tests or web search can evaluate an output. He then described another implementation with a generator agent and a separate critic agent. Reflection can be a self-review cycle, a tool-backed evaluation cycle, or a collaboration between agents.

The current Agentic AI course teaches the same patterns alongside evaluation and error analysis. Its access language is specific: free auditors can watch course videos and participate in the community forum, while assessments, certificates, and project tools require Pro membership. The Pro description also names quizzes and interactive labs.

None of those sources calls the patterns steps, orders them as a maturity ladder, or identifies multi-agent collaboration with a graph. The loop-to-graph order below is our synthesis.

What we could verify about the PDF claims

The @0xCodila post says Ng released an 8-page PDF, while the @0xMovez post claims 12 pages and uses a different title. Neither post links a document hosted by Ng or DeepLearning.AI.

Our check was bounded. As of 2026-07-29, we found no primary-source graph engineering PDF in the sources listed for this article. That finding supports caution about these two claims; it does not prove that no document can exist anywhere.

The useful material is already available directly through Ng's design-pattern post, Agentic AI course, and later feedback-loop letter. Readers do not need an unlinked PDF claim to study them.

One possible mapping onto an agent graph

Ng's patterns describe capabilities and collaboration techniques. A graph describes execution structure through nodes, edges, routing, and state. The same pattern can have several graph implementations.

This table is an implementation menu, not a translation key. Tool use can change graph shape. Planning and routing solve related but different problems. Shared state has to be designed; it does not appear automatically when several agents collaborate.

Our loop-to-graph synthesis

For a workflow with one objective and one reliable stopping condition, a single worker loop may be enough. Reflection can improve that loop, and tools can provide external evidence without requiring a multi-agent system.

When a plan needs to survive across actions, persist it as inspectable state. Add conditional edges only where the execution path genuinely branches. Introduce a specialized agent when a role needs its own instructions, context, permissions, or evaluation criteria.

That order is our build recommendation. It is not Ng's sequence, and the patterns do not depend on it. A tool node can appear before reflection, a planner can work inside one loop, or two agents can collaborate in a simple fixed chain.

Deterministic transforms, tool calls, routers, and human checkpoints are all valid nodes. Agentic worker nodes that are intended to revise their output need a verifier and a stopping condition, but every node in a multi-agent graph does not have to be a loop.

Ng's later three-loop feedback model covers a separate question about how product feedback arrives at different cadences around a system.

How to choose an implementation

Keep the architecture small when one worker can own the task and its verifier. Tool calls can stay inside that worker if making them separate nodes adds no useful control or observability.

Use explicit graph structure when the path branches, a handoff must survive across runs, state needs inspection, or a human checkpoint controls what happens next. Multi-agent collaboration earns its cost when specialized roles have genuinely different context or evaluation criteria.

Define what passes and when retries stop for any node that produces iterative work. A deterministic transform or recorded human decision may need no loop; the graph or loop decision guide covers those tradeoffs in more detail.

Related Content

• Graph Engineering: The 2026 Guide - Nodes, edges, state, frameworks, and the cases where a graph earns its complexity.
• Graph or Loop: How to Decide - Architecture signals, costs, and failure modes.
• Graph Engineering with Claude Code - A practical implementation using subagents and explicit orchestration.
• Loop Engineering Guide - Verifiers, stopping conditions, and the feedback loop inside an agentic worker.

Start Here

Start with a task that already has a clear pass condition. Build one reliable worker, make its evidence visible, and add structure only when the next failure requires a branch, persistent state, or a specialized handoff.

The Loop Engineering course covers the worker-level discipline behind that foundation. AI Builder Club also publishes source-linked teardowns when new agent architecture claims spread faster than their receipts.

Join AI Builder Club