Cómo montar un SDLC agéntico con graph engineering (2026)

TL;DR para fundadores ocupados

• Graph engineering → nodos, aristas, estado compartido; capa sobre prompt y loop.
• AGENTS.md → topología de dos pares, Watchdog y needs:human.
• Par de issues → Steward planifica y manda trabajo; Curator investiga y cierra.
• Par de PRs → Builder y Guardian cuidan el PR hasta que Guardian hace merge.
• Listo ahora → Cursor Cloud Agents. No listo → el mismo grafo en Qwen local.

---

¿Qué es graph engineering para un SDLC agéntico?

Graph engineering es cómo diseñas la coordinación entre agentes, tools, validadores y un humano—no cómo redactas un prompt.

A mediados de 2026 la industria pasó de “loop engineering” a grafos después de una pregunta simple de Peter Steinberger: ¿seguimos hablando de loops, o ya pasamos a grafos? Un grafo útil todavía contiene loops. El cambio es de un worker autónomo al cableado entre varios tipos de trabajo.

Esto no es GraphRAG ni un knowledge graph. Esos guardan hechos. El graph engineering de agentes guarda control flow: quién puede correr después, con qué estado, y cuándo el sistema debe parar.

Monté este grafo from scratch para constraints de founder solo: dos pares autónomos, más un stop que un mobile agent puede reanudar.

¿En qué se diferencia un grafo de un prompt o un loop?

Un prompt vive dentro de un nodo. Un loop es un nodo preguntando “¿sigo o paro?” Un grafo pregunta “¿qué nodo corre después, con qué evidencia?”

Usa este split:

Capa	Pregunta que responde	Dónde vive
Prompt	¿Cómo piensa este worker en un turno?	Dentro de un nodo
Loop	¿Este worker sigue?	Un ciclo de un agente
Grafo	¿Quién sigue, con qué estado, bajo qué stop?	AGENTS.md + runtime

Quédate en un loop cuando un agente puede hacerse cargo de una tarea corta y lineal con un checker claro. Pasa a grafo cuando el trabajo se ramifica: issues y PRs en paralelo, un verifier con autoridad real, fallos con recovery distinto, o un human gate que debe pausar y reanudar.

¿Qué va en AGENTS.md?

AGENTS.md es el archivo de topología del grafo. No es un cookbook de prompts.

Pon contratos: roles, aristas, eventos, label de stop y deploy. Deja afuera trucos de prompting por modelo. Cursor, Codex y otros agentes ya leen AGENTS.md como guía del repo.

Un esqueleto mínimo:

# 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.

Crear, aprobar y start son tres eventos distintos. No arranques un Builder desde un issue “Planned”. No trates “abrí un ticket” como approval.

¿Qué hace cada subagente en el grafo?

Cada nodo tiene un trabajo. Si dos nodos siempre comparten todo el contexto, júntalos.

• Steward — planifica y prioriza el issue, manda el job a Builder, y hace QA en staging después del merge.
• Curator — investiga y completa el issue. Es dueño del issue, no del PR.
• Builder — implementa en un branch. Cuida el PR con Guardian.
• Guardian — review y merge cuando pasan los requirements. Misma sesión repara; no spawnees un segundo Guardian.
• Watchdog — reconciliador programado para trabajo aprobado que se trabó. No arranca cada ciclo.
• Mobile agent — el agente en el chat mobile. En needs:human notifica, debate el siguiente paso con el supervisor, y reanuda. No es un “phone agent.”
• Helpers — subagentes que cualquiera de los cuatro puede spawnar. No son roles de SDLC.

Un observer opcional puede endurecer checks desde trabajo shipped, bugs y eval humana. Agrégalo cuando los dos pares ya vuelan.

¿Cómo corren juntos los dos pares?

El par de issues y el par de PRs corren como peers. No es Curator luego Builder luego Guardian luego Steward como cinta.

Steward manda un job a Builder. Builder y Guardian loopean el PR como autor y reviewer hasta que Guardian hace merge. Después del merge, Steward hace QA en staging (main). Production es un tag y un release.

Cada uno de los cuatro puede spawnar helpers y debería tener un cloud env para tests y browser (localhost antes del merge, staging después).

El loop entero sabe que puede necesitar un humano (secrets, pagos, juicio de producto). El stop es needs:human. Freeze, notifica al mobile agent, debate, y ese agente reanuda.

¿Dónde puedes implementar este grafo en 2026?

Cursor Cloud Agents están listos para implementar o probar este grafo. Un stack local con Qwen no está listo para la misma topología.

Cursor Cloud Agents corren en VMs aisladas con un dev env completo, runs en paralelo, AGENTS.md, pull requests, computer y browser use, MCP, automations, y una superficie mobile/web que puede reanudar. Eso calza con envs aislados por rol, un Watchdog y un mobile agent.

Qwen local (Ollama más Continue, Cline o Aider) es la herramienta correcta para autocomplete privado y loops cortos. Vive en una máquina. Si el laptop se duerme, el grafo muere. No tienes cuatro cloud envs aislados, babysitting durable del PR, ni resume mobile. El tool-use todavía pierde contra cloud frontier en jobs agénticos largos. Ver la guía de stack local para lo que local sí hace bien.

Necesidad	Cursor Cloud Agents	Qwen local	Codex cloud
Env aislado por rol	Listo	Una máquina	Sandbox por task
Topología de dos pares	La defines en AGENTS.md	Frágil	Un worker delegado
Loop de merge de PR	Listo	Manual	Fuerte en PRs
Browser / E2E	Computer use	Atado al laptop	Limitado
Resume mobile	iOS / web agents	No	App de ChatGPT, no este grafo
Watchdog	Automations	Tú corres cron	No esta topología
Este grafo de SDLC	Listo para probar	No listo	Parcial

Codex es fuerte como un worker async que devuelve PRs. No es un grafo de dos pares drop-in. Para IDE vs cloud delegado, ver Cursor vs Codex.

¿Cómo adaptas este setup a tus constraints?

Mantén los dos pares y needs:human. Corta lo que tu runtime no puede sostener.

Founder solo, Cursor Cloud ya pagado. Corre el grafo completo. Un par Steward/Curator y un par Builder/Guardian. Watchdog en horario de semana. Mobile agent para el gate.

Vives en el editor. Deja Cursor local Agent para gusto y arquitectura. Manda a cloud Builder/Guardian solo jobs aprobados. El híbrido es normal; ver el split Cursor vs Codex.

Privacy / air-gapped. Usa Qwen local para lecturas y edits chicos. No finjas cuatro workers cloud en una GPU. Achica a un loop local más merge humano. Vuelve al grafo cuando tengas envs aislados.

Sin chat mobile. Mantén el stop, pero el notifier tiene que ser Slack, email o el inbox del cloud agent. La regla sigue: el supervisor debate, y un agente reanuda—los humanos no pican “continue” dentro del worker.

Equipo, no solo. Misma topología. Agrega owners en las aristas (quién aprueba producto, quién hace merge). No agregues un quinto rol de SDLC por cada hire. Los helpers escalan; los roles no.

CI ya es estricto. Deja CI como evidencia que Guardian lee. No conviertas CI en un agente.

Si el constraint es “necesitamos esto cableado a nuestro repo, labels y deploy,” eso es implementación, no otro post.

¿Cómo encargas la implementación de este grafo?

Reserva una call si quieres este grafo adaptado a tus constraints e instalado—AGENTS.md, roles de los pares, Watchdog y el human gate—no un demo genérico de agentes.

Lo implemento como servicio: mapear tu flujo de issues/PRs, escribir la topología y engancharla a un runtime que de verdad pueda correrla (hoy eso es Cursor Cloud Agents para el grafo completo). El repo sigue siendo tuyo.

Reservar una call o ver servicios si quieres primero la versión con scope.

Paso concreto: copia el esqueleto de AGENTS.md a un repo. Nombra los dos pares. Corre un issue real en Cursor Cloud Agents. No empieces instalando Qwen local como runtime del grafo.