How to Set Up an Agentic SDLC with Graph Engineering (2026)

TL;DR for busy founders

• Graph engineering → nodes, edges, shared state; layer above prompt and loop.
• AGENTS.md → topology for two pairs, Watchdog, and needs:human.
• Issue pair → Steward plans and sends work; Curator investigates and closes.
• PR pair → Builder and Guardian babysit the PR until Guardian merges.
• Ready now → Cursor Cloud Agents. Not ready → the same graph on local Qwen.

---

What is graph engineering for an agentic SDLC?

Graph engineering is how you design coordination among agents, tools, validators, and a human—not how you word one prompt.

In mid-2026 the industry moved from “loop engineering” to graphs after a simple question from Peter Steinberger: are we still talking loops, or did we shift to graphs? A useful graph still contains loops. The shift is from one autonomous worker to the wiring between many kinds of work.

This is not GraphRAG and not a knowledge graph. Those store facts. Agent graph engineering stores control flow: who may run next, with what state, and when the system must stop.

I built this graph from scratch for solo-founder constraints: two autonomous pairs, plus a stop a mobile agent can resume.

How is a graph different from a prompt or a loop?

A prompt lives inside a node. A loop is one node asking “continue or stop?” A graph asks “which node runs next, with what evidence?”

Use this split:

Layer	Question it answers	Where it lives
Prompt	How does this worker think on one turn?	Inside a node
Loop	Should this worker keep going?	One agent cycle
Graph	Who runs next, with what state, under which stop?	AGENTS.md + runtime

Stay on one loop when one agent can own a short, linear task with a clear checker. Move to a graph when work branches: issues and PRs in parallel, a verifier with real authority, failures that need different recovery, or a human gate that must pause and resume.

What belongs in AGENTS.md?

AGENTS.md is the topology file for the graph. It is not a prompt cookbook.

Put contracts in the file: roles, edges, events, stop label, and deploy. Leave model-specific prompt tricks out. Cursor, Codex, and other agents already read AGENTS.md as repo guidance.

A minimal skeleton:

# AGENTS.md

## Graph
Two autonomous pairs, one graph. Helpers are not a fifth SDLC role.
CI is evidence, not an actor.

## Issue pair
- Steward: plan, prioritize, send jobs to Builder.
- Curator: investigate, complete the issue.

## PR pair
- Builder: implement on a branch.
- Guardian: review like an author/reviewer pair; merge when requirements pass.

## Watchdog
Scheduled reconciler. Keeps approved work moving.
Does not start every cycle.

## Human gate
On `needs:human`: stop, notify the mobile agent, summarize and debate
with the supervisor, then the mobile agent resumes.
Humans do not poke the loop directly.

## Events (create ≠ approve ≠ start)
1. Create / pack ready
2. Product approved
3. Start the run

## Deploy
Staging is `main`. After merge, Steward QAs staging.
Prod is tag + release.

Create, approve, and start are three different events. Do not start a Builder from a “Planned” issue. Do not treat “I filed a ticket” as approval.

What does each subagent do in the graph?

Each named node has one job. If two nodes always share all context, merge them.

• Steward — plans and prioritizes the issue, sends the job to Builder, then QAs staging after merge.
• Curator — investigates and completes the issue. Owns the issue record, not the PR.
• Builder — implements on a branch. Babysits the PR with Guardian.
• Guardian — reviews and merges when requirements pass. Same session repairs; do not spawn a second Guardian.
• Watchdog — scheduled reconciler for approved work that stalled. It does not kick off every cycle.
• Mobile agent — agent in the mobile chat. On needs:human it notifies, debates the next step with the supervisor, then resumes. Not a “phone agent.”
• Helpers — subagents any of the four can spawn for research or chores. They are not SDLC roles.

An optional observer can tighten checks from shipped work, bugs, and human eval. Add it after the two pairs fly.

How do the two pairs run together?

The issue pair and the PR pair run as peers. It is not Curator then Builder then Guardian then Steward as a conveyor.

Steward sends a job to Builder. Builder and Guardian loop on the PR like author and reviewer until Guardian merges. After merge, Steward QAs on staging (main). Production is a tag and a release.

Each of the four can spawn helpers and should have a cloud env for tests and a browser (localhost before merge, staging after).

The whole loop knows it may need a human (secrets, payments, product judgment). The stop label is needs:human. Freeze, notify the mobile agent, debate, then that agent resumes.

Where can you implement this graph in 2026?

Cursor Cloud Agents are ready to implement or try this graph. A local Qwen stack is not ready to host the same topology.

Cursor Cloud Agents run in isolated VMs with a full dev env, parallel runs, AGENTS.md, pull requests, computer and browser use, MCP, automations, and a mobile/web surface that can resume work. That matches isolated envs per role, a Watchdog, and a mobile agent.

Local Qwen (Ollama plus Continue, Cline, or Aider) is the right tool for private autocomplete and short loops. It lives on one machine. The laptop sleeping kills the graph. You do not get four isolated cloud envs, durable PR babysitting, or a mobile resume path. Tool-use still lags frontier cloud on long-horizon agent jobs. See the local coding stack guide for what local is good at.

Need	Cursor Cloud Agents	Local Qwen	Codex cloud
Isolated env per role	Ready	One machine	Sandbox per task
Two-pair topology	You define it in AGENTS.md	Fragile	One delegated worker
PR merge loop	Ready	Manual	Native PR strength
Browser / E2E	Computer use	Laptop-bound	Limited
Mobile resume	iOS / web agents	No	ChatGPT app, not this graph
Watchdog	Automations	You run cron	Not this topology
This SDLC graph	Ready to try	Not ready	Partial

Codex is strong as one async worker that returns PRs. It is not a drop-in two-pair graph. For IDE vs delegated cloud, see Cursor vs Codex.

How do you adapt this setup to your constraints?

Keep the two pairs and needs:human. Cut everything your runtime cannot honestly support.

Solo founder, Cursor Cloud already paid. Run the full graph. One Steward/Curator pair and one Builder/Guardian pair. Watchdog on a weekday schedule. Mobile agent for the gate.

You live in the editor. Keep Cursor local Agent for taste and architecture. Send only approved jobs to cloud Builder/Guardian. Hybrid is normal; see the Cursor vs Codex split.

Privacy / air-gapped. Use local Qwen for reads and small edits. Do not pretend four cloud workers fit on one GPU. Shrink to one local loop plus a human merge. Revisit the graph when you have isolated envs.

No mobile chat. Keep the stop, but the notifier has to be Slack, email, or the cloud agent inbox. The rule stays: the supervisor debates, then an agent resumes—humans do not click “continue” inside the worker.

Team, not solo. Same topology. Add owners on edges (who may approve product, who may merge). Do not add a fifth SDLC role for every new hire. Helpers scale; roles should not.

CI is already strict. Keep CI as evidence Guardian reads. Do not make CI an agent.

If the constraint is “we need this wired to our repo, labels, and deploy,” that is implementation work, not another blog post.

How do you get this graph implemented for your repo?

Book a call if you want this graph adapted to your constraints and installed—AGENTS.md, pair roles, Watchdog, and the human gate—not a generic agent demo.

I implement this as a service: map your issue/PR flow, write the topology, and hook it to a runtime that can actually run it (today that is Cursor Cloud Agents for the full graph). You keep the repo.

Book a call or see services if you want the scoped version first.

Action step: copy the AGENTS.md skeleton into one repo. Name the two pairs. Run one real issue on Cursor Cloud Agents. Do not start by installing local Qwen as the graph runtime.