The Algorithm is the core of DuranteOS. Not a prompt. Not a framework. A code-orchestrated pipeline that turns every non-trivial request into a sequence of verified phases — each with gates that pass or fail.
Most AI coding workflows are a single step: prompt in, code out. The Algorithm replaces that with seven distinct phases, each with a defined purpose, required outputs, and programmatic gate checks.
The Seven Phases
OBSERVE
The pipeline starts by understanding what exists before changing anything. The system reads files, inspects the codebase, queries databases, and spawns research agents if needed. No code is written. No changes are made. The goal is to build an accurate model of the current state.
This prevents the most common AI coding failure: generating code based on assumptions about the codebase instead of evidence from the codebase.
DEFINE
Every request decomposes into Ideal State Criteria (ISC) — binary testable conditions that describe what must be true when the work is complete.
A criterion like "User authentication supports OAuth with Google and GitHub" is concrete and verifiable. A criterion like "Improve the auth system" is not. DEFINE forces precision. If you cannot state the success condition in 8-12 words with a binary outcome, the requirement is not ready for execution.
Criteria are typed by priority: critical (must pass), important (should pass), and anti-criteria (must NOT be true). Anti-criteria catch regressions — "No existing tests break after refactor" is as important as "New feature works correctly."
THINK
The system pressure-tests its own plan before executing. What could go wrong? What assumption is riskiest? What would a pre-mortem reveal?
THINK is the phase that catches overengineering before it starts. If the plan requires four database migrations for a feature that could use a single config change, THINK surfaces that. Not every request needs this phase — the orchestrator activates it for extended and advanced effort levels.
PLAN
Execution strategy. Which files to modify. Which agents to spawn. What order to work in. What to verify first. The plan maps every ISC criterion to a specific execution step, ensuring nothing is forgotten.
PLAN also validates prerequisites. If the task requires a database connection and none is configured, PLAN catches that before MAKE wastes tokens on code that cannot run.
MAKE
Execution. Code is written, files are created, agents are spawned. This is where the LLM does what it does well — generating code, analyzing patterns, creating content.
The critical difference from prompt-based tools: MAKE runs with the ISC criteria visible. The system knows what gates it must pass. And it knows that something other than itself will be checking.
VERIFY
The gate. Every ISC criterion is checked with evidence. Code runs, tests execute, files are inspected. Each criterion resolves to pass or fail.
Verification is never self-reported. The LLM does not say "I believe I met criterion C3." Code inspects the result and returns a boolean. If critical criteria fail, the phase loops back for retry. After exhausting retries, the run aborts.
There is no partial pass. There is no "close enough." The gate holds or it does not.
LEARN
After delivery, the system reflects. What worked? What failed? What would a smarter algorithm have done differently? Insights are persisted to cross-session memory, making the next run sharper.
LEARN is what turns a stateless tool into an accumulating system. Patterns discovered in session 50 inform decisions in session 500.
Progressive Depth
Not every request needs all seven phases. The orchestrator classifies each request in under 500 milliseconds and selects the minimum viable pipeline:
- Minimal — Direct response, no phases (simple questions, quick lookups)
- Fast — OBSERVE, MAKE (small changes with low risk)
- Standard — OBSERVE, DEFINE, PLAN, MAKE, VERIFY (most development work)
- Extended — Full pipeline including THINK and LEARN (complex features, architecture changes)
The classification is automatic. A typo fix does not run through seven phases. A database migration does.
Why Phases Matter
Single-step AI coding conflates understanding, planning, execution, and verification into one prompt-response cycle. The LLM must simultaneously figure out what exists, decide what to do, write the code, and check its own work. It does all of these poorly because it is doing all of them at once.
Phased execution separates concerns. The system that observes the codebase is not the same invocation that writes code. The system that verifies is not the same invocation that generated. Each phase has a single responsibility, a defined output, and a gate.
This is not novel architecture. It is the same principle behind CI/CD pipelines, compilation phases, and request middleware. The novel part is applying it to AI-generated output — treating LLM output with the same rigor you would treat any other untrusted input.
The Algorithm is that rigor, codified.