The Model Wasn't the Breakthrough. The Graph Was.

A few months ago, implementing a new API integration meant opening several editor windows in VS Code and becoming the human API between them. Our architecture is distributed accross multiple repositories, this makes sense. This allows us to follow the single responsability principle.

I would change a FastAPI service in one repository, switch to another repository for shared data contracts, open a configuration interface, inspect an automation path, check the current environment, and then reconstruct how every change depended on the others. The code was distributed for good architectural reasons. The integration graph, however, existed mostly in my head.

The difficult part was rarely typing the code. It was transporting context: which component owned a behavior, what decision had already been made, which interface connected two systems, what had changed since the last attempt, and which test would prove that the user-visible outcome actually worked. Every window switch risked dropping one of those facts. Every handoff required another explanation of the invisible map.

This was not just an individual productivity problem. It was an organizational throughput problem. A capable engineer could still move quickly, but the work depended on that person remembering a large, changing set of relationships. A second engineer, or an AI coding agent, could contribute only after someone rebuilt the same context for them.

My first instinct was to improve the prompts. That helped, but only locally. Better instructions produced better responses inside one conversation. They did not preserve system ownership, coordinate changes across repositories, enforce release boundaries, or verify a complete business outcome.

The more important step was to build a central orchestration repository: a meta-engineering layer above the product repositories, without replacing them. My idea was to have one central place where all my internal thiking process could be easily replicated every time I wanted to create a new feature, fix a bug or find the root cause of an incident.

That decision led me through a progression I now think of as Prompt → Context → Harness → Loop → Graph.

A repository above the repositories

The product repositories remained the authoritative source for implementation. The central layer owned something different: the knowledge required to work across them. It contained a registry of systems and responsibilities, architecture guidance, operating procedures, reusable quality checks, security boundaries, and lessons learned from previous deliveries.

That distinction matters. A central repository can easily become a stale wiki—or, even worse, a competing source of truth. I did not want to duplicate implementation details. I wanted it to answer a different set of questions: Where should an agent begin? Which system boundaries are affected? What evidence is required before moving forward? Where must a human make the decision? And which lessons from the last project should improve the next one?

The first benefit was simple but powerful: one entry point. I could describe the outcome I wanted instead of manually identifying repositories, files, and dependencies. From there, the system could locate the relevant surfaces, retrieve focused context, create an impact map, make repository-scoped changes, run the appropriate checks, and stop whenever it reached a decision or production action that required human judgment.

Using the system over time taught me a great deal—especially what to do and what not to do. With every project, bug, and integration, more of that knowledge found its way back into the repository. Gradually, it became less like documentation and more like an executable operating model—one that was not tied to a particular LLM.

I started sharing the results with my development team and showing them how they could use these capabilities in their own work. Then it clicked for them too. They had experienced the same problems, and some had already built similar automations for themselves. They began contributing their own knowledge, workflows, and lessons to the repository.

That was the turning point. It was no longer just a place for automating the processes I owned. It became the shared entry point for understanding and changing the entire system.

Everyone has a different way of working, so the team connected the repository to the tools and harnesses they preferred—Claude, Codex, Pi, OpenCode, and others. The model became interchangeable. The shared context, processes, quality gates, and decision points became the durable foundation.

It fundamentally changed how we worked as a team.

Today, we use this system as the starting point for almost every change, and it continues to grow with every delivery. Installed as a plugin, it can make an AI agent aware of our architecture, responsibilities, constraints, and operating procedures within seconds. Meanwhile, we remain in control of the decisions that matter.

The repository had become more than a collection of instructions. It had become our graph: a living network connecting architecture, context, tools, workflows, evidence, and human judgment.

Five cumulative layers of AI engineering

How we achieved this can be explain with five layers. Each keeps the capability of the layer before it and expands the unit of control.

Prompt engineering: guide behavior

Prompt engineering asks: How should the model respond?

A good prompt defines intent, boundaries, format, tone, and examples. It can make a single response dramatically more useful. It remains foundational because agents still need clear instructions, especially when the cost of ambiguity is high.

But a prompt usually controls one model call or one bounded interaction. It does not know, by itself, whether the surrounding facts are current. It cannot decide which repository is authoritative or whether a green test represents the real outcome. Prompting improves the worker's instructions; it does not create the work system.

Context engineering: supply the right knowledge

Context engineering asks: What should the model know right now?

That includes current code, architecture boundaries, prior decisions, operating rules, live state, and relevant lessons. The goal is not maximum context. More tokens can add noise, bury constraints, and increase the chance that an old detail is treated as current. The goal is the smallest high-signal context that supports the next decision.

This was the first layer that reduced my window-switching burden. Knowledge that had lived i n my memory became retrievable. An agent could start from the system registry, follow ownership guidance, inspect the current implementation, and distinguish an approved decision from a historical note. Anthropic describes this shift as curating the complete context state available to an agent, not merely refining the wording of an instruction.

Harness engineering: enable safe action

Harness engineering asks: What can the agent safely do?

The harness provides a workspace, file access, command execution, version-control operations, test runners, permission boundaries, and approved interfaces to other systems. This is where a model stops being only a conversational assistant and becomes an agent capable of changing its environment.

The word safely does most of the work. A useful harness does not simply expose every tool. It scopes authority, separates read-only investigation from mutation, protects sensitive values, and makes consequential actions explicit. The agent should be able to inspect broadly enough to reason, change narrowly enough to remain reviewable, and stop before an irreversible step it has not been authorized to take.

Loop engineering: repeat until evidence says stop

Loop engineering asks: How does the agent continue until the result meets an external criterion?

The basic shape is:

plan → act → observe → verify → repair → repeat or stop

The verifier is what separates a useful loop from repeated model confidence. Tests, command results, rendered output, persistent state, or expert review provide evidence outside the model's own reasoning. A stopping condition defines success, escalation, or a safe failure.

OpenAI's practical guide to agents describes patterns such as routing, specialized agents, guardrails, and human intervention. Anthropic similarly distinguishes structured workflows from agents that dynamically direct their own process. In practice, both perspectives point to the same discipline: match autonomy to the predictability and risk of the task.

Graph engineering: coordinate complete outcomes

Graph engineering asks: How do many agents, loops, tools, systems, and humans coordinate toward one end-to-end outcome?

Nodes perform bounded work. Edges encode dependencies and allowed transitions. Shared state carries decisions and evidence. Branches route different conditions. Local loops repair failed nodes. Gates pause for human judgment. Stop conditions prevent unsafe progression.

A graph does not replace prompts, context, harnesses, or loops. It composes them. The model is a worker in the graph; it is not the operating system.

Peter Steinberger popularized this framing in a short 2026 post asking whether the conversation had shifted from loops to graphs. I find the phrase useful because it names a real expansion in scope. It should not be mistaken for a claim that graph-shaped orchestration was formally invented in that moment. Engineers have long modeled workflows, state machines, dependencies, and human approvals as graphs.

Engineering evolution

Capability compounds when the system learns.

1. 01

   Prompt

   Direct the model

   Task leverage
2. 02

   Context

   Supply relevant knowledge

   Better decisions
3. 03

   Harness

   Equip repeatable tools

   Reliable delivery
4. 04

   Loop

   Inspect and improve

   Compounding quality
5. 05

   Graph

   Connect system knowledge

   Operating advantage

What the graph actually contains

Calling something a graph can make it sound more abstract than it really is. In our engineering system, I see seven practical graphs layered together. Six describe how the system operates. The seventh—which I will return to shortly—is what allows the entire system to grow.

The system graph shows how components, repositories, and external capabilities relate to one another. The execution graph defines which delivery stage comes next, what can proceed automatically, and what is blocked. The context graph points to the current sources for code, architecture, decisions, and external specifications. The state graph preserves plans, branches, review status, and evidence across sessions. The governance graph places permissions, approvals, rollback requirements, and production boundaries on the relevant transitions. Finally, the learning graph turns discoveries from previous work into guidance and quality checks for future deliveries.

These graphs do not need to exist inside a single visual graph database. Some relationships are encoded in a registry, others in version control, test dependencies, skills, or orchestration tools. What matters is that those relationships are explicit, retrievable, and connected to action.

That final point is especially important for leaders. Documentation creates value when it changes a decision. A graph creates operating leverage when new information can change routing, validation, or authority.

For example, if one integration teaches us that a single credential can provide access to several selectable sites, the next implementation should automatically include an explicit selection step and a test for it. If an external system can return an ambiguous result after a write, the graph should prohibit a blind retry and route the process towards reconciliation instead. A lesson is only truly captured when it changes what the system does next.

The seventh—and perhaps most important—graph is the communication graph.

An automated system cannot evolve across an organisation unless the people using it understand it, trust it, and contribute their own knowledge to it. The technology matters, but adoption determines whether it creates lasting value. If a development team does not build and improve the system together, individual automations simply become new silos, creating more fragmentation and inefficiency.

The communication graph connects the people behind the system: who shares discoveries, who contributes new workflows, who challenges assumptions, and who carries lessons from one project into the next. It is what turns a powerful individual tool into a shared engineering capability.

Features became end-to-end outcomes

Before the orchestration layer, a cross-system feature was often planned as a list of code changes. The list might be correct and still miss the customer journey. A backend endpoint could work while configuration failed. A workflow could turn green while the final state never persisted. A notification could be delivered even though the underlying business action did not happen.

The graph changed the unit of planning from “files changed” to “outcome proven.” A typical integration path now moves through research, contract definition, backend behavior, configuration, data normalization, user-facing setup, transactional behavior, downstream event handling, deployment preparation, human end-to-end validation, monitoring, and any external certification or pilot gate.

Each stage has an owner, inputs, outputs, evidence requirements, and a stop condition. The next stage does not inherit confidence merely because the previous one returned a success code.

Several lessons show why this matters. One integration revealed that a credential could expose multiple organizational units, so setup needed explicit selection rather than assuming a one-to-one relationship. Another exposed a gap between catalog data and values that were actually available at transaction time. A third required signed requests and strict separation between safe validation and real mutations. A more complex write path revealed several transaction contexts and the danger of retrying when the first response was inconclusive.

None of those discoveries was valuable because an agent generated a large amount of code. The value came from converting each discovery into durable system behavior: a typed contract, a required question, a test fixture, a review gate, or a stop condition. The next feature began with less uncertainty because the previous one had changed the graph.

This is also where the central repository earned its keep. It did not absorb the implementation. It connected the stages, routed each change to the right owner, and made the cross-boundary definition of done visible.

Debugging became a graph traversal

The same model improved root-cause analysis.

I start with what the customer experienced and trace the issue backwards through the system. At each step, I check what went in, what came out, which version was running, which component was responsible, and what evidence shows whether it worked. I then compare the failing flow with one that worked correctly and test one clear hypothesis at a time.

This sounds obvious, but operational pressure encourages shortcuts. A request returned 200, so the service must be fine. An automation run is green, so the workflow must have completed. A message was delivered, so the incident must be resolved. Each fact is useful; none proves the full outcome.

Graph thinking keeps the investigation focused on system boundaries and on what changes at each step. It also makes parallel analysis safer. For example, two different AI harnesses, such as Claude and Codex, can independently review the same evidence without seeing each other’s conclusions. If both reach the same result, our confidence increases. If they disagree, that disagreement becomes useful evidence. We then run a specific check to determine which conclusion is correct, instead of letting two confident AI-generated explanations compete with each other.

The human gate remains decisive. Resolution means the real user outcome works again, the cause is understood well enough to prevent recurrence, and any remediation has been checked at the consequential boundary—not merely that one node looks healthy.

Human quality gates are part of the design

I describe the system as AI-operated, human-governed.

Agents can retrieve context, produce impact maps, propose plans, implement bounded changes, run tests, inspect output, compare paths, prepare review material, and collect evidence. Humans retain authority over product intent, architectural trade-offs, irreversible production actions, risk acceptance, external commitments, and the definition of a successful business outcome.

For consequential changes, I also want a deliberate double check. That can be an independent agent review, a second test path, a comparison with a known-good implementation, or a human walking the rendered flow. The form varies; the principle does not. The system should not ask the same model to grade its own answer using only the reasoning that produced it.

Quality gates are not a tax placed after automation. They are nodes in the graph. A privacy review belongs before public output. A rollback decision belongs before authority changes. A real mutation belongs after read-only validation. A customer-visible outcome belongs after internal checks, not as an assumption derived from them.

What changed in delivery time—and what did not

Across observed integration examples, work that had commonly been estimated as a weeks-sized engineering unit moved into roughly 2.5 to 4 active engineering days for the concentrated technical implementation.

That is an observation from specific deliveries, not a universal promise. It does not mean every integration was commercially live in four days. External responses, access, certification, security review, controlled pilots, and rollout decisions continued on their own timelines. The graph compressed the work we controlled: context reconstruction, impact analysis, implementation, cross-boundary verification, review preparation, and reuse of previous lessons.

The distinction matters because optimistic AI claims often collapse implementation time and elapsed delivery time into one number. CTOs should measure both. Active engineering time reveals internal leverage. Calendar time reveals the full system, including external dependencies and governance. Improving one does not make the other disappear.

The more durable gain was not speed on a single project. It was a lower cost of starting the next project. Estimates became better because the stages and unknowns were visible. Reviews became more focused because evidence traveled with the change. Engineers spent less time rediscovering ownership and more time improving the difficult boundary.

From personal leverage to organizational memory

The largest shift was reducing how often the organization had to rediscover itself.

Previously, a lesson could remain in a developer's memory, an old conversation, or a review thread. Now it can become a reusable rule: a required check, a typed interface, a test, a stop condition, or a new branch in the delivery graph. Each completed feature can reduce the uncertainty of the next one. Each incident can improve the investigation system. Each human correction can become a durable quality gate instead of feedback that must be repeated manually.

This is what an AI-native company means to me. It is not a company without people, and it is not a company in which every process is autonomous. It is a company whose operating knowledge is sufficiently digital, current, accessible, and governed that agents can execute meaningful parts of the work safely while people remain accountable for consequential decisions.

The next step is to make the graph more observable. I want clearer measures of where work waits, which context is repeatedly missing, which gates catch real problems, and which lessons genuinely shorten later delivery. I also want better provenance: an important decision should be traceable to the evidence and human authority behind it.

There are hard limits. Context becomes stale. Tests can encode the wrong assumption. Tools can fail. Agents can produce plausible but incorrect explanations. A graph can automate a bad process just as effectively as a good one. External systems remain unpredictable, and some ambiguity cannot be resolved without domain judgment. Governance therefore has to evolve with capability, not follow it months later.

The graph is the compounding advantage

Powerful models are increasingly available to everyone. Access to a strong model is valuable, but it is a weak long-term differentiator on its own.

The compounding advantage is the system around the model: relevant proprietary context, well-designed tools, explicit workflows, accumulated decisions, external verification, permissions, and human judgment placed at the right edges. Model quality determines how much intelligence is available at a node. Graph design determines whether that intelligence becomes reliable organizational output.

We began by trying to remove the friction of switching between editor windows. We ended up encoding how engineering work is routed, checked, learned from, and governed.

The model was not the breakthrough. The graph was.

Sources

1. OpenAI, “A practical guide to building AI agents” — tools, orchestration, guardrails, and human intervention.
2. OpenAI, “Building an AI-native engineering team” — agent-supported engineering with strategic ownership remaining human-led.
3. Anthropic, “Effective context engineering for AI agents” — curating the context state available to long-running agents.
4. Anthropic, “Building effective agents” — workflow, routing, parallelization, and evaluator-optimizer patterns.
5. Peter Steinberger, graph-engineering framing — the post that popularized the shift in discussion from loops toward graphs.