Every few months since early 2025, the work of getting a language model to do something useful has been renamed. Prompt engineering became context engineering. Context engineering picked up harness engineering. By June 2026 people were writing about loop engineering, and a month after that graph engineering arrived on X with three competing definitions inside 48 hours, one of them a joke about the pace of the renaming.
Some of that is churn. But the order isn't arbitrary. Read the five terms in the sequence they appeared and they trace one line: the scope of state the model is trusted to own keeps expanding outward by one layer at a time. Each new term names the layer that broke when the previous one got good enough to ship.
That line has an endpoint, and it isn't a sixth word. It's the systems the agent touches.
Why this matters more than the words do
Read the five terms as a map of where state lives, and the progression is legible:
| Term | The question it answers | What owns the state |
|---|---|---|
| Prompt engineering | What do I say to the model? | The request |
| Context engineering | What does the model get to see? | Retrieval and memory |
| Harness engineering | What can the agent do, and when does it stop? | The execution environment |
| Loop engineering | What keeps it going without a human? | The exit condition |
| Graph engineering | How do multiple agents branch and share state? | Persistent shared state |
Each row hands more durable state to the machine than the row above it. A prompt owns state for one request. A graph owns state across sessions and across agents, surviving retries that take different paths.
But the state doesn't actually live in any of those layers. It lives in your CRM, your billing system, your HRIS, your warehouse. What a graph calls shared state is a cache of decisions about records that belong to systems you already run. Every term on the treadmill is a more sophisticated way of describing how software reaches into those systems and changes them.
Five terms in two years for the model side. Zero new terms for the systems the model is reaching into.
The layer nobody renamed
Watch what happened to the category while the vocabulary moved. Almost every integration vendor that called itself an iPaaS in 2024 now describes itself as AI orchestration, an agent platform, or an enterprise agent surface. The positioning moved on the same treadmill the vocabulary did.
The substrate underneath mostly did not. The recipe engine is still the recipe engine. Version control in much of the category remains a JSON snapshot exported to a repository, and observability is commonly gated to the tier above the one you bought.
That gap isn't anyone's mistake. These platforms were built for a caller that behaved like a person: one paced request, a human reading the result, a human deciding what happens next. The assumption held for a decade. An agent breaks it, and renaming the product doesn't reach the assumption, because the assumption sits in the substrate rather than the label.
So the treadmill lands somewhere specific. Prompt, context, harness, loop, and graph engineering all resolve into questions about a tool call: which tool, called by whom, with what authority, against which version of the contract, and with what evidence afterward.
Every layer of agent scaffolding terminates in a tool call against a system of record, and that call is governed by your integration layer or it is governed by nothing.
What each layer actually asks of your integration platform
Read the treadmill as a demand list rather than a glossary and it gets concrete. Each term asks the layer beneath it for something specific and testable.
Context engineering needs tool output you can trust. The window fills with retrieved records and tool results, and if a connector quietly returns a stale record or a partial page, the model reasons correctly over wrong inputs. You then spend a week debugging the prompt. In Koodisi, retrieval and tool steps are Activities inside a versioned workflow, and the Mapping Engine holds the transform explicitly instead of leaving it implicit in whatever the connector happened to hand back.
A harness decides which tools the agent may call, and that decision is worth exactly what the enforcement behind it is worth. Koodisi evaluates RBAC on every artifact and verb, with attribute tags feeding ABAC policy at runtime. The agent doesn't hold a tool because someone pasted a token into a config file. It holds that tool because policy resolved in its favor on that call, for that tenant, at that moment.
Loops raise a different demand, and a commercial one. A loop without a hard stop is a resource sink, and on a metered platform the runaway loop is also the billable one. Koodisi is licensed as one flat enterprise plan rather than by execution volume, which turns a retry storm at 2 AM into an operational problem to fix rather than an invoice to explain. No per-execution billing. No overage invoices. Your bill doesn't move when your traffic does.
Graphs need durable state and contracts that hold still. Agents branching across sessions need state that survives them, and they need the tool contract not to shift underneath a run in progress. Koodisi's Git-Enabled application archetype keeps your integrations as real files in your repository. You branch and tag inside the platform and raise pull requests through your existing GitHub or GitLab flow. An agent reads a schema at runtime and never reads a changelog, so the version it bound to stays pinned while the new one lands beside it.
All four rest on evidence. Koodisi emits OpenTelemetry metrics, traces, and logs out of the box, with distributed traces spanning each Activity and export to Datadog, Honeycomb, Grafana Cloud, New Relic, Elastic, or Splunk. Immutable audit logs stream to your OTLP collector or SIEM. When someone asks which agent changed that record and on whose authority, the answer is a trace and an audit row rather than a reconstruction.
The scaffolding layer changes names every quarter; the demands it makes on the systems underneath have been stable the whole time.
The governed tool surface, specifically
The piece most teams end up building by hand is worth naming directly, because it's where the five terms converge.
Koodisi's AI skills are reusable, governed capabilities defined at the organization layer. Extractors and classifiers and generators, each carrying declarative constraints: a model allowlist, PII handling rules, output validation contracts. You define the capability once with its constraints attached, and the agent consumes it as a tool. The constraint travels with the capability rather than living in a prompt anyone can edit.
Around that sit the Activity library and the custom connector SDK, so a tool an agent calls is a versioned, org-scoped, access-controlled artifact instead of an endpoint someone wired up on a Thursday. Profiles bind runtime configuration to tenants, clients, and deployments. Variables resolve at the application, deployment, and client levels, so one tool definition behaves correctly in Dev, UAT, and Prod without forking. Tenant isolation and multi-tenancy are built in.
The platform's own agent modes work the same way. Ask, Design, Build, Review, and Support operate across the platform surface, drafting activities, mappings, schemas, and connections. The platform drafts and reviews. Engineers approve.
A tool an agent can call needs a version, an owner, a policy, and a trace: the same things you already demand of production code.
The honest part
None of this makes the vocabulary useless, and the model-side work isn't a distraction. A badly written prompt inside a well-governed graph still returns a bad answer. Exit-condition design is hard in a way no platform solves for you. The people naming these layers are naming real problems.
Not every agent needs the apparatus either. An internal assistant summarizing documents nobody acts on can live in a notebook. The demands here start applying when an agent's tool calls change records that other systems, auditors, or customers depend on. That threshold arrives sooner than most roadmaps assume, but it isn't day one.
Where to start
Take one agent you plan to give write access to a system of record. Answer four questions about it: which tools it can call, what stops the loop, which version of each tool contract it's bound to, and where the trace goes when it fails at 2 AM. If any of those answers is a person's name or a config file, the scaffolding isn't finished.
Start with one agent tool. Wire it through Koodisi as a governed Activity, then pull the trace and the audit row for a single call. Koodisi is one enterprise plan with a flat license and no per-execution billing, so that first tool and the hundredth cost the same to run. Talk to us to try it against your own systems.
A sixth term will arrive. The questions it raises will still be answered at the tool call: which systems the model may touch, and what you can prove afterward.