Greenfield and brownfield: same gates, different first question
The operating model runs in two configurations. Greenfield starts from an empty repository and writes the standards as it writes the code. Brownfield starts inside a product already in production, where the agents must learn the codebase, its rules and its failure history before they may propose anything. The phases and gates are identical; what changes is what has to be known before the first one opens.
The question we get most often from leaders who like the model is some version of "that's fine for a new product, but we have fifteen years of code." It is the right question, and the answer is that the model runs in two configurations with the same phases and the same gates. What changes is the first question the agents have to answer.
Greenfield: what should exist?
Greenfield is a new product from an empty repository. The agents start from the idea and its business case, cut the epics, build the working mock, and the standards are written as the code is written. There is nothing to learn first because there is nothing there.
The risk in greenfield is not the agents; it is the humans skipping the early phases because the slate is clean. The temptation is to go straight to code because there is no legacy to respect. That is how you get a beautifully built product nobody needed. The initiative with ROI and the epics with measurable outcomes matter more in greenfield, not less, because nothing else is constraining the scope.
This is how LPG's payments platform was built: from an empty repository to PayFac-as-a-Service infrastructure that sponsor banks run their programs on, with the operating model enforced from the first commit.
Brownfield: what already exists, and why?
Brownfield is a new feature inside a product that already runs in production. Here the agents are not allowed to propose anything until they have learned three things: the codebase as it actually is, the rules it operates under, and its failure history. What broke before, why, and what was done about it.
That learning is a phase of its own, before S0. The domain experts load the real rulebooks for this business. The engineer agents build a map of the services, the contracts between them, the data they own, and the tests that exist. The records agent pulls the incident history. The graph knowledge base is seeded from all of it, and from then on it keeps learning with every prompt.
Only then does the lifecycle begin, and it begins the same way: idea, initiative with ROI, epics, working mock. The working mock is especially valuable in brownfield, because it is deployed into a temporary environment alongside the real system and vetted against the real integrations. "Does this break settlement?" is answered by using it, not by hoping.
The risk in brownfield is the opposite of greenfield: the agents being too respectful of what exists. A codebase with fifteen years of history has fifteen years of decisions that may no longer be right. The engineers are allowed to propose changes to the legacy, but those proposals go through the same pipeline as everything else, with the mutation checks and the full suite proving that the old behavior is preserved where it should be and changed only where the acceptance criteria say so.
The same gates
In both configurations: a named person approves the acceptance criteria, acknowledges the locked tests, and releases. Auditors run on a different model from engineers. Guards deny and agents stop. Every merge deploys dark; release is a decision.
The reason the gates do not change is that the regulator does not care whether the code is new. The question is the same for a feature in a fifteen-year-old loan management system and for a new PayFac platform: who approved this, what proves it, and who turned it on.
Choosing a track
Most organizations run both. The new line of business is greenfield; the core is brownfield; the integration between them is where the two tracks meet and where the domain experts earn their keep. The course on this site teaches both tracks side by side, with the same stories run each way, so the difference is visible rather than theoretical.