¿Pueden los agentes fusionar código?

No. Abren pull requests en borrador. Una persona revisa y fusiona cada cambio; nada se fusiona automáticamente.

¿Realized.dev aloja un modelo o runtime?

No. El trabajo se ejecuta en tus repositorios con Cursor y tus modelos.

¿Cuántos subagentes en paralelo?

Las ejecuciones locales están configuradas para ejecutar como máximo 8 subagentes a la vez. Esto no describe agentes en la nube.

¿Quién paga el uso de modelos?

Tú, directamente a tu proveedor. No añadimos margen sobre los tokens.

¿El harness es de código abierto?

Se está estudiando publicar el harness.

¿Dónde viven las especificaciones?

En docs/ de tu repositorio Git, junto a tareas y hallazgos.

Referencia · Arquitectura

Guía de arquitectura

Una referencia única sobre cómo se estructura la fábrica de software, qué hace y qué no hace cada capa, y cómo se corresponde con un engagement.

Actualizado el 12 de octubre de 2026

Definiciones

Fábrica de software: Agentes que escriben especificaciones, pruebas y código en tus repositorios, con reglas que exigen revisión humana antes de cualquier fusión.
Spec is Law: La especificación aceptada, no el modelo, tiene la autonomía. No se implementa nada sin una especificación aceptada y una prueba que falla.
El harness: El harness de Realized: comandos, reglas, subagentes, hooks que comprueban las acciones de los agentes y scripts de bootstrap para Cursor. Se está estudiando publicar el harness.
Engagement: Nuestro trabajo comercial por fases: Taller de descubrimiento, Piloto acotado, Engagement de realización.

Las cuatro capas

Capa	Qué hace	Qué no hace
L1 Sustrato de gobernanza	Comprobaciones de política y vinculación de identidad. Los agentes abren pull requests en borrador; una persona aprueba cada fusión.	Revertir significa deshacer la fusión.
L2 Actuación acotada	Llamadas a herramientas tipadas y con permisos sobre los sistemas de registro.	Diseñada para evitar escrituras libres.
L3 Malla de orquestación	Coordina los subagentes en el ciclo. Las ejecuciones locales están configuradas para ejecutar como máximo 8 subagentes a la vez.	Este ajuste describe solo subagentes locales, no agentes en la nube.
L4 Modelos	Los modelos que aportas, desde tu configuración de Cursor.	No incluimos modelo ni runtime ni guardamos credenciales en el repositorio.

Capa, ciclo y fase

Cada paso pertenece a una capa. El Taller de descubrimiento acota el ciclo, el Piloto acotado lo ejecuta de principio a fin para un flujo en un entorno, y el Engagement de realización lo amplía a más flujos.

Paso	Capa	Qué ocurre	Primera ejecución
Especificación	L1 Sustrato de gobernanza	Una persona escribe o aprueba el ticket y sus criterios de aceptación.	Taller de descubrimiento (alcance)
Tests primero	L2 Actuación acotada	El agente escribe pruebas que fallan a partir de esos criterios.	Piloto acotado
Ejecución del agente	L2 Actuación acotada	Un agente en la nube abre una pull request en borrador y después registra su trabajo en ella.	Piloto acotado
Comprobaciones automáticas	L3 Malla de orquestación	El agente ejecuta las pruebas antes de enviar los cambios y se realiza una comprobación de revisión de código sobre el cambio; los hallazgos se registran en la pull request.	Piloto acotado
QA	L3 Malla de orquestación	Un agente QA comprueba la vista previa y registra un veredicto listo o señalado en la pull request.	Piloto acotado
Aprobación humana	L1 Sustrato de gobernanza	Una persona revisa y aprueba cada fusión.	Piloto acotado

Flujo del harness

Especificaciones, tareas y hallazgos viven en docs/ de tu repositorio Git. Cada criterio de aceptación pasa por Red → Green → Refactor en subagentes separados: la prueba se escribe antes que el código que comprueba.

Los subagentes locales se ejecutan en oleadas de 8 como máximo. Los agentes abren pull requests en borrador. No pueden fusionar: una persona revisa y fusiona cada cambio, nada se fusiona automáticamente y revertir significa deshacer la fusión.

Dónde se ejecuta el trabajo

En tus propios repositorios y herramientas, con Cursor. Realized.dev no aloja runtime ni modelo. La traza de auditoría es tu historial de Git.

Modelo de costes

Aportas tus propios modelos. Tu proveedor de modelos te factura el uso directamente; no añadimos margen sobre los tokens. Nuestros honorarios están en la página de precios.

De dónde salen las cifras

Cifra	Tipo	Fuente
4 capas	Diseño	La arquitectura descrita en esta página.
8 subagentes a la vez	Ajuste configurado	Las ejecuciones locales están configuradas para ejecutar como máximo 8 subagentes a la vez. No describe agentes en la nube.
90 minutos	Formato fijo	Duración del Taller de descubrimiento.

Preguntas

¿Pueden los agentes fusionar código?: No. Abren pull requests en borrador. Una persona revisa y fusiona cada cambio; nada se fusiona automáticamente.
¿Cómo se revierte un cambio?: Deshaciendo la fusión en Git.
¿Realized.dev aloja un modelo o runtime?: No. El trabajo se ejecuta en tus repositorios con Cursor y tus modelos.
¿Cuántos subagentes en paralelo?: Las ejecuciones locales están configuradas para ejecutar como máximo 8 subagentes a la vez. Esto no describe agentes en la nube.
¿Quién paga el uso de modelos?: Tú, directamente a tu proveedor. No añadimos margen sobre los tokens.
¿El harness es de código abierto?: Se está estudiando publicar el harness.
¿Dónde viven las especificaciones?: En docs/ de tu repositorio Git, junto a tareas y hallazgos.

¿Quieres ver el ciclo en uno de tus flujos?

Reservar el taller de 90 minutos Referencia de seguridad y despliegue