Graph Engineering Is Thirty-Nine Years Old

The AI community has named “graph engineering” something software engineering has been building since 1987. The version now popular leaves out the parts the earlier work found hardest.

This post was written with the assistance of Claude. The ideas, positions, and reasoning are mine. I have used Claude to retrieve and organize all the sources cited in the article. Don’t hesitate to contact me to signal mistakes or misinterpretations.

The post in three sentences

1. The term “graph engineering” went from a single remark on X to the history of a three-year discipline in five days, and the company behind the framework it names has said in public that the idea is not new.

2. Graph Engineering is a smaller version of the software process work starting in 1987: the process model reduced to nodes and edges, the specification reduced to prose in headed sections, in both cases without the notions the earlier work had found necessary.

3. These results belong to a neighboring discipline, not to the AI community’s own past: that discipline produced them, tested them in industry, and wrote down where each one failed, so rebuilding them without reading any of it means paying twice for mistakes already discussed.

---

At 00:34 UTC on Saturday, 18 July 2026, Peter Steinberger posted a single sentence on X: “Are we still talking loops or did we shift to graphs yet?” The sentence is often credited with introducing the term “graph engineering,” but it does not contain it.

Four and a half hours later, Hamel Husain published a piece titled “Loop Engineering Is Dead. Enter Graph Engineering”, which several readers took as satire. The label was older than both: an essay dated 4 July had already proposed it deliberately, and the two words have appeared in technical print since at least 2016, in quantum walks and in object graphs, with an unrelated meaning.

The tweet put the label into circulation. By Monday, it had spread far enough for Harrison Chase, the author of LangGraph, to reply: “So i didn’t really know what graph engineering is, and i still don’t really… but it’s basically just langgraph?” On Wednesday, LangChain published “3 Years of Graph Engineering with LangGraph”, calling the expression “the latest term to come out of X’s AI content factory”, and settled the question: “Graph engineering isn’t a new idea. It’s the latest name for a well established approach to building reliable agents.”

Five days were enough to carry the label from an isolated remark to the corporate history of a three-year discipline. The term it displaced, “loop engineering”, had itself been in circulation for a few weeks.

The idea is old, and this is undisputed: LangChain states this directly. What no one is examining is the nature of that idea and when it was first developed. Software engineering built it between 1987 and the end of the 1990s, under the name “software process”: a body of languages, environments, and industrial experiments that is described in the next section. The version now returning under the name “graph engineering” retains only part of it. A discipline that names its concerns in this order — prompt engineering, context engineering, harness engineering, loop engineering, graph engineering — is reconstructing, one term per quarter, a body of knowledge available in published form. And each reconstruction is narrower than the material it reproduces.

The existing corpus

In the spring of 1987, at the ninth International Conference on Software Engineering in Monterey, Leon Osterweil gave a plenary talk whose title set the direction for the next fifteen years of research: “Software Processes are Software Too”. He claimed that the process used to build software is itself an artifact, and can therefore be written in a language, analyzed, executed, and improved.

A research area grew from it, with its own workshops, journals, and industrial programs. The languages were called Process Modeling Languages, and the environments that interpreted them were Process-centered Software Engineering Environments. The paradigms varied: high-level Petri nets in SPADE and in FUNSOFT nets, a logic-based language in Latin, which drove the Sentinel environment, and Osterweil’s own process programming, first in an extension to Ada and later in JIL. Running a process model was called enactment. The environments helped the people doing the work, automated routine steps, and invoked and controlled the tools.

I worked in this area for several years. In 1995, with Sergio Bandinelli, Luigi Lavazza, Maurizio Loi, and Gian Pietro Picco, I published in IEEE Transactions on Software Engineering an account of one such experiment: the anomaly management process of the Business Unit Telecommunications for Defense at Italtel, written partly as finite state machines and partly in SLANG, our Petri-net-based language. The model contained twenty-four SLANG activities. A finite state machine held the states an anomaly report could be in; a net held the coordination among the configuration management group, the change control board, and the qualification subgroup.

Nodes, edges, states, transitions, persistent state, and an engine that advances the model one step at a time. The LangGraph documentation — “At its core, LangGraph models agent workflows as graphs”, with nodes that “encode the logic” and edges that “determine which Node to execute next” — describes, word for word, what we built in 1995. Microsoft’s Agent Framework uses almost the same terms: “A Workflow ties executors and edges together into a directed graph and manages execution.” Google’s ADK 2.0 has made the graph the runtime itself, to the point that its base agent class now inherits from a base node class.

The process model of the 1990s and the agent graph of 2026 are the same concept, aiming at the same target, three decades apart.

Software Process was not the only research area addressing these topics. The same route was traveled by workflow management systems and BPMN, and later by tools that industrialized them: Apache Airflow, which since 2015 has had data engineers describe their pipelines as directed acyclic graphs of tasks, and AWS Step Functions, which since 2016 has orchestrated cloud services as state machines. That is why the LangGraph documentation cites Pregel, and not Osterweil. The notation survived the journey; the research that explained where it breaks did not.

Reduction, first instance: the process

A process model of the 1990s held three things beyond control flow, and the roadmap I wrote for ICSE 2000 lists them in that order. It held roles: who may perform an activity, and what to do when that person is not available. It treated artifacts as typed objects with a life cycle, so the model knew that a specification document was not a test case and which versions of which items had to remain consistent with each other. And it held tools, with the conditions under which each one is called.

Some of this exists in the current frameworks, and it would be wrong to say otherwise. Microsoft validates a workflow as built, ensuring that message types are compatible across connected executors. Google’s ADK stores artifacts as named, versioned, MIME-typed objects behind a service. CrewAI requires a role string on every agent. So the payload is often typed, and the actor often has a name.

The people are there. LangGraph can stop a run and wait for someone; Google’s ADK asks for confirmation before a tool call. Every serious framework has a way to hand a decision to a human. So these systems coordinate models, tools, and people, which is the same mixed set that the 1990s models coordinated. What they lack is any notion of which person, with what authority, and what happens when that person does not answer. A stopping point without a role is the gap the earlier work had filled.

The largest omission is not on that list. The paper we wrote in 1995 spent its analysis on a distinction that has no equivalent in today’s tools: the process the owner wants, the process as written down, the process each participant believes is in force, the process an observer records, and the process that actually runs. We called them the Desired, Official, Perceived, Observed, and Actual processes, and we concluded that together they form “an unstable feedback system in which stability can only be enforced by reducing the sources of divergencies”.

Robert Balzer had drawn the practical consequence four years earlier, in “Tolerating Inconsistency” at ICSE 1991. A formal system cannot reason usefully once an inconsistency is present, and real development is inconsistent most of the time; a support system should therefore tolerate inconsistency and mark it, so that whoever can resolve it is told, and the parts of the system that cannot handle it are shielded from it. That was a minority position in 1991, and it is the point on which the whole line of work eventually turned.

Part of that apparatus has been rebuilt. Tracing and evaluation are an established product category: a trace records the Observed Process, and an evaluation measures the distance between the result wanted and the result obtained. What is missing is the comparison itself — a declared model to check a trace against, so that a departure is reported as a departure rather than a lower score. The Perceived Process has no name in this vocabulary, as the participants are assumed to be executors.

Reduction, second instance: the specification

The same compression has occurred more visibly in specifications.

The best answer the agent community has produced to ungoverned code generation is spec-driven development: write down what the system must do before the agent writes it. The reasoning is sound, and it is the reasoning software engineering has used since the field had a name.

GitHub’s Spec Kit, public since August 2025 and announced in September, is the most widely adopted case: it organizes a project around a constitution, a specification, a plan, and a task list, written as markdown in headed sections and read by a model. Amazon’s Kiro goes further in one respect, writing its requirements in EARS, a template syntax built at Rolls-Royce for aero engine control systems, which Kiro renders as WHEN [condition/event] THE SYSTEM SHALL [expected behavior]. That is a real constraint, and it is the mildest form of an old one. EARS itself is finer grained: its event-driven pattern reads WHEN <optional preconditions> <trigger> the <system name> shall <system response>, and separating the precondition from the trigger is the point of it. The reduction has happened here too, inside the one place where the specification was supposed to get more precise. Fixing the shape of a requirement so that it can be checked is an idea the field had been working on long before EARS gave it a tidy name, and the A-7E tables discussed below had taken it much further decades earlier.

Prose in headed sections has no formal semantics, no type system, and no mechanical checks for consistency between documents. Spec Kit has added a command that asks a model to check the specification, the plan, and the task list against each other. That admits the problem and answers it with a second model’s judgment.

The SE corpus offers a different comparison. Hoare’s axiomatic basis for computer programming dates from 1969 and gave a program a formal meaning: the axioms and rules of inference were to be “the ultimately definitive specification of the meaning of the language”. VDM had come out of the IBM laboratory in Vienna at the end of 1972. Z was written by Jean-Raymond Abrial in France in 1977 and developed further at Oxford after he arrived there in 1979. At the Naval Research Laboratory, Kathryn Heninger, David Parnas, and their colleagues rewrote the requirements of the A-7E aircraft’s navigation and weapon delivery program as tables of functions, to show that software engineering principles held up on a real embedded system running in twelve thousand instructions and sixteen kilobytes of memory. The exercise produced a finding worth keeping: “Writing down the requirements turned out to be surprisingly difficult in spite of the availability of a working program and experienced maintenance personnel.” Harel’s statecharts, published in 1987, gave event-driven behavior a formal semantics, which STATEMATE made executable and which Simulink Stateflow later carried into industry, so that a specification could be simulated, code generated from it, tests derived to coverage criteria, and safety properties checked by machine. Alloy made lightweight formal modeling automatically analyzable. And IEEE 830, the recommended practice for requirements specifications, now replaced by the international standard ISO/IEC/IEEE 29148, put the reason in four words: “Natural language is inherently ambiguous.”

Most of these notations were built for reasons that recur in the papers introducing them: a specification in natural language admits contradictory readings, and the contradictions are found late, in the running system, by its users.

Almost sixty years of work on that problem, and the state of the art in agent tooling is prose in headed sections.

The notation is the smaller part of what is being ignored. Current discussion of agent-assisted development keeps arriving at one recommendation, offered in good faith: write good requirements. It is put forward as though the writing were the easy part, and as though the whole problem fitted into a well-organized markdown file.

Requirements engineering exists as a field, with a conference series since 1993 and more than thirty years of results, because that is false. It established that requirements are negotiated, not collected, among stakeholders whose aims are legitimately incompatible; that much of what matters is tacit and goes unsaid even by the people who hold it, which is why elicitation is a technique and not a meeting; that requirements change while they are being written, at a rate set by the domain rather than by the analyst’s competence; and that judging a requirement correct, rather than merely well formed, needs a reference outside the document, which is the one thing a document cannot hold.

Fred Brooks made the point in the version of “No Silver Bullet” that reached most readers in 1987, the year of Osterweil’s talk: “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems.” In the volume where I wrote about software processes in 2000, the requirements engineering roadmap by Bashar Nuseibeh and Steve Easterbrook is the paper immediately after mine, and the open problems it lists are still open.

Design has had the same treatment. Architectural styles, architecture description languages, and the design rationale tradition are decades of work on how to record why a system has the shape it has, so the reason outlasts the person who had it. The current answer is a paragraph of prose in plan.md.

“Write good requirements” restates the problem as if it were the solution. It is where the field stood before it had any results, offered now as its conclusion.

I am not arguing that agent projects should be written in — say — Z. Most should not, and the formal tradition stayed in a niche for a real reason: the models cost more to write and keep current than the work they described. I am arguing that a field that has decided specifications matter, and that has a whole discipline’s worth of results on how to write them, might read some of them before settling on markdown.

What went wrong the first time

When I assessed software process research for the Future of Software Engineering track at ICSE 2000, the finding on one specific line of work was blunt: after more than ten years of research on process modeling languages and the environments that interpreted them, none of the approaches had reached industrial practice. The diagnosis had two parts. The languages were built to be executed, which pushed them toward completeness and detail, which made them cost more to write and maintain than the work they described. And the environments got in the way, because a model detailed enough to run is a model rigid enough to obstruct. What reached practice, and is still here, was configuration management, which worked because it automated only the process fragments that were reasonable to automate. The same holds for what later became ITSM (IT Service Management), on the operations side.

The update I wrote with Elisabetta Di Nitto in 2014, for the same track, found no reason to change the original argument. On the languages: “Many languages developed during the 90s were too complex and rigid. In general, they turned out to be difficult to apply in real settings and not capable of producing a concrete impact on software development practices… But PMLs went too far and basically ‘missed the point’.” On the scope of automation: researchers “have recognized that the possibilities of fully automating them are limited to specific aspects and phases such as code generation, testing, packaging, deployment and operation management of final products”. The lesson is that prescriptiveness has a ceiling, and that going past it turns a support system into an obstacle.

Fundamentals without a source

On 14 August 2026, Andrew Ng published what he called The AI Engineering Skills Map, based on an analysis of over 10,000 job postings and a set of expert interviews. Four skills emerge from it: building and deploying AI applications, software engineering fundamentals, using coding agents, and shaping the build. On the second, he is explicit and correct: knowing the fundamentals is what lets an engineer see which tradeoffs exist and steer an agent “using the precise language of software engineering”.

The map, though, is filed under AI engineering. I wrote a few days ago about the two questions that fall under one phrase: how to use AI when building an information system, and how to build a product made with AI. Ng’s map seems to answer the second and borrows the first’s vocabulary. The fundamentals it invokes belong to a discipline that is not the map’s subject.

The precise language of software engineering is precise because someone wrote it down. It has notations, standards, results, and a record of what happened when it was used. The fundamentals are written down in textbooks, in SWEBOK, and across an entire academic discipline. Saying where they are written is the part the map omits, and without it, the instruction stays an exhortation.

What has changed

There is a version of this argument that ends in complacency, and I want to avoid it. The corpus did not fail because practitioners were incurious. It failed for two real reasons.

Writing and maintaining a formal model cost more than the work it described. And a deterministic engine, given an incomplete or inconsistent model, either stops or forces a resolution that throws away information the situation held. That is fatal because incompleteness and inconsistency are the normal state of software development, not defects in it. It was the hardest point, and the one where the technology of the time broke: a formal language flexible enough to tolerate deviation is close to a contradiction in terms.

Not everything in the earlier diagnosis was about cost. The 2014 paper gives a second reason, and it is the one that still holds: software development is human-centered, creativity and autonomy are decisive in it, and most of its activities therefore cannot be rigidly automated. What automates well is what is repetitive and error-prone, which is why configuration management and deployment worked. That criterion is about the nature of the activity, not about the price of writing a model for it, so a fall in cost does not affect it.

The two obstacles above are the ones that new technology can remove, and the two claims are not of the same kind.

The first is a hypothesis. Drafting a model, keeping it aligned with the system, and deriving one representation from another are tasks a large language model can perform, so the cost that once blocked this work in the 1990s may no longer be prohibitive.

The second does not depend on cost at all. An executor that generates rather than computes can continue with a partial model instead of stopping at it. A departure comes out as an output to judge, not as an error that halts the run.

The property this delivers already has a specification, written twelve years ago and never claimed. The 2014 paper has a section titled “From Rigid Compliance to Smart Convergence”, and its argument runs: “In software development, consistency is the exception and inconsistency is the most common state. Therefore, it is impossible to impose a rigid adherence to a (often strictly) predefined set of rules and constraints. Rather, it is much more important to ensure that the process as a whole ‘converges’ towards the desired outcome, tolerating, controlling, and exposing inconsistencies as they occur… In process automation and support, it is therefore essential to make inconsistencies a ‘first-class citizen’, helping software developers to visualize, monitor, and manage them, rather than ‘fighting’ to eradicate them.”

No deterministic engine could meet that requirement, and saying so was the honest end of a research program. A generative executor meets part of it by construction. It tolerates inconsistency, because inconsistency is the condition it works in rather than the condition that stops it. It does not expose it. Given a self-contradictory specification, a model picks one reading and produces plausible code, leaving the contradiction in the result rather than in front of the engineer. The 2014 requirement asked for both, and for convergence on top. The remaining half is the research problem, and it is the same one as the missing comparison between a declared model and a trace. The technology arrived after the specification was finalized, and the two have not been integrated.

A PSEE failed because of the people it governed: they found a rigid model inconvenient and circumvented it, and their Perceived Process diverged from the Official one. An agent does not circumvent a model. So the fact that PSEEs failed does not mean agent graphs will fail, and I am not claiming they will. What remains useful from that experience is narrower: a record, built over fifteen years of industrial use, of which parts of a process were worth automating and which were not.

Looking forward

None of this is a claim of priority. Whether a result came first in Milan in 1995 or in San Francisco in 2026 makes no difference to anyone building a system today.

What the earlier work gives is a record of where each path ends: which parts of a process yield to automation and which resist it; what becomes of a model when the people it governs find it inconvenient; why every attempt to specify behavior in prose produced the same class of defect; how much detail a model can carry before maintaining it costs more than the work it describes. That record is written down in venues that are indexed and mostly downloadable, and it is still largely unread by the discussion that is now rebuilding its contents.

Reinventing the wheel is expensive. Reinventing it with fewer spokes and then measuring that it rolls badly is a choice.

Sources

• Leon J. Osterweil, “Software Processes are Software Too”, Proceedings of the 9th International Conference on Software Engineering (ICSE 9), Monterey, CA, 30 March – 2 April 1987, pp. 2–13

• S. Bandinelli, A. Fuggetta, L. Lavazza, M. Loi, G. P. Picco, “Modeling and Improving an Industrial Software Process”, IEEE Transactions on Software Engineering, 21(5), May 1995, pp. 440–454

• A. Fuggetta, “Software Process: A Roadmap”, Future of Software Engineering, ICSE 2000, pp. 25–34

• A. Fuggetta, E. Di Nitto, “Software Process”, Proceedings of the on Future of Software Engineering (FOSE 2014), Hyderabad, pp. 1–12

• Robert Balzer, “Tolerating Inconsistency”, Proceedings of the 13th International Conference on Software Engineering (ICSE 13), Austin, TX, 13–17 May 1991, pp. 158–165. The paper is behind a paywall with no open copy; the account of the guards, or “pollution markers”, follows A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, B. Nuseibeh, “Inconsistency Handling in Multi-Perspective Specifications”, IEEE Transactions on Software Engineering, 20(8), 1994

• K. L. Heninger, “Specifying Software Requirements for Complex Systems: New Techniques and Their Application”, IEEE Transactions on Software Engineering, SE-6(1), January 1980, pp. 2–13; and K. L. Heninger, J. W. Kallander, D. L. Parnas, J. E. Shore, Software Requirements for the A-7E Aircraft, NRL Memorandum Report 3876, Naval Research Laboratory, 1978

• David Harel, “Statecharts: A Visual Formalism for Complex Systems”, Science of Computer Programming, 8(3), 1987, pp. 231–274

• Frederick P. Brooks Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, 20(4), April 1987, pp. 10–19, revised from “Essence and Accident in Software Engineering”, Information Processing 86, IFIP Congress, 1986

• Bashar Nuseibeh, Steve Easterbrook, “Requirements Engineering: A Roadmap”, Future of Software Engineering, ICSE 2000, pp. 35–46

• C. A. R. Hoare, “An Axiomatic Basis for Computer Programming”, Communications of the ACM, 12(10), October 1969, pp. 576–580, 583

• A. Mavin, P. Wilkinson, A. Harwood, M. Novak, “Easy Approach to Requirements Syntax (EARS)”, 17th IEEE International Requirements Engineering Conference, 2009

• ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering, which supersedes IEEE 830-1998

• GitHub, Spec Kit, toolkit for spec-driven development

• Kiro, “Requirements-First Workflow”, Kiro documentation: “System behaviors in EARS format (WHEN…THE SYSTEM SHALL…)” https://kiro.dev/docs/specs/feature-specs/requirements-first/

• Peter Steinberger (@steipete), post on X, 18 July 2026, 00:34 UTC

• Josh C. Simmons, “We Are Entering the Graph Engineering Phase”, dated 4 July 2026 — the earliest deliberate use of the label in this sense I have been able to find. On earlier uses of the two words in unrelated senses, see for instance Quantum walks with dynamical control: graph engineering, initial state preparation and state transfer, New Journal of Physics 18, 2016, and Evil Pickles: DoS Attacks Based on Object-Graph Engineering, ECOOP 2017

• Hamel Husain (@HamelHusain), “Loop Engineering Is Dead. Enter Graph Engineering”, X article, 18 July 2026, 04:59 UTC

• Sydney Runkle, Harrison Chase, “3 Years of Graph Engineering with LangGraph”, LangChain blog, 22 July 2026

• LangGraph documentation, Graph API

• Microsoft, Agent Framework — builder and execution

• Google, “Welcome to ADK 2.0”, ADK documentation, section “Agent Execution: BaseAgent to BaseNode” https://adk.dev/2.0/

• Andrew Ng, “The AI Engineering Skills Map”, 14 August 2026

• Alfonso Fuggetta, “Usare l’AI per costruire software o costruire software di AI?”, A bassa voce, 14 August 2026

• Alfonso Fuggetta, “Claude Workflows: Revisiting Process Modeling Languages Three Decades Later”, A bassa voce, 1 June 2026

---

---

---

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

---

---