Agentic Software Engineering and Modernization, powered by Semantic Engineering

Semantic Engineering is the methodology we developed at Accion Labs for running AI agents reliably inside enterprise software work. It treats the knowledge an agent needs as a queryable graph, constrains generation through that graph, and governs the graph through named ownership and validation gates so it stays honest as the work proceeds. The same principles apply whether the team is building new software, evolving live software, or modernizing legacy software.

This page is the executive overview. Each section links to a deep dive in the topic area it summarizes. If you want to jump straight to a use case, the two anchor sections are Agentic Software Engineering (SDLC) and Agentic Legacy Modernization.

The Shared Problem

Enterprise software work is hard because the knowledge that holds a system together lives in heads, decaying documents, and code that is opaque without interpretation. In a typical enterprise application, four roles carry that tacit knowledge:

• the product owner holds the why (personas, outcomes, scenarios, rejected proposals)
• the architect holds the where (service boundaries, source-of-truth databases, integration contracts)
• the UX designer holds the how it looks and behaves (components, interaction patterns, state handling)
• the engineering team collectively holds the what the code actually does (live functions, retry policies, active feature flags, dead utilities)

No single human holds the whole picture and no document does either. AI coding assistants do well on small, contained tasks but break against this complexity because they have no structured way to query the system’s actual state. Bigger context windows do not fix this. The agent needs structured context it can read against, not more raw text to wade through.

Every use case in a typical enterprise portfolio hits the same wall. Greenfield work needs the new application to fit a landscape it has not yet been built into. Brownfield work needs to reason about dependencies inside the live application as it evolves. Legacy modernization needs to honor years of accumulated behavior while replacing the stack that produced it. The complexity differs by use case, but the structural gap is the same.

The full problem treatment is in The Manual Translation Tax for continuous SDLC and The Modernization Translation Tax for legacy modernization.

The Methodology

Semantic Engineering responds to the structural gap with four universal principles that hold across every use case.

The principles are universal. The shape of the graph and the rhythm of the operating model differ by use case because the questions each use case asks are different. The next section shows how the same principles instantiate across the three use cases the enterprise portfolio actually contains.

One Methodology, Three Use Cases

The three use cases collapse into two graph models on the question of whether the target is fixed or moving. Greenfield and brownfield both have a moving target and share the four-layer ontology of a live application, curated continuously by the four custodians. Legacy modernization has a fixed delivery target and uses a different ontology shape sized for the bounded scope of the work. The same four custodian roles govern the modernization ontologies; the target state itself is defined and governed by the Product Owner, Architect, UX Designer, and Engineering Team rather than handed over as a static input.

The four-layer ontology and the Source-state / Target-state / specification format are two instantiations of the same methodology. The diagram below contrasts the two graph models directly.

A side-by-side view of the three use cases against the dimensions that matter most:

When a modernization completes and the client wants ongoing SDLC governance on the modern system, the modernization graph converts to the four-layer ontology and the engagement continues under the continuous SDLC instantiation. The methodology covers both halves of that lifecycle.

Topic by Topic: How the Methodology Stays Consistent

The site is organized so a reader can walk either use case end to end across the same six topics. The table below shows how each topic instantiates on each side, with deep-dive links per cell.

The structural response is the same in both columns. The shape of the response differs because the work asks different questions.

Two Platforms, One Methodology

The methodology is operationalized by two production platforms. Each one is sized for the use case it serves.

The platforms are peers under the same methodology. They differ in graph shape and operating cadence because the use cases differ. They share the same principles, the same enablement discipline, and the same governance posture.

Numbers from Real Engagements

Outcomes measured on engagements running under this methodology. Anonymized walkthroughs are in the case archetype pages linked above.

Continuous SDLC engagements under Breeze.AI:

Legacy modernization engagements under ASIMOV:

How We Arrived Here

Semantic Engineering started in 2017 as Breeze, an internal framework of role-based guidelines and templates for product owners, architects, and UX designers. When Gen AI entered our work in 2022 on a pharma drug-discovery engagement, we found that grounding models with a knowledge graph kept hallucinations under control. In 2023 we productized the knowledge-graph approach as KAPS and rolled it out across customer engagements, so the methodology was in commercial use well before it had a name. By 2024 we had converted the Breeze guidelines into the four-layer ontologies and built agent fleets around them, naming the resulting SDLC platform Breeze.AI in tribute to its 2017 ancestor. The legacy modernization shape of work demanded a different graph model and a different agent fleet, which became ASIMOV. The discipline took the name Semantic Engineering in 2025.

The full origin story is in Origins.

What We Believe

Domain knowledge, from intent to implementation, should be stored in a machine-readable, interconnected semantic model that admits only one valid interpretation, persists across time, and maintains traceable connections across every layer.

Every choice in the methodology traces back to this commitment. The four ontology layers, the partition rule, the validation gates, the agent fleet, the enablement partnership. Each was added because it made the commitment operational in some specific way we had run up against on an engagement.

Where the Industry Is

Snowflake’s semantic layer, Microsoft’s knowledge graph integrations in Fabric, and Palantir’s ontology positioning have all shipped or matured in the last twelve months. The market is converging on what we concluded in 2022: enterprise AI needs structured context to operate at scale, and a knowledge graph is the practical way to provide it.

Beyond the commercial vendors, open-source projects like Graphify have started building knowledge-graph context layers around code. The technical direction is broadly consistent with what we have been building. These efforts today focus primarily on the Code layer of what we treat as a four-layer ontology. The Functional, Design, and Architecture layers, the cross-layer relationships, the enablement partnership that keeps the graph healthy over years, and the operating model that makes the methodology run at enterprise scale are not yet part of these efforts. We expect open-source to fill in over time, and we will be glad when it does.

Where to Go Next

About the Methodology

Semantic Engineering is proprietary to Accion Labs. The framework and concepts are public, documented on this site, and free to apply. The methodology mark is reserved.

If you want to adopt the methodology in your own organization, the content here is everything you need to understand it. If you want our help running it, the Practitioner section describes how we engage.

Talk to us about adopting this for your team.