Un agente puede escribir código, ejecutar pruebas y preparar un cambio completo. Pero si nadie le indicó dónde tiene que frenar, también puede tomar una decisión de producto, asumir un criterio de arquitectura y avanzar como si todo estuviera definido.
En Incu empezamos a usar Ways para abordar ese problema. No es un agente nuevo ni un reemplazo de las herramientas que ya usamos. Es una capa para hacer explícita, instalable y verificable la manera en que queremos que los agentes trabajen con nosotros.
La diferencia parece sutil hasta que la llevamos a un equipo: una cosa es pedirle a un agente que siga un proceso y otra es tener ese proceso declarado, versionado y con puntos en los que una persona realmente debe decidir si se avanza.
El agente suelto funciona, pero depende demasiado de la conversación
Trabajar sin un framework o una capa de proceso no está mal. Para investigar una idea, corregir algo chico o explorar un repositorio, una buena instrucción puede ser más que suficiente.
El problema aparece cuando esperamos consistencia entre tareas, personas y proyectos. En ese escenario, la forma de trabajo suele quedar repartida entre varios lugares:
un prompt que alguien fue mejorando con el tiempo;
una wiki con convenciones que el agente quizás no ve;
archivos Markdown copiados entre repositorios;
scripts de validación;
revisiones humanas que todos conocen, pero que no siempre ocurren en el mismo momento;
decisiones que viven solamente en el historial de una conversación.
Podemos escribir una instrucción como esta:
@render markdown
Antes de implementar, prepará un PRD y un plan.
Pedime aprobación en cada paso y recién después escribí código.Es una buena instrucción. Aun así, sigue siendo una expectativa textual. Su cumplimiento depende del contexto disponible, de cómo la interprete el agente y de que la conversación no pierda justamente esa parte importante.
Además, el prompt no resuelve por sí solo otras preguntas: ¿qué versión del proceso estamos usando?, ¿qué herramientas necesita?, ¿el entorno está correctamente configurado?, ¿qué documento demuestra que se aprobó una decisión?, ¿cómo retomamos el flujo en otra sesión?
Cuando el uso de agentes deja de ser individual y pasa a formar parte del trabajo del equipo, esas preguntas dejan de ser detalles.
@render mermaid
flowchart LR
S["<b>Sin una capa de proceso</b><br/><br/>Prompt y contexto<br/>Interpretación del agente<br/>Decisiones implícitas<br/>Resultado variable"]
W["<b>Con una Way</b><br/><br/>Flujo versionado<br/>Entregables esperados<br/>Gates explícitos<br/>Siguiente fase habilitada"]
S -->|"Formalizar y validar"| W
classDef accent fill:#fff1df,stroke:#d5672e,stroke-width:2px,color:#292522;
classDef neutral fill:#f4eee6,stroke:#a99b8e,stroke-width:1.5px,color:#292522;
class S neutral;
class W accent;El cambio no está en reemplazar al agente, sino en volver explícito el proceso que debe seguir.
El problema no es crear una skill, sino sostener el sistema
En uno de los posts donde presentamos Ways, Nico cuenta que antes actualizar la forma de trabajo implicaba pasar checklists, avisar por un canal qué comandos debía ejecutar cada persona y dedicar varias horas al onboarding. Cuando algo fallaba, tampoco era evidente qué versión, qué MCP o qué combinación de herramientas tenía instalada cada integrante.
Ese origen ayuda a entender la propuesta. Compartir una carpeta de skills puede resolver la primera instalación, pero no necesariamente su actualización, la validación del entorno ni la visibilidad del proceso completo.
El recorrido empezó con Incuway, nuestra forma de trabajo con IA en el equipo de desarrollo de Incu. Cuando quisimos trasladarla a otros equipos y clientes apareció el problema de escala: cómo empaquetar, instalar, compartir y descubrir no sólo las skills, sino también hooks, MCP, reglas, requisitos, workflows, gates y documentos.
Ways nace en ese punto. No para demostrar que antes era imposible trabajar de esta manera, sino para que sostenerla no dependa de una persona pasando instrucciones y revisando configuraciones máquina por máquina.
Qué es Ways y qué no es
La manera más útil de entender Ways es como un contrato para la forma de trabajo.
Una Way describe un flujo con fases, entregables, herramientas requeridas y puntos de aprobación. Ese contrato vive en un manifiesto, se puede versionar en Git, instalar en distintos repositorios y validar antes de empezar una tarea.
Por ejemplo, un flujo de desarrollo podría verse así:
@render markdown
discovery → PRD → aprobación → plan → aprobación → implementación → validación → PRLa secuencia no es solamente una recomendación escrita en una página. La Way puede declarar qué documento produce cada fase, qué gate lo valida y qué estado debe alcanzarse antes de continuar.
También es importante marcar el límite: Ways no es el modelo, no razona por el agente y no ejecuta mágicamente todo el flujo. Las skills siguen guiando las tareas, MCP aporta herramientas y otras capas distribuyen reglas o conocimiento. Ways organiza y valida el contrato que compone esas piezas.
Esta distinción es central en nuestra explicación: no intentamos inventar otro formato para empaquetar skills, plugins o servidores MCP. Construimos la capa de arriba, donde se define cómo se conectan esas capacidades dentro de un proceso.
@render mermaid
flowchart TB
W["Ways: contrato y validación"]
subgraph C["Lo que declara una Way"]
direction LR
F["Fases"]
G["Gates"]
D["Documentos"]
R["Requisitos"]
end
subgraph P["Piezas que compone"]
direction LR
S["Skills"]
ST["Steering y reglas"]
M["MCP y herramientas"]
H["Hooks"]
end
A["Agente en su formato nativo"]
W --> C
W --> P
C --> A
P --> A
classDef accent fill:#fff1df,stroke:#d5672e,stroke-width:2px,color:#292522;
classDef neutral fill:#f4eee6,stroke:#a99b8e,stroke-width:1.5px,color:#292522;
class W,A accent;
class F,G,D,R,S,ST,M,H neutral;Ways declara y valida el contrato; las skills, las reglas, MCP y los hooks siguen cumpliendo funciones propias.
La diferencia está en los gates
En conversaciones sobre agentes aparece seguido la idea de human in the loop. Suena bien, pero puede significar cosas muy distintas.
En el caso más débil, el agente muestra un plan y continúa si nadie responde rápido. La persona está informada, aunque no tenga una intervención real sobre la transición.
Un gate busca algo más concreto: el flujo queda en un estado desde el cual no debería avanzar hasta recibir la aprobación, el rechazo o el pedido de cambios esperado. También puede haber gates automáticos, como una validación que debe pasar antes de habilitar la fase siguiente.
Pensemos en una feature con una definición de producto todavía ambigua. Sin una capa de proceso, el agente podría elegir la alternativa técnicamente más razonable y empezar a implementarla. Con una Way bien diseñada, primero produce el PRD y llega a un gate bloqueante. La implementación todavía no es una transición válida: antes hace falta una decisión humana.
Eso no vuelve infalible al sistema. Un gate vago —“¿está todo bien?”— sigue siendo vago. Y el nivel de bloqueo real depende de cómo estén construidas la skill y las integraciones disponibles. Lo valioso es que el punto de decisión deja de ser una intención escondida en el prompt y pasa a formar parte explícita del flujo.
@render mermaid
sequenceDiagram
participant P as Persona
participant A as Agente
participant E as Estado de la Way
A->>E: Produce el PRD
E-->>A: Gate pendiente
Note over A,E: La implementación todavía no está habilitada
A->>P: Solicita revisión
P-->>A: Puede pedir ajustes
A->>E: Actualiza el PRD
Note over P,E: El ciclo se repite hasta la aprobación
P->>E: Aprueba el gate
E-->>A: Habilita la fase de planificaciónUn gate pendiente conserva el estado del flujo y evita tratar una revisión humana como una sugerencia opcional.
De una receta informal a un proceso reproducible
Ways agrega varias piezas alrededor de ese flujo.
Instalación fijada
Cuando agregamos una Way, Ways resuelve su fuente, valida el manifiesto y muestra qué contenido o comandos podrían ejecutarse antes de pedir aprobación. La instalación queda fijada a una versión y un digest en ways.lock.
Si el contenido cambia, cambia también su identidad y hace falta aprobarlo de nuevo. Otra persona o un entorno de CI puede reproducir la instalación exacta en lugar de reconstruirla a mano.
Validación del ambiente
ways doctor comprueba requisitos como CLIs, variables de entorno, servidores MCP, bindings y versiones fijadas. No reduce todo a un tilde verde: distingue entre algo que pasó, falló, se omitió, no pudo determinarse o no puede inspeccionarse.
Esto permite descubrir antes de trabajar que falta una herramienta o que una integración no es verificable, en vez de encontrar el problema a mitad de la implementación.
Herramientas intercambiables
Una Way puede pedir capacidades abstractas, como un proveedor de control de versiones, un gestor de issues o una herramienta de análisis de seguridad. Cada equipo vincula esos slots con GitHub, GitLab, Jira, Linear u otra implementación compatible.
El proceso expresa lo que necesita sin quedar atado a la marca elegida al momento de crearlo.
Estado visible
El progreso puede persistirse por rama o worktree: fase actual, gates y documentos. El historial de Git y los entregables siguen siendo los registros duraderos, pero el agente ya no necesita reconstruir todo el estado leyendo una conversación larga.
Sin una Way y con una Way
La comparación práctica no es entre “caos” y “orden perfecto”. Es entre dos niveles distintos de formalización.
@render table
| Aspecto | Agente sin una capa de proceso | Agente trabajando con una Way |
| --- | --- | --- |
| Secuencia | Surge del prompt y puede variar entre sesiones | Fases y transiciones declaradas y versionadas |
| Decisiones humanas | Revisión pedida en texto o realizada de forma ad hoc | Gates explícitos, relacionados con el estado y los entregables |
| Documentación | Se crea si alguien la recuerda o la solicita | El flujo declara qué documentos debe producir |
| Herramientas | Las faltantes suelen aparecer durante la tarea | Los requisitos pueden validarse antes con `doctor` |
| Portabilidad | El proceso puede quedar acoplado a marcas concretas | Slots que cada equipo vincula a sus herramientas |
| Reproducción | Hay que copiar configuración e instrucciones | Fuente, versión y contenido quedan fijados en un lockfile |
| Flexibilidad | Muy alta; ideal para explorar o resolver algo chico | Más disciplina; útil cuando la consistencia importa |
| Costo inicial | Bajo | Hay que diseñar fases, gates, artefactos y bindings |El lado izquierdo no desaparece. Hay tareas en las que formalizar ocho fases sería absurdo. Si estoy explorando una API o corrigiendo un texto, probablemente no necesite un proceso completo.
Ways empieza a tener sentido cuando queremos que un equipo repita una forma de trabajo, cuando una decisión no puede quedar a criterio del agente o cuando necesitamos demostrar que el ambiente y el proceso son los esperados.
Incuway: un caso concreto
Incuway es nuestra forma de trabajo en Incu empaquetada sobre Ways. Técnicamente es una WayFamily: una familia que reúne procesos relacionados bajo una misma identidad, sin fingir que todos tienen el mismo flujo.
Actualmente incluye tres Ways:
incu/dev, para desarrollar features desde discovery y PRD hasta validación y pull requests;incu/bugs, que separa documentación, causa raíz, reproducción, plan del arreglo y validación;incu/security, orientada a hallazgos, alcance, plan de remediación, correcciones y nuevo análisis.
Las tres comparten reglas, skills y capacidades, pero conservan fases y gates propios. Es una decisión que nos parece especialmente valiosa: resolver un bug no es desarrollar una feature más corta, y remediar una vulnerabilidad tampoco debería ser una variante cosmética del mismo prompt.
La familia se puede incorporar desde su repositorio con:
@render bash
npx ways.sh add github:incu-tech/incuwayA partir de ahí todavía hay trabajo: revisar el plan de instalación, vincular las capacidades que necesita el equipo y ejecutar ways doctor. Instalar una Way no reemplaza la conversación sobre cómo queremos trabajar; la vuelve concreta.
El costo honesto de adoptar un framework
Formalizar un proceso obliga a mirar cosas que antes podían quedar implícitas. Hay que decidir qué fases existen, qué documento aporta valor, dónde debe frenar el agente y quién tiene autoridad para aprobar.
Eso lleva tiempo y mantenimiento. También puede producir procesos pesados si agregamos gates por reflejo en lugar de hacerlo por riesgo o necesidad.
Ways tampoco corrige un objetivo mal definido, una skill pobre o una revisión superficial. Compone piezas existentes; no mejora automáticamente la calidad de cada pieza. Además, al apoyarse en formatos como SKILL.md, Steering y MCP, tiene que acompañar la evolución de herramientas que no controla.
Para nosotros, el criterio no debería ser “usemos framework porque estamos usando agentes”. La pregunta más útil es:
¿El costo de que cada ejecución improvise este proceso es mayor que el costo de diseñarlo y mantenerlo explícitamente?
En una tarea personal y exploratoria, probablemente no. En un equipo que desarrolla features, atiende bugs y remedia problemas de seguridad con varios agentes y repositorios, la respuesta puede cambiar bastante.
Una forma de trabajar también es parte del sistema
Durante mucho tiempo tratamos el proceso como documentación alrededor del software: importante, pero separado de las herramientas que efectivamente hacen el trabajo. Con agentes capaces de actuar sobre un repositorio, esa separación se vuelve más riesgosa.
Ways propone que la manera de trabajar sea también un artefacto técnico: declarada, instalable, versionada y verificable.
Nos quedamos con tres ideas:
un agente capaz no reemplaza un proceso claro;
una aprobación aporta valor cuando puede detener una transición real;
un framework conviene cuando la consistencia compartida pesa más que la improvisación.
Si ya trabajás con agentes, puede valer la pena revisar una tarea reciente: ¿qué decisiones quedaron solamente en el chat?, ¿en qué momento debería haber frenado el agente?, ¿qué parte del proceso tendría sentido repetir igual en todo el equipo?
Ese ejercicio, incluso antes de instalar nada, ya ayuda a descubrir cuál es realmente nuestra forma de trabajar.
Para seguir leyendo