HyperTeamsMap of the four processes
What you will learn What each of the next four chapters covers, and where the familiar analysis-design-build-test stages ended up inside them.
That is the concepts — what still blocks, what changes, micro-sprints, IntentOps, fluid software.
Now the actual process. It runs over four chapters; before going in, here is the whole thing on one page.
The four processes
graph TD
P1["Process 1<br/>Capturing intent"] --> P2["Process 2<br/>Agent orchestration"]
P2 --> P3["Process 3<br/>Automatic validation"]
P3 --> P4["Process 4<br/>Immediate delivery"]
P3 -.->|"tests fail"| P2
P3 -.->|"retry limit — the spec is wrong"| P1
P4 -.->|"monitoring signal"| P1The three dotted lines are the content of this picture.
- Process 3 → 2 (self-healing): when a test fails, nobody is paged — the code is regenerated. This is the loop's normal operation.
- Process 3 → 1 (going back): if several rounds of fixing do not help, it is not the code that is wrong but the spec or the test. This is where a person enters.
- Process 4 → 1 (the loop closes): after release, monitoring signals become the intent of the next cycle.
One lap takes minutes to hours. Not two weeks.
What each process answers
| Process | Core question | Output |
|---|---|---|
| 1. Capturing intent | what are we building — with no room for interpretation | spec + the tests that decide "done" |
| 2. Orchestration | how do we build it | working code |
| 3. Automatic validation | is it actually done | a fully passing test run |
| 4. Immediate delivery | is it actually used | shipped change + monitoring signals |
Where did the familiar four stages go?
Analysis → design → build → test. If your organisation has worked in that order, the diagram above will look foreign. Those stages did not disappear — they moved.
| Familiar stage | Where it went | What changed |
|---|---|---|
| Analysis | Process 1 | not a meeting but a PM agent's questions. Not minutes, but the Q&A itself is the spec |
| Design | the architect inside Process 2 | not a separate stage but a role running concurrently with build and review |
| Build | the coding agent inside Process 2 | written by an agent, not a person. Code is not an asset but a derivative |
| Test | the front (IntentOps) + Process 3 | not the final gate — decided up front alongside the spec, then judged automatically at the back |
| (Release) | Process 4 | not an event outside the stages but inside the loop |
The middle two are worth a closer look.
Design did not disappear
Process 2 has an architect agent, and the work of designing system structure and change scope is still there. What is gone is the order in which review waits for build to finish. The three run at the same time and hand problems back to each other.
And the points where a person steps into design are fixed.
- When the design direction diverges from the spec
- Irreversible decisions — schema changes, external contract changes
However short the cycle gets, those two are looked at by a person.
Test moved to the front
Traditionally testing was the final gate. Here, IntentOps settles the tests up front together with the spec, and Process 3 merely runs them and judges.
There is one reason for the reordering. If a person is not going to decide when something is done, the criterion has to exist at the start.
What changed is the coordination, not the order
It is easy to read this map as "so it is waterfall, run fast." It is not.
graph TD
W["Sequential model"] --> W1["build waits for design<br/>review waits for build"]
H["Process 2"] --> H1["architect · coding · review run<br/>at the same time, handing work back"]As what changes put it, what this methodology changes is not the order or the length of the stages but who does the coordinating. The mapping table above is only a map of where the familiar names landed — the four processes must not be read as sequential gates.
Where the people are
Nowhere in the four processes is there "a person writes the code." People are in three places instead.
| Position | What they do |
|---|---|
| Before Process 1 | deciding what to build |
| Inside Process 2 | design direction, and approving irreversible decisions |
| Process 3's criteria | the judgement of whether the tests are a real pass mark |
The third is the one most often dropped. The loop's goal is passing the tests, so if the criteria are shallow it will exploit the gaps precisely.
Do you have to adopt all four?
No. Process 4 (immediate delivery) has the most prerequisites — an automated deployment pipeline, rollback in minutes, real-time monitoring. Without them, use Processes 1-3 and leave delivery on human approval as before.
Common misunderstandings
"So we write no design documents?"
The spec and the tests take the document's place. Documents written to explain things to people shrink; what remains is a spec that people and agents both read. It is the same point as fluid software — the asset you protect moves from code to spec plus tests.
"We are required to review the output of each stage"
Every process has an output, so the review points can exist. What differs is where you attach them. With cycles running in minutes, attaching a human review to every cycle brings back exactly the coordination cost you removed. Attach review to the spec and the test criteria, not to individual cycles — which is the subject of guardrails.
Check yourself
1. Where did the familiar "design" stage go?
Answer
Into the architect role inside Process 2. It was not removed; it stopped being a separate stage and now runs concurrently with build and review. Irreversible decisions (schema, external contracts) are still approved by a person.
2. Why did testing move to the front?
Answer
Because a person no longer decides when something is done. For the judgement to be automatic, the criterion has to exist at the start, so IntentOps settles the tests up front alongside the spec.
3. If tests keep failing in Process 3, what should you suspect?
Answer
If several rounds of fixing do not help, it is not the code but the spec or the test that is wrong. That is why the loop has a retry limit and calls a person when it is exceeded — the Process 3 → 1 dotted line in the diagram.
Now each process one at a time → Process 1 — capturing intent