The Graph from the Post

The LinkedIn post presents a “Full graph” architecture - a coding agent state machine built in LangGraph, based on a work methodology from Anthropic. Read these as executable transition systems - not process art. This is impressive work. But let me show what Amp already does natively.

START → INTAKE → SPEC → PLAN
  → STRATEGY → MILESTONE LOOP
  → CLOSE_OUT → QA
  → VERDICT → DONE
                     └── reopen ×2 ──┘

BRANCH → IMPLEMENT → TEST → GATE_A
  → E2E (only if has_ui) → GATE_B
  → PR → CI → MERGE

DEBUG (waits for human) → BRANCH

“Read it as a state machine, not a flowchart. Guards are evaluated in table order and exactly one must match.” — the post

What's Actually Being Built

The diagram isn't a flowchart — it's a finite state machine with guard conditions. Each transition is a guarded rule evaluated deterministically. This is serious engineering:

What the Code Actually Looks Like

Here's what a single node + guard from the milestone loop looks like in LangGraph:

class AgentState(TypedDict):
    request: str; spec: str; plan: list; strategy: str
    milestones: list; current: int; code: dict; tests: dict
    test_passed: bool; lint_errors: list; blocked: bool
    reopen_count: int; has_ui: bool; approved: bool; verdict: str

def implement_node(state: AgentState) -> AgentState:
    response = llm.invoke(build_prompt(state))
    state["code"] = dispatch_tools(response.tool_calls)
    return state

def branch_router(state: AgentState) -> str:
    if state["blocked"] and state["strategy"] == "debug": return "debug"
    if state["blocked"] and state["reopen_count"] < 2: return "reopen"
    if all_done(state): return "close_out"
    if state["strategy"] == "D": return "stop_early"
    return "implement"

graph.add_node("implement", implement_node)  # ...seven nodes here
graph.add_conditional_edges("branch", branch_router, routes)
app = graph.compile(checkpointer=PostgresSaver(conn))

Every Node in the Graph → Amp Built-in

Here's the key insight: every single node in the diagram has a native Amp equivalent that requires zero custom infrastructure.

How Amp's Tool Stack Replaces the Graph

No graph code needed. This is Amp's execution model:

USER REQUEST → AMP AGENT (MAIN THREAD)
  01 Read code     02 Plan       03 Review plan   04 Implement
  05 Test          06 Gate A     07 E2E / UI      08 Gate B
  09 Ship          10 CI         11 Verify        12 Report

  ┌── MULTI-AGENT ─────────────────────────────────────────┐
  │ create_thread → Task A │ Task B │ Task C               │
  │                    wait_for_threads → integrate         │
  └─────────────────────────────────────────────────────────┘
  ┌── HUMAN-IN-THE-LOOP ─────┐  ┌── SCHEDULING ───────────┐
  │ approval model            │  │ set_schedule            │
  │ user steering             │  │ update_schedule         │
  └───────────────────────────┘  └─────────────────────────┘

Oracle: A Smarter Gate Than Hand-Coded Rules

The GATE_A and GATE_B nodes use static guard conditions. Amp's oracle uses GPT-5.6 reasoning to review the actual diff.

def gate_a(s):
  if s["failed_tests"]: return "reject"
  if s["lint_errors"]: return "reject"
  if s["diff_lines"] > 500: return "review"
  return "pass"

# Knows only predefined failures.
# Cannot assess intent or architecture.

oracle(
  "Review this diff against the user's intent.
   Check semantics, architecture, race conditions,
   type safety, regressions, and missing tests.
   Return concrete findings with evidence."
)

# Reads the diff and reasons about what changed.
# Finds risks you did not know to encode.

The Milestone Loop Without the Loop

The graph processes milestones sequentially through the loop. Amp parallelizes them natively.

M1: IMPLEMENT→TEST→GATE→E2E→GATE→PR→CI→MERGE
M2: IMPLEMENT→TEST→GATE→E2E→GATE→PR→CI→MERGE
M3: IMPLEMENT→TEST→GATE→E2E→GATE→PR→CI→MERGE

create_thread(task="Milestone 1")
create_thread(task="Milestone 2")
create_thread(task="Milestone 3")
wait_for_threads(ids)
oracle("Review integrated result")

The DEBUG Node vs. Amp's Native Approval

The diagram says DEBUG “waits for a human.” Here's what that costs in LangGraph vs. what Amp gives for free:

def debug_node(state):
  ticket = notify_human(state, channel="slack")
  answer = wait_for_approval(ticket, timeout=86400)
  return process_response(state, answer)

Capabilities the Diagram Doesn't Cover

Amp has features the state machine doesn't even address:

Where the Graph Engineering Approach Still Wins

This isn't one-sided. The graph-based approach has real advantages in specific scenarios:

For Regulated-Industry Work

If working in regulated spaces, here's the decision matrix:

Complete Workflow: The Graph vs. Amp

Task: Implement a feature, test it, review it, and ship it.

class State(TypedDict):
  # 50 state fields

# 18 node functions
# 25 guard functions
# graph assembly and conditional edges
# checkpointer.compile()
# app.invoke(initial_state)
# ~500 lines of tests

# You ask for the feature, then Amp uses:
finder("Locate feature architecture")
read_file(paths)
oracle("Review implementation plan")
edit_file(...); create_file(...)
shell_command("run focused tests")
oracle("Gate A: review diff")
skill("ui-preview"); view_media(...)
oracle("Gate B: holistic review")
thread_interact("ship")

The Verdict

Complete Feature Comparison

Print this as a one-page decision matrix.