Field Notes
A practical guide series for the enterprise agentic transition — and why brownfield projects need a different conversation
If you haven't read the Agentic Engineering Journey, start there! It introduces Dan Shapiro's five levels, along with DDD, BMAD, and Attractor to orient someone new to the field. If you are new to any of these concepts, that's your foundational read.
That initial article maps the territory well. What it doesn't do—because it wasn't written to—is address the gap between that map and the enterprise reality. The five levels often assume a fresh start. Most enterprise teams, however, are not starting fresh. They navigate systems accumulating technical and functional debt for decades, managing SAP or large application implementations with years of undocumented custom code, and supporting legacy applications where core architects left long ago.
This series of seven guides is an attempt to address that gap. It begins where most agentic development discourse doesn't: with domain clarity before tooling, business process understanding before specification, and a realistic account of what works—and what doesn't—in brownfield environments.
Current agentic development literature largely targets greenfield projects—new codebases, clean domain models, teams unburdened by accumulated decisions. The assumption is that you can start with a clear specification, hand it to a structured agent workflow, and converge on working software. For genuinely new projects with well-understood domains, that assumption holds.
The enterprise reality is different. Greenfield projects are a minority. And even those that begin clean quickly become brownfield—a business rule changing during UAT, an architectural compromise made under pressure, a "temporary" integration running for years in production. Today's greenfield is tomorrow's brownfield, and under enterprise timelines, that transition happens faster than most project managers admit.
Most enterprise teams aren't asking "how do we build a dark factory?" They're asking "how do we transition to an agentic world without making things worse?" This is a distinct question that hasn't received serious attention from the agentic development community.
Brownfield projects present a specific challenge: the system itself *is* the specification. Every implicit decision from a decade of patches, hot-fixes, and workarounds is encoded in running code, not in any document an agent can read. Business rules governing edge cases live in the heads of long-gone experts. Terminology, once agreed, has drifted across teams. An agent operating here without careful domain preparation will produce confident, internally consistent, yet wrong output—errors that surface only when the new system clashes with the old reality.
The guides in this series are not a methodology to adopt wholesale. They are a thinking toolkit—seven lenses on the same problem, each addressing a different part of the enterprise transformation challenge. Read what fits your context. Apply what earns its place.
| Guide | Title | What it Solves |
|---|---|---|
| 1 | Domain-Driven Design — A Practical Reference | The conceptual foundation. Addresses how an agent working from an ambiguous domain model will amplify that ambiguity at speed. Focuses on Ubiquitous Language, Bounded Contexts, and Subdomain classification. |
| 2 | Event Storming — A Practical Workshop Guide | The discovery method. Covers the workshop technique for applying DDD to a specific business with its actual experts, including facilitation and output-to-DDD mapping. |
| 3 | The Flowchart-First Path | The offline alternative. A systematic method for building a domain model from existing swimlane flowcharts, overlaying DDD vocabulary on existing business documentation. |
| 4 | Domain Context Engineering | The LLM-driven pipeline. Presents a structured domain-ctx.txt format and LLM prompts that generate BMAD Briefs, PRDs, and Architecture skeletons with consistent terminology. |
| 5 | The BMAD Method — A Practical Guide | Structured execution at Levels 3 and 4. Covers agent roles, the Brief-PRD-Architecture-Story workflow, and brownfield relevance for application support. |
| 6 | Attractor — A Practical Guide | The lights-out factory and its enterprise adaptation. Details NLSpec, Directed Graphs, Holdout Scenarios, Digital Twins, and practical multi-agent collaboration. |
| 7 | From Domain to Factory — The Synthesis Guide | The argument that ties the other six together. Explains the dependency sequence, walks through a worked example, and introduces the Harness Engineering framing. |
Most enterprise organizations already possess swimlane flowcharts—produced for ISO certification, regulatory compliance, or business process reengineering. These documents, often outdated, hold the raw material for a domain model. The insight of the Flowchart-First guide is that swimlane notation and DDD vocabulary are the same map at different zoom levels.
Every swimlane represents an Actor. Every process box is a Command and an implied Domain Event. Every cross-lane handoff arrow is a Domain Event crossing a context boundary—a critical element routinely left unnamed. Every decision diamond is a Policy. The lane boundaries suggest Bounded Context candidates.
A DDD practitioner, reading an existing flowchart through this lens, can extract a draft domain model in hours. The revealed gaps—unhandled exceptions, unwritten policies, shifting terminology—become a targeted question list for domain experts. This is not a full-day workshop, but a structured document for asynchronous review.
LLMs possess substantial generic knowledge of standard ERP process flows (SAP Order to Cash, Oracle Procure to Pay). What an LLM doesn't know is your specific implementation: Z-exits, custom approval hierarchies, unrecorded business rules. The domain context file captures this delta—the unique aspects diverging from the LLM's baseline knowledge. This reframes the effort for brownfield ERP environments: you ask experts where your process differs from standard, not to explain standard processes. The result is a much smaller, more focused conversation.
The LLM-driven pipeline then generates BMAD Briefs, PRDs, and Architecture skeletons from this context file, leveraging the LLM's ERP knowledge with your organization's specific delta. Consistent terminology, correct scope, functional requirements derived from Domain Events. Human contribution is domain expertise; LLM contribution is consistent mechanical translation—neither duplicates the other.
The prevailing discourse on agentic development maturity often frames the journey as a leap of faith: control agent output, gradually trust more, eventually reach Level 5 and trust completely. Enterprise architects and risk-conscious engineering leaders hear this and rightly hesitate.
The correct framing is different, and it transforms the emotional character of the journey: it's not "trust the agent more," but "build the harness better." Each level of harness maturity removes a human bottleneck, not by blind trust, but because the harness now encodes the knowledge and checks previously performed manually.
The harness is the full collection of specifications, domain context files, quality constraints, workflow guidance, and transition conditions that controls the agent's "how" loop. domain-ctx.txt is harness. The BMAD artefact chain is harness. The NLSpec is harness. CLAUDE.md is harness. Every well-written Story File is harness. Building a better harness isn't about trust; it's about encoding what you already know precisely enough for an agent to apply consistently.
At Level 2, the human holds all context. Nothing happens when you step away because nothing is encoded. The human is the bottleneck because the human *is* the harness. At Level 3, the BMAD artefact chain carries specification context. The human remains in the loop at review gates, but the agent works autonomously between them. At Level 4, the NLSpec carries architectural decisions and quality constraints. The human reviews outcomes, not individual steps. At Level 5, the holdout scenario suite carries verification—the human bottleneck is removed not because the agent is blindly trusted, but because every human verification has been encoded in the harness.
This reframing has practical consequences for enterprises: you don't need to decide how much to trust an agent. You need to decide how much harness you have built. If the harness covers the decision, the agent can make it reliably. If not, a human must make it—not because agents are inherently untrustworthy, but because the specific knowledge required hasn't been encoded yet.
Kief Morris at Thoughtworks named this practice "Harness Engineering" in March 2026. While "Spec-Driven Development" (a popular framing) names one component, Harness Engineering asks: which component of the control system failed? That's the more useful diagnostic question.
The most important thing to convey about these seven guides is simple: they are not a methodology to adopt wholesale. Agentic development is a tectonic shift—as significant as the pre/post-internet distinction. But tectonic shifts are felt gradually. The right response is not to redesign your entire SDLC overnight, but to experiment carefully, accumulate evidence, and build mental models that allow for better decisions as the technology matures.
Start with one practice. Apply NLSpec discipline to a project's Story Files—making them precise enough that a Developer agent never guesses about terminology or scope. Or run a Flowchart-First exercise on a business process. Or add ADR generation to a BMAD Architecture session. Pick the practice that addresses your actual bottleneck, in your current project, with your existing team.
Measure what changes, not abstractly, but within your project. If story rejection rates drop due to more precise Story Files, that practice has earned its place. Extend it. If not, it may not be the right starting point. Try another tool from the toolkit.
Organizations that navigate the post-Agentic transition most effectively will not be those adopting the most frameworks fastest. They will be those experimenting thoughtfully now, building an accumulated understanding of what works in their context, and achieving the harness maturity to deploy more autonomy responsibly when technology and discipline align.
Pre-Agentic organizations skipping experimentation will adopt practices without understanding why—the Agile ceremony problem all over again. They'll copy CLAUDE.md from a starred GitHub repo and wonder why the agent is unpredictable. They'll install BMAD as a process without the domain clarity that makes artifacts meaningful. They'll reach Level 2, feel the productivity lift, and stop—because Level 2 always feels like the destination.
The dark factory isn't the immediate goal for most enterprise teams. The goal is building the mental models, practices, and harness discipline that make the next level reachable when you're ready. That work is available to every organization today, regardless of their current maturity.
The seven guides are available as standalone HTML files—each navigable by chapter, readable offline, with diagrams. They are designed to be read in any order based on your journey. Start with the DDD guide if domain clarity is your gap. Choose the Flowchart-First guide if you have existing process documentation and want a practical starting point. Begin with the BMAD guide if you are already using agent-assisted development and need more structure. Or dive into the Synthesis guide if you want the overarching argument for the sequence before any individual layer.
The blog series will delve deeper into each of these areas as the thinking evolves. Initial posts will specifically address application support and brownfield use cases—areas where most enterprise teams operate, and where current discourse provides the least guidance.
In the meantime, the realistic summary is this: the technology is ready for careful experimentation. The frameworks exist to structure that experimentation. The domain clarity work—the unglamorous, time-consuming, discipline-requiring effort of understanding your business precisely enough to specify it—is the prerequisite no tool can substitute for.