Semantic Engineering

Home / Follow the story / The full video

Loading the video
Transcript

1. Who holds the knowledge

The knowledge an enterprise application depends on falls into four kinds: functional, design, architecture and code. The product owner holds the functional knowledge: the personas, the outcomes, the scenarios, and the proposals that were rejected. The UX designer holds the design knowledge: the components, the interaction patterns and how each screen handles its states. The architect holds the architecture knowledge: the service boundaries, the databases that are the source of truth, and the integration contracts. The engineering team holds the code knowledge: the live functions, the retry policies, the active feature flags and the unused utilities. The product owner writes functional knowledge into prose specifications, the UX designer writes design knowledge into Figma handoffs, and the architect writes architecture knowledge into an architecture wiki. Much of the code knowledge stays in people's heads, each developer holding a narrow slice of the codebase. No single person and no document holds all four kinds of knowledge. The four roles are the custodians of the application's knowledge.

On the site: The Shared Problem · What the Custodians Know That the Code Does Not Show · The Landscape Today

2. One feature in one sprint

Consider one developer in a conventional Scrum sprint, working with an AI coding agent on a feature that lets users choose how often they receive saved-search alerts. The coding agent writes code in seconds: in one example, twenty minutes of typing becomes ninety seconds of reading and editing. Before the agent can write the right code, the developer needs four kinds of knowledge, and each kind comes from a person. For the functional knowledge, the developer has the product owner's one-paragraph user story, and three questions about it. For the design knowledge, the design system offers four controls, and the UX designer takes thirty seconds to name the right one. For the architecture knowledge, the architecture wiki has not been updated in nine months, so the developer asks the architect where the new data should live. For the code knowledge, the developer messages two colleagues, one of whom is away until Monday. Each message costs the person asking about thirty minutes, and each answer takes ten to fifteen minutes to write. The answers come back partial, and one contradicts the wiki. Code review catches one issue, integration testing catches another, and the third surfaces in production six weeks later. The coding agent saved minutes of typing, and the feature still waited on people. Each of these exchanges happens between two people, and none of them is recorded. The time and information lost in exchanges like these is what the methodology calls the Manual Translation Tax.

On the site: The Manual SDLC Problem This Zone Addresses · What This Looks Like on a Sprint · The Landscape Today

3. The Manual Translation Tax

The Manual Translation Tax is the recurring cost of knowledge and context lost at each handoff across roles, artifacts and tools, as documents, messages and memory become decisions and code. Every translation takes time, and every translation loses some information. A coding agent makes writing code faster, and leaves the tax where it is. The team's time goes into paying the tax, so faster code generation does not make the team faster. When one delivery team of thirty people was surveyed, 60 percent named estimation and understanding the existing code as places where the tax was paid. The tax has three components, and all three appear even on disciplined teams with good tools. The first component is ambiguity: the same words mean different things to different people. A product owner writes "let users save their search so they can return to it later". The frontend developer stores the search in the browser, the backend developer stores it in the database, and the QA engineer tests for a confirmation message. The difference surfaces in code review, and two weeks of work are partly redone. The second component is non-persistence: knowledge that was never written down is lost when the person who holds it leaves. When a senior engineer leaves, the team spends months rediscovering what she knew, usually when something breaks. A coding agent loses its knowledge the same way, because every new session starts with no memory of the last one. The third component is non-traceability: nothing records which parts of the code depend on a feature the user sees. When the alert frequency on saved searches changed from daily to weekly, some customers received both emails, because a worker in another repository still sent the daily ones. Nothing linked the alert frequency feature to that worker, and finding the cause took two days. The usual response to the tax is to write more documentation. On one platform team, roughly 40% of the architecture pages sampled were materially out of date by the end of the year. More documentation adds more text to translate, and the new text goes out of date in the same way. Removing the tax requires changing how the knowledge is recorded.

On the site: The Manual Translation Tax: The Cost, Named · Where the Manual Translation Tax Was Paid · Case Archetypes: Continuous SDLC

4. Why AI coding agents make mistakes

A coding agent working on the same feature faces the same gaps. The agent sees the codebase, the ticket and the wiki, and the wiki is often stale. The agent cannot see the direct messages, does not know which custodian to ask, and cannot ask anyway. Everything the four custodians know is invisible to the agent. In one example, an agent called a function the team had removed three sprints earlier, because the spec said the function existed. Coding agents do well on small, contained tasks, and make mistakes on the complexity of enterprise applications. On one codebase of more than two million lines, the team's AI coding tools produced isolated prototypes and no overall gain in productivity. On another team, an agent working from an out-of-date wiki needed so much back-and-forth that the change took longer than it would have taken by hand. Bigger context windows do not solve the problem, because more unstructured text gives the agent nothing it can check its work against. Building new applications, changing existing ones and modernizing legacy systems all face this gap, at different levels of complexity. The agent needs what the four custodians know written down in a structured form, which it can search for exactly the part each task needs.

On the site: The Shared Problem · Why AI Coding Agents Stall on This · The Manual Translation Tax: The Cost, Named

5. Four principles

Semantic Engineering answers the problem with four principles that apply to every kind of project. The first principle is to record the knowledge that governs the application in a knowledge graph, with explicit items and the relationships between them. Each agent asks the knowledge graph for just the part its task needs. The second principle is that every change is analyzed against the knowledge graph before code is written, and agents cannot ignore what the analysis finds. The specification still describes what to build, including the details the graph leaves out, and the knowledge graph governs how each change fits the application. The third principle is named ownership: every part of the knowledge graph has a person accountable for keeping it accurate. When part of the knowledge graph falls out of date, the methodology holds the owner of that part responsible. The fourth principle is validation gates: automatic checks that test every change against the knowledge graph. Each validation gate records a pass or a fail that the team can audit.

On the site: The Methodology · Agentic Software Engineering and Modernization, powered by Semantic Engineering

6. The four layers

For an application in use, the knowledge graph has four layers, and each layer is called an ontology: a structured description of one kind of knowledge. The Functional Ontology holds personas, outcomes, scenarios, steps and actions, and the Product Owner keeps it. The Design Ontology holds screen components and their building blocks, page templates and user flows, kept by the UX Designer and the design system owner. The Architecture Ontology holds services, boundaries, dependencies, data stores and integrations, kept by the Architect and the tech lead. The Code Ontology holds modules, classes, functions, endpoints and database schemas, kept by the Engineering Team. Links connect the layers, so one search can follow a user action through to the screen component, the service and the code function behind it. On one user story about email alerts, following those links found fourteen affected parts of the architecture and fifteen code changes across five repositories. The search runs before any code is written. Every item in the graph cites its source: the document, design frame, ticket or code file it came from.

On the site: The Four-Layer Ontology · Cross-Layer Traversal · Citations at Every Layer

7. What goes into the graph

A common first instinct is to put everything into the graph. Within a few sprints, the maintenance burden overwhelms the team. The methodology uses a rule, called the aperture, to decide what enters the graph. Every decision has a blast radius: the other decisions, artifacts and behaviours that have to change when the decision changes. A persona definition, a service boundary or a shared API contract has a wide blast radius, so it belongs in the graph. The wording on a single button affects nothing beyond that button, so it stays in the specification and the code. When the answer is unclear, the element stays out of the graph until the team is sure. The aperture starts narrow and widens as the team gains confidence, reaching its full width by about sprint twelve. The graph is partitioned by product, with one graph per product or application. Each graph is kept to one product, because the cost of a query grows with the size of the graph. Where two products integrate, links connect their graphs.

On the site: Aperture · The Blast Radius Test · How the Aperture Matures

8. Keeping the graph accurate

Every change is checked against all four layers of the graph before it can merge. An agent called the PR Validation Agent runs this check on every pull request before it merges into the main branch. The check fails when a change misses a required outcome, duplicates an existing design component, crosses a service boundary, or breaks something that depends on it. When the code changes, the KG Sync Agent updates the graph before the pull request merges, so the graph matches the main branch. The health of the graph itself is measured too, with twenty-nine metrics and fourteen verification checks. A merge that fails one of the most critical checks is blocked until the problem is fixed. The four custodians stay human. Each custodian works with information that exists only in conversations and decisions between people, such as customer calls, compliance decisions, vendor contracts and user research. No system an agent can read contains that information. Agents draft updates to the graph for the custodians to approve, and enforce the graph when code merges.

On the site: The Validation Gate · Governance and Metrics · The 14 Verification Checks

9. Two kinds of graph

Semantic Engineering covers three kinds of work: building a new application, called greenfield; changing an existing one, called brownfield; and replacing an old system, called legacy modernization. The three kinds of work use two shapes of graph, depending on whether the end state keeps changing or is fixed in advance. New and existing applications keep changing, so greenfield and brownfield work share the four-layer graph. A greenfield graph is built up as the application grows, and a brownfield graph is extracted from the existing application and then maintained by its owners. For an application of more than 2 million lines, extraction typically completes in two to three weeks. Legacy modernization has a fixed end state, chosen at the start of the project. The modernization graph has three parts: a graph of the old system built from its code, a graph of the new system defined by the custodians, and a specification that connects the two. The same four custodian roles govern both shapes. When a modernization completes, its graph converts to the four-layer graph. The right process for continuous work depends on how complex the application is.

On the site: One Methodology, Three Use Cases · Brownfield Extraction · Zones of AI-Assisted SDLC

10. When are specifications not enough?

AI coding tools are fast for one developer working on small, contained tasks. A small application that its team can hold in mind works well with a written specification for each change, which the coding agent builds from and the reviewer checks against. Specifications start to fall short as the application grows complex: a large existing system, a legacy code base, or work that crosses team boundaries. Each specification describes one change, and knows little about the rest of the application. Specifications drift from the code under deadline pressure. A specification carries the product owner's functional knowledge, and little of the design, architecture and code knowledge the change depends on. Writing specifications becomes the slowest step in the process. The knowledge graph sits alongside the specifications and supplies the design, architecture and code knowledge they lack. Each specification still describes the change, and the knowledge graph describes the application the change lands in.

On the site: The Four Zones · When This Zone Stops Working · From SDD to SE

11. Where is the state of the work kept?

Three records hold the state of the work, and each answers a different question. The specification says what one change should do. The ticket system, such as Jira, says who is doing what, and how far the work has got. The knowledge graph says what the application does today. The ticket carries each change from start to finish. When a specification is written, a hook in the ticket system runs impact analysis and attaches the report to the ticket. Every later step updates the ticket's status and attaches its results, such as test results and a second impact analysis after coding. At the end, the final impact analysis uses the whole history of the ticket. The ticket works the same way whether people, agents or both do the work. Teams design the workflow between the steps to fit their own process.

On the site: Three Sources of Truth · How the Ticket Carries the Change

12. Who prepares a change before coding starts?

With AI, writing code is fast, so preparing good specifications becomes the slowest step. The methodology gives that work its own sprint, the spec sprint, which runs a step ahead of the implementation sprint. The custodians meet for one or two days and work through several requests together. The product owner drafts the specification from a standard template. Impact analysis reports everything the specification will touch. Each custodian reviews the report for their own layer: functional, design, architecture and code. Impact analysis can show that a change needs new items, and the custodians propose them in the specification; the items enter the graph only when their code merges. The finished specification, with its impact report, goes into the implementation backlog. The implementation sprint works from specifications whose risks are already known. A specification that turns out to be missing context goes back to the spec sprint.

On the site: Why a Separate Cadence · The Mechanics · What Happens in a Spec Sprint

13. What does impact analysis tell you, and when does it run?

Impact analysis follows the links in the knowledge graph from a specification to everything it touches: outcomes, components, services, database tables and code. For people, impact analysis writes a readable report with the reasons for each finding. For another agent, impact analysis returns structured data that lists the IDs of the affected items in each layer. When an agent owns the work, the agent reads the structured form and continues without waiting for a person. Impact analysis runs when the specification is written, again after the code is written, and again at the pull request, using the whole history of the change. One example is the saved-search alert feature, on an application of 1.6 million lines. The report found three things that would have been hard to find by hand. The report found that the database already had the column the feature needed, so no database change was required. The report flagged a likely and serious risk: without a new filter, weekly subscribers would also receive a daily email. The report also set the order of deployment across three repositories. A senior engineer would need three to five working days to produce a comparable analysis.

On the site: What It Does · Two Kinds of Output · When Impact Analysis Runs

14. How do coding agents use the graph?

Developers keep the coding agents they already use, such as Claude Code or Cursor. The coding agents connect to the knowledge graph through the Breeze.AI MCP server, a standard interface that AI tools use to call other services. The impact report goes into the coding agent's prompt. With the report in its prompt, the coding agent knows which services, components and tables the change must touch. The coding agent cannot ignore what the impact report found, and the specification tells it what to build. Rules for the functional layer are checked on the developer's machine before any change reaches the graph. Code generated twice from the same prompt still differs in detail, such as variable names and the order of operations. The impact report fixes the structure of the change, so the remaining differences are in detail only. Code review moves from asking whether the agent changed the right files to asking whether the details are right.

On the site: The Claude Code Plugin · Integration Surface · Ontology Guardrails

15. How is each change checked, and how does the graph stay current?

Every pull request goes through the PR Validation Agent before it can merge. The PR Validation Agent compares the change with the impact report, and checks the change against all four layers of the graph. The check fails when a change misses an outcome the specification required, duplicates an existing design component, crosses a service boundary, or breaks something that depends on it. A failed check names the violation and the item in the graph involved, and a mismatch with the impact report goes to a person for review. Style, linting and unit test coverage stay in the team's existing build pipeline. The BDD Generation Agent writes test scenarios from the functional layer, each describing how the application should respond to a user's action. Before the pull request merges, the KG Sync Agent updates the graph to match the new code. The graph then matches the main branch, and the next impact analysis runs against the application as it is.

On the site: The PR Validation Agent · What the Gate Checks · What the Gate Does Not Do

16. Who decides which work agents do?

Every agent has a named human owner, and no agent runs on its own without one. People decide which work goes to agents, in sprint planning or in support triage. Work with a repeatable pattern suits an agent: support requests, customer customizations, changes to workflows and forms, new fields and custom reports. An agent takes on a pattern once it has a record of reliable results on that pattern. New scope stays with people, because a new feature needs product, design and architecture judgment. Agents earn autonomy over five levels, from suggesting a change to acting without review. Each step up is recorded in a written agreement that names the evidence, the threshold, the person who approved it, and the conditions for stepping back down. When an agent's results fall below the threshold, the agent steps back down automatically. The agents that run impact analysis and pull request checks typically operate at the fourth level, where people review their results on a regular schedule.

On the site: Which Work Goes to Agents · Progressive Autonomy · The Five Levels

17. How do managers see what people and agents are doing?

Managers see the work of people and agents in the ticket system they already use. Every step of a change updates the ticket, whether a person or an agent did it. Some products receive support and data requests at a volume a ticket system handles poorly, because it holds no knowledge of the application. For those products, the requests can move to an agent workbench. Triage agents in the workbench classify every request, apply the product's own priorities, and route the request to a person or to an agent. Metrics are kept per product, per graph and per agent. Organizations bring these metrics into their own reporting.

On the site: How the Ticket Carries the Change · High-Volume Support Work · Governance and Metrics

18. What happens across many products?

Each product has one knowledge graph, shared by every team that works on that product. Graphs are kept to one product because queries slow down as a graph grows. A portfolio adopts the methodology one product at a time. The first product builds its graph, sets up the process, and hands its repeatable work to agents, and after a few months the next product follows. Some knowledge belongs to the whole enterprise: compliance and security rules, infrastructure preferences, shared deployment pipelines, and an enterprise design system. Enterprise knowledge is defined once, and every product's agents read it according to their access rights. Where products integrate, impact analysis follows the integration points into the other products' graphs. Every quarter, an agent looks across the product graphs for capabilities that are duplicated or no longer used.

On the site: Partition by Product · What Decides It · One Graph for All of a Product's Teams

19. What about existing systems and technical debt?

For an existing application, agents extract the knowledge graph from the code, and the custodians review it. Extraction typically takes two to three weeks for an application of more than two million lines. Extraction shows the application as it actually is, including duplicated and tangled parts that nobody had mapped. Agents that write code quickly can also add technical debt quickly. An enterprise often decides on a target that some products have not reached yet. One example is a new authorization service that some products have not adopted. Until the change reaches the code, the target lives in the specifications, because the knowledge graph keeps strict parity with the code. When a change touches that area, impact analysis shows everything in the current code that the change touches, and the specification can move that code toward the target. Large-scale legacy modernization is the exception: there, the target has a graph of its own.

On the site: Brownfield Extraction · Extraction as Rationalization · Paying Down Technical Debt

20. What changes for the team?

The sprint, the ticket system and code review stay as they are. The team adds a spec sprint ahead of implementation. The team works in three layers: the custodians, the implementation teams, and an enablement layer from Accion Labs. Forward-deployed engineers from Accion Labs fill any custodian role the client cannot staff yet. Specialists work part-time across several workstreams, and one architect can cover two or three of them. The custodians stay human. Much of what the custodians know comes from customer calls, compliance decisions, vendor contracts and user research, which no agent can read. Agents draft updates to the graph, and the custodians approve them.

On the site: The Layered Team Structure · Forward-Deployed Engineers · Fractional Allocation

21. What results have teams seen?

Engagements under Breeze.AI report these results, each in its own context. On one engagement across three products, deployments rose from 19 to 36 a month over a fourteen-week pilot. On the same engagement, lead time for changes fell from 2.0 to 1.42 days. Extracting the graph from a codebase of more than two million lines took two to three weeks. On one brownfield application, impact analysis replaced three to five days of investigation by a senior engineer before each change. In the first sprint of a new user-interface workstream, 53% of design components were reused. Defects fell 23% compared with the same team's results before Semantic Engineering, on the same codebase. Test coverage reached 93.4%, with test scenarios generated from the functional layer and no manual scenario writing. A cost model puts five-year total cost 81% lower when the AI runs on the client's own infrastructure; the figure comes from the model and was not measured on an engagement.

On the site: Numbers from Real Engagements · Case Archetypes: Continuous SDLC

22. The modernization tax

In a legacy modernization, a team replaces an old technology stack with a modern one, and keeps the behavior the business has built up over years. The people who could once explain the legacy system are often retiring, scarce or already gone. The legacy code is the only authoritative record of what the system actually does. The cost of working from that record by hand is the Modernization Translation Tax, and the tax has four components. The reverse-engineering tax is the work of finding out, from the legacy code, what the system does, which needs senior engineers. The lost-context tax covers business decisions the code does not show, such as deliberate edge cases and old workarounds. The validation-vacuum tax arises because nothing can test the old behavior automatically, so every migrated module needs a hand-built check that it behaves as before. The knowledge-disappearance tax arrives after the project, when the people who built up the understanding leave with the engagement. The first three components make each other worse. Without an executable contract that proves the new system behaves like the old one, nobody can show the migration is complete. A modernization that cannot be proven complete stalls before it can deploy.

On the site: The Modernization Version of the Problem · The Four Components · Why the Tax Compounds

23. Graphs of the old and new systems

The methodology replaces this manual work with three structured records, each fixed for the length of the project. The Source-state ontology is a graph of the old system, built from the legacy code by agents: its files, classes, functions, statements and APIs. The Source-state ontology keeps the actual code statements, as evidence of the behavior the new system must reproduce. The Target-state ontology is a graph of the new system, built from the target blueprint: its architecture, runtime, standards and design system. The specification connects the two graphs, and produces a requirements document, test scenarios, end-to-end test scripts and a chatbot that answers questions about the code. The Product Owner and Architect mark every module of the old system, in the specification, with one of four decisions. Retain keeps the module's behavior while its structure changes. Modify changes the behavior in defined ways that the Product Owner records. Replace hands the function to a different solution, such as a modern library. Retire removes the function, and the retired items stay documented. A module without a decision cannot be migrated.

On the site: The Three Modernization Ontologies · The Source-State Ontology in Detail · The Target-State Ontology in Detail

24. The parity contract and the four gates

Together, the two graphs and the marked-up specification form the parity contract: the agreed definition of how the new system must behave, which the agents must follow. Neither the recorded legacy behavior nor the target architecture can change during the project. Migration agents write the new code one module at a time, from the specification and the Target-state ontology. Every piece of migrated code then passes through four validation gates, each run by its own agent. The architecture gate checks conformance to the target blueprint's architecture. The design gate checks the design system and UI guidelines. The standards gate checks security rules and coding standards. The functional gate checks that the new code behaves like the legacy code recorded in the Source-state ontology. Code that fails any gate goes back with the gate's evidence attached, until all four gates pass. Nine named agents cover five stages: Discover, Document, Migrate, Validate and Maintain. People check the work at two points: the decisions in the specification before migration, and a modernization expert's review of the code that has passed the gates. The five stages run on a platform called ASIMOV.

On the site: The Parity Contract · Named Agents · Validation Stage Agents

25. Five engagement modes and five delivery stages

A modernization client enters through one of five engagement modes, each sized to the work the client is ready to commit to. The modes differ in how much of the work the client takes on. Documentation Only produces documentation and test scenarios from the legacy code, with no migration. Discovery and Documentation adds an inventory of the applications, maps of their dependencies, the business rules, and review material for subject-matter experts. Migration Readiness adds a scope for each module, its place in the new system, the order of migration, and the marked-up specification. Full Modernization runs the whole pipeline, over quarters to years. Maintain, Operate and Convergence keeps the knowledge graph up to date on the modern system. Each mode addresses a defined part of the modernization tax, and a client may stop at any mode. Full Modernization runs in five stages: discovery and analysis, building the graphs, migrating one first module, migrating the rest, and user acceptance testing with deployment. While the first module is migrated, subject-matter experts review the output and tune the agents to the project.

On the site: Why Engagement Modes · The Five Engagement Modes · MTT Components Addressed by Each Mode

26. Results, and the handover

More than fifteen million lines of legacy code have been modernized with ASIMOV, across more than ten programs. On a one-million-line standalone codebase, the indicative figures are up to four times faster than manual modernization, and up to seventy percent less migration time. An inventory and warehouse platform moved 2.1 million lines from Java 8 to Java 21 in about three and a half months. A European education-technology provider moved three million lines of Delphi to cloud-native .NET 8, with about sixty percent less effort than manual. Actual outcomes vary by engagement scope, target stack and the modules selected. When a modernization completes and the client wants ongoing governance of the new system, a four-layer graph is built for it. The code layer is then extracted from the new code by Breeze.AI's agents, so the graph matches the modernized system from the start. The Retain and Modify decisions in the specification become the starting point for the functional layer. The target blueprint becomes the starting point for the architecture and design layers. The same four custodians continue, and the work moves from project stages to regular sprints.

On the site: Numbers from Real Engagements · Aggregate Track Record · Version and Platform Upgrade: Inventory and Warehouse

27. Engagement phases

A continuous SDLC engagement runs in four phases: Advise, Launch, Scale and Optimize. Advise takes two to four weeks, assesses how the team uses AI today and where it meets friction, and produces a scoped roadmap and a platform recommendation. Launch takes about twelve weeks, builds the four-layer graph for the highest-priority product, and puts the validation gate in place on every pull request. Scale extends the methodology across the portfolio over quarters to years, with agents gaining autonomy on routine, repeatable work. Optimize is continuous operation, with governance audits every quarter and regular clean-up of the graphs. In every phase, the client's four custodians own the four layers of the knowledge graph. During an engagement, Accion Labs customizes the platform, sets up the initial graph, and provides managed support in one of three tiers. For the end of an engagement, Accion Labs makes four commitments. The graph can be exported, the agents can be reproduced, the governance framework is documented, and the roles Accion Labs filled can be handed to the client's own staff.

On the site: The Four Phases · Advise · Launch

28. Two engagements

Two anonymized engagements show the methodology at work on continuous SDLC. The first archetype is a live code base of more than two million lines, with five to six scrum teams. Extracting the graph from the code built all four layers in two to three weeks. On the extracted graph, impact analysis replaced three to five days of investigation by senior engineers. The second archetype is a new user-interface workstream that grew in complexity, and started with the design layer of the graph. In its first sprint under Semantic Engineering, the workstream reused 53 percent of its components from the existing design system. In both engagements, structured knowledge was added exactly where the specification alone was not enough.

On the site: The Archetypes · Brownfield Enterprise Modernization · What Changed in How the Team Works

29. Products that agents use

Software products are starting to open their capabilities to their customers' own agents, which act on the customer's behalf through interfaces such as MCP servers. An MCP server that exposes hundreds of tools gives an agent access, and still leaves the agent to work out which tools to use, in what order and under which rules. The knowledge graph already records what the product provides: its capabilities, workflows, entities and contracts, which are the domain invariants every customer shares. An interface for agents can be built from the graph, describing each capability in the terms of the domain, independently of the screens and APIs designed for people. The graph also governs which external agent may use which capability. A formal grammar above the graph adds the rules a schema cannot express, so an agent can write what a customer needs and check its own result by running tests. Dialect engineering is the name for this approach, which lets more of a software-as-a-service product vary per customer while the domain invariants stay shared. Dialect engineering is set out at dialect-engineering.ai, and it builds on a knowledge graph governed with Semantic Engineering.

On the site: Graphs for Agent-Facing Products

30. Where it came from

Semantic Engineering was assembled over eight years of client work at Accion Labs, from 2017 to 2025. In 2017, an internal Accion Labs framework called Breeze set out what product owners, UX designers and architects need to produce. Teams maintained the Breeze documents by hand, and tended to drop them under deadline pressure. In 2022, on a drug-discovery project for a pharmaceutical client, connecting the AI model to a knowledge graph kept its hallucinations, the answers it invents, under control. In 2023, the knowledge-graph approach became a commercial platform, KAPS, used across customer engagements. By 2024, the Breeze guidelines had become the four layers of the knowledge graph, with agents built around them, in a platform named Breeze.AI. The method took the name Semantic Engineering in 2025. The framework and concepts of Semantic Engineering are public and free to apply. The methodology runs on Breeze.AI for new and existing applications, and on ASIMOV for legacy modernization. Teams can adopt the methodology with Accion Labs, and an engagement can start with a two-day workshop.

On the site: The 2017 Framework: Breeze · The 2022 Discovery: Drug Discovery and Hallucination · Productizing the KG Approach: KAPS, 2023

Choose a path

The full video in six parts and an appendix, one part at a time.

Act 3Knowledge graphs and agents in the AI-driven SDLC, with Breeze.AIPlay →
  1. 10When are specifications not enough?
  2. 11Where is the state of the work kept?
  3. 12Who prepares a change before coding starts?
  4. 13What does impact analysis tell you, and when does it run?
  5. 14How do coding agents use the graph?
  6. 15How is each change checked, and how does the graph stay current?
  7. 16Who decides which work agents do?
  8. 17How do managers see what people and agents are doing?
  9. 18What happens across many products?
  10. 19What about existing systems and technical debt?
  11. 20What changes for the team?
  12. 21What results have teams seen?