Why solveOS
What problem it solves, what its principles are, and how AI fits into the structure.
The four failure modes
Most people fail at solving things for one of four reasons. solveOS is designed to prevent each one.
1. Skip planning
They jump into execution without a clear goal or constraints, and end up building the wrong thing.
solveOS response: The Plan phase requires a written brief before any execution begins.
2. Over-plan
They get stuck refining the plan and never ship anything real.
solveOS response: Appetite is a core field in the Plan Brief. Scope fits the time — not the other way around.
3. Lose context
The goal defined at the start gets distorted by the time execution ends.
solveOS response: The Plan Brief is an active reference throughout Build — not a starting artifact.
4. Never measure
They ship something, move on, and never find out if it worked. The same mistakes repeat.
solveOS response: The Review gate closes the loop — measuring what happened and feeding it into the next Plan.
The Six Principles
These principles govern how solveOS should be applied. They are not rules — they are lenses. When you feel stuck or off-track, return to them.
Principle 1
Clarity before action
Before execution begins, you must be able to state the problem, who it is for, and what success looks like — in writing. Not perfect clarity. Enough clarity to make the first decision without guessing. The Plan phase creates this foundation. Without it, every subsequent decision is unanchored.
Principle 2
Build to learn
Planning can only take you so far. The act of building reveals constraints, edge cases, and insights that no amount of thinking can surface. Don't treat the build phase as pure execution — treat it as structured discovery.
Principle 3
Reality is the only validator
No plan, build, or opinion tells you if something works. Only putting it in the world does. Shipping is not the end of the process — it is the beginning of knowing. An imperfect thing that is live produces more real information than a perfect thing that isn't.
Principle 4
Gates reduce cost, not momentum
Optional gates exist to catch expensive mistakes early, not to create bureaucracy. If a gate is slowing you down more than it's protecting you, skip it. Gates should serve the work, not the other way around.
Principle 5
The brief is your compass
The clarity established in Plan doesn't maintain itself. Every decision made during Build is an opportunity to drift from the original goal. The Plan Brief is not a starting artifact — it is an active reference. When what you're building no longer matches the brief, you either update the brief in writing or course correct. Silent drift is how projects fail.
Principle 6
Context must be carried forward
Every phase and gate produces learning. That learning only has value if it travels into the next step — explicitly, in writing. This matters everywhere, but it is critical when working with AI. AI has no memory between sessions. If you do not carry the context forward — decisions made, directions cut, constraints discovered, things that didn't work — the next session starts from zero. The cycle degrades. Each handoff between phases is an opportunity to capture what was learned and inject it into what comes next.
solveOS and AI
solveOS is the first problem-solving framework designed around AI as a primary executor — not a tool, not an assistant, but a participant that can own the Build phase from a brief.
Most frameworks were designed before AI could do meaningful work. They treat AI as an accelerator at best. solveOS is built from the ground up assuming AI can be the builder — and structures the collaboration to make that safe and effective.
AI can take any role in solveOS. It can be a thinking partner in Plan, an executor in Build, or a fully autonomous agent running an entire phase from a brief. The framework does not prescribe who (or what) does the work — it prescribes the structure that makes the work sound.
What AI does. What the human decides.
The division is not about capability — it is about accountability. AI executes. The human decides.
Every phase and gate in solveOS produces an output. The human reads that output and makes a decision: accept it, reject it, revise it, or iterate. This decision loop is not optional — it is the mechanism that keeps the work aligned with intent.
| Phase / Gate | AI can... | Human must... |
|---|---|---|
| Plan | Challenge the problem statement, sharpen constraints, rewrite vague goals | Own the goal, decide what success means, commit to the plan |
| Research | Surface findings, synthesize information, identify gaps | Decide what question to answer, judge whether findings are sufficient |
| Build | Produce the output — code, text, designs — given the Plan Brief | Decide which approach to take, recognize when output doesn't match the goal, update the brief |
| Validate | Check output against criteria, flag gaps | Decide whether to ship, iterate, or cut scope |
| Ship | None | Decide that this goes in front of real people — and that it is the right thing to ship |
| Review | Measure, summarize, surface patterns | Decide what to learn and what to change in the next cycle |
At any gate, if the output is not right, iterate. Gates are checkpoints where the human reads the output and decides whether to proceed or go back. Skipping the decision is the most common way a cycle fails — not because AI produced bad output, but because no one checked.
Por qué solveOS
Qué problema resuelve, cuáles son sus principios y cómo encaja la IA en la estructura.
Los cuatro modos de fracaso
La mayoría de las personas fracasan al resolver problemas por una de cuatro razones. solveOS está diseñado para prevenir cada una.
1. Saltarse la planificación
Se lanzan a ejecutar sin un objetivo claro ni restricciones, y terminan construyendo lo incorrecto.
Respuesta de solveOS: La fase Plan exige un brief escrito antes de comenzar cualquier ejecución.
2. Sobreplanificar
Se quedan refinando el plan indefinidamente y nunca llegan a entregar nada real.
Respuesta de solveOS: El apetito es un campo central en el Plan Brief. El alcance se ajusta al tiempo disponible, no al revés.
3. Perder el contexto
El objetivo definido al inicio se distorsiona para cuando termina la ejecución.
Respuesta de solveOS: El Plan Brief es una referencia activa durante todo el Build, no un artefacto de inicio.
4. No medir nunca
Entregan algo, siguen adelante y nunca averiguan si funcionó. Los mismos errores se repiten.
Respuesta de solveOS: El gate Review cierra el ciclo: mide lo ocurrido y lo alimenta al siguiente Plan.
Los Seis Principios
Estos principios rigen cómo debe aplicarse solveOS. No son reglas — son lentes. Cuando te sientas atascado o fuera de rumbo, regresa a ellos.
Principio 1
Claridad antes de la acción
Antes de comenzar la ejecución, debes poder enunciar el problema, para quién es y cómo se ve el éxito — por escrito. No claridad perfecta. Suficiente claridad para tomar la primera decisión sin adivinar. La fase Plan crea esta base. Sin ella, cada decisión posterior carece de ancla.
Principio 2
Construir para aprender
La planificación solo llega hasta cierto punto. El acto de construir revela restricciones, casos límite e insights que ninguna cantidad de pensamiento puede descubrir. No trates la fase Build como pura ejecución — trátala como descubrimiento estructurado.
Principio 3
La realidad es el único validador
Ningún plan, construcción u opinión te dice si algo funciona. Solo ponerlo en el mundo lo hace. Entregar no es el fin del proceso — es el comienzo del conocimiento. Una cosa imperfecta que está en vivo produce más información real que una cosa perfecta que no lo está.
Principio 4
Los gates reducen el costo, no el impulso
Los gates opcionales existen para detectar errores costosos a tiempo, no para crear burocracia. Si un gate te frena más de lo que te protege, omítelo. Los gates deben servir al trabajo, no al revés.
Principio 5
El brief es tu brújula
La claridad establecida en Plan no se mantiene sola. Cada decisión durante Build es una oportunidad de desviarse del objetivo original. El Plan Brief no es un artefacto de inicio — es una referencia activa. Cuando lo que estás construyendo ya no coincide con el brief, o actualizas el brief por escrito o corriges el rumbo. La deriva silenciosa es como fracasan los proyectos.
Principio 6
El contexto debe trasladarse hacia adelante
Cada fase y gate produce aprendizaje. Ese aprendizaje solo tiene valor si se traslada al siguiente paso — de forma explícita, por escrito. Esto importa en todas partes, pero es crítico al trabajar con IA. La IA no tiene memoria entre sesiones. Si no trasladas el contexto hacia adelante — decisiones tomadas, direcciones descartadas, restricciones descubiertas, cosas que no funcionaron — la siguiente sesión comienza desde cero. El ciclo se degrada. Cada traspaso entre fases es una oportunidad para capturar lo aprendido e inyectarlo en lo que viene.
solveOS y la IA
solveOS es el primer framework de resolución de problemas diseñado con la IA como ejecutor principal — no como herramienta, no como asistente, sino como participante que puede tomar el control de la fase Build a partir de un brief.
La mayoría de los frameworks fueron diseñados antes de que la IA pudiera hacer trabajo significativo. La tratan como un acelerador, en el mejor de los casos. solveOS está construido desde cero asumiendo que la IA puede ser el constructor — y estructura la colaboración para que eso sea seguro y efectivo.
La IA puede tomar cualquier rol en solveOS. Puede ser compañera de pensamiento en Plan, ejecutora en Build, o un agente completamente autónomo que ejecuta una fase entera a partir de un brief. El framework no prescribe quién (o qué) hace el trabajo — prescribe la estructura que hace que el trabajo sea sólido.
Lo que hace la IA. Lo que decide el humano.
La división no es sobre capacidad — es sobre responsabilidad. La IA ejecuta. El humano decide.
Cada fase y gate en solveOS produce un resultado. El humano lee ese resultado y toma una decisión: aceptarlo, rechazarlo, revisarlo o iterar. Este ciclo de decisión no es opcional — es el mecanismo que mantiene el trabajo alineado con la intención.
| Fase / Gate | La IA puede... | El humano debe... |
|---|---|---|
| Plan | Cuestionar el enunciado del problema, afinar restricciones, reescribir objetivos vagos | Ser dueño del objetivo, decidir qué significa el éxito, comprometerse con el plan |
| Research | Descubrir hallazgos, sintetizar información, identificar vacíos | Decidir qué pregunta responder, juzgar si los hallazgos son suficientes |
| Build | Producir el resultado — código, texto, diseños — dado el Plan Brief | Decidir qué enfoque tomar, reconocer cuando el resultado no coincide con el objetivo, actualizar el brief |
| Validate | Verificar el resultado contra los criterios, señalar vacíos | Decidir si entregar, iterar o reducir el alcance |
| Ship | Nada | Decidir que esto llega a personas reales — y que es lo correcto para entregar |
| Review | Medir, resumir, detectar patrones | Decidir qué aprender y qué cambiar en el siguiente ciclo |
En cualquier gate, si el resultado no es correcto, itera. Los gates son puntos de control donde el humano lee el resultado y decide si continuar o volver atrás. Saltarse la decisión es la forma más común de que un ciclo fracase — no porque la IA produjo mal resultado, sino porque nadie lo verificó.