From Seed to Software: Cultivating AI-Driven Systems Through the Allotment Lifecycle

By Michael Mifsud

#ai-agents#domain-driven-design#software-architecture#agentic-workflows#software-engineering

Beyond “Prompt → Code”

The prevailing approach to AI-assisted software engineering treats development as a linear transaction: type a prompt, receive a block of code, paste it into an editor, and hope nothing breaks.

While this works for trivial functions or isolated snippets, it fails as a methodology for building complex, enduring software systems. Software is not a disposable text payload. It is a living ecosystem with domain boundaries, evolving requirements, architectural invariants, and continuous state.

When project context is trapped inside volatile prompt windows, ad-hoc chat sessions, or black-box agent frameworks, engineering teams quickly encounter cognitive drift and structural chaos. Nobody knows where an implementation choice originated, what assumptions were made, or why a boundary was breached.

To build genuinely autonomous, reliable agentic software workflows, we need a different mental model. Instead of treating software delivery as a series of ad-hoc prompt transactions, we should think of it as cultivating a project through a visible, structured lifecycle.

The Agentic Allotment Lifecycle Model

The Core Metaphor: The Agentic Allotment

Consider an allotment or market garden. You do not dump raw seeds directly onto open ground and expect an instant harvest. You follow an intentional, physical sequence that transforms raw potential into mature produce:

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  01. SEED    │ ──> │ 02. SUBSTRATE│ ──> │03. GREENHOUSE│ ──> │ 04. HARVEST  │
└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
  Raw Ideas &          Domain Specs &       Implementation &     Production Git
 Requirements          Bounded Work           Verification         Repository

By mapping this natural sequence directly onto our workspace filesystem, we establish a physical, human-readable pipeline for agentic engineering:

1. 01. seed — Raw Ideas & Discovery

This is where raw ideas arrive. It holds unpolished audio transcripts, whiteboard notes, market observations, user feedback, research papers, and fuzzy feature requests. No code lives here, and no architectural commitments have been made yet.

2. 02. substrate — Domain Specs & Bounded Work

Before implementation begins, raw seeds must be conditioned into structured substrate. This stage converts loose thoughts into explicit domain boundaries, Domain-Driven Design (DDD) specifications, user stories, acceptance criteria, and actionable tickets. It defines the rules of engagement for the codebase.

3. 03. greenhouse — Implementation & Verification

This is the active growing space where AI sub-agents write code, build experimental features, run automated test suites, generate BDD specs, and log intermediate artifacts. It is an environment built for trial, feedback, and refinement.

4. 04. harvest — The Production Repository

Once code in the greenhouse passes all acceptance criteria, static analysis, and verification checks, it is harvested into the primary production Git repository. The harvest represents proven, deployable capability.

Domain-Driven Design: Crop Patches as Bounded Contexts

The allotment metaphor extends naturally to Domain-Driven Design (DDD). On a well-managed allotment, you do not throw all crops into a single mixed pile. Carrots, cabbages, potatoes, and sunflowers each occupy their own dedicated patch of soil, with specific nutrients, care routines, and harvesting timelines.

In software architecture, each crop patch represents a Bounded Context:

┌────────────────────────────────────────────────────────────────────────┐
│                        THE AGENTIC ALLOTMENT                           │
├───────────────────┬───────────────────┬────────────────────────────────┤
│ 🥕 CARROTS        │ 🥬 CABBAGES       │ 🥔 POTATOES                    │
│ Property Catalog  │ API Security &    │ Usage Monitoring &             │
│ & Search          │ Key Management    │ Rate Enforcement               │
├───────────────────┴───────────────────┴────────────────────────────────┤
│ 🌻 SUNFLOWERS                                                          │
│ Monetization, Metering & Billing                                       │
└────────────────────────────────────────────────────────────────────────┘

When an AI agent is tasked with working on the Property Catalog, it operates strictly within the Carrots patch. It respects the boundaries and domain terms of that context without accidentally mutating the security rules of the Cabbage patch or the billing invariants of the Sunflower patch.

By isolating domain patches physically and logically, we prevent agents from hallucinating cross-domain dependencies or diluting core domain concepts.

Infrastructure as Gardening Tools, Not the Soil

A common architectural trap in modern engineering is confusing infrastructure with domain logic. Engineers often design around their database schema, queue broker, or cloud provider rather than around business capability.

In the allotment model:

Tools support the cultivation process, but they are not the crop itself. You can swap a hand trowel for an automated irrigation system without altering the genetic identity of the carrot. Likewise, an agentic workflow should allow underlying databases, frameworks, or agent runtimes to evolve without invalidating the core domain substrate.

Human as Steward, AI as Automated Cultivator

This lifecycle model redefines the relationship between human engineers and AI agents:

The human never abdicates responsibility for the quality or direction of the system. Instead, the AI agent removes the manual toil of digging, weeding, and watering, allowing the steward to focus on architecture, intent, and high-leverage judgment.

The Vault as the Ultimate Source of Truth

A foundational design principle of this architecture is filesystem transparency:

The workspace directory must remain completely understandable to a human without needing an AI agent or proprietary platform to interpret it.

If a new engineer opens the workspace vault in an ordinary file explorer or Obsidian editor, the entire project lifecycle should be physically visible:

  1. They can inspect 01. seed to understand where an idea originated.
  2. They can read 02. substrate to see how that idea was structured into domain requirements.
  3. They can check 03. greenhouse to review active experiments, test run logs, and current PRs.
  4. They can view 04. harvest to see the production codebase.

There are no hidden prompt histories, no proprietary cloud state databases, and no opaque vector indexes required to understand what the system is doing or why. The filesystem itself is the authoritative state machine.

Building in Tiny, Repeatable Increments

We are testing this lifecycle model not by building a massive monolithic agent, but through controlled, tiny increments:

  1. Discovery: Ingesting raw seed notes and validating that concepts can be extracted deterministically.
  2. Domain Modelling: Establishing clear boundary rules for each patch of domain soil.
  3. State Visibility: Ensuring every transition between lifecycle stages produces human-inspectable artifacts.
  4. Controlled Automation: Gradually giving AI agents access to external tools—Git pipelines, issue trackers, databases, and APIs—while keeping the overarching lifecycle model immutable.

The ultimate objective is a rinse-and-repeat delivery methodology: a structured, observable pattern that can be applied to radically different software projects without having to invent a new workflow every time.

The Question for the Future of Agentic Engineering

As AI capabilities advance, the core challenge of software engineering is no longer how fast we can generate syntax. It is how effectively we can manage context, boundaries, and system comprehension.

Can agentic software engineering become dramatically easier to reason about, audit, and scale if we make the project lifecycle physically visible and intuitive—rather than leaving it hidden inside a maze of prompts and ephemeral chat sessions?

By shifting our perspective from prompt engineering to allotment stewardship, we give both humans and agents a clear, shared ground on which to build software that lasts.