An enterprise cannot govern what it cannot name with reasonable precision. If agent means a chat assistant in procurement, a model endpoint in an architecture diagram, a service account in IAM, and an autonomous employee in a board presentation, the disagreement is no longer merely semantic. It changes what gets bought, which risks are accepted, who receives access, what evidence is retained, and who is accountable when the system does something expensive.
This is why I treat an agentic-engineering taxonomy as part of the platform contract. Not glossary decoration. The vocabulary has to survive the journey from an individual experiment, through a team workflow, into enterprise identity, CI/CD, risk, audit, and production operations.
There is no settled industry vocabulary to import wholesale. The OECD’s 2026 paper on the agentic AI landscape describes definitions as unsettled while identifying recurring dimensions such as goal-directed behavior, autonomy, environment interaction, tool use, adaptation, coordination, sustained operation, and human oversight. It is preliminary analytical work, and its multi-agent emphasis is not universal. Still, it makes one thing fairly obvious: selecting a vendor diagram and calling it the enterprise ontology would be premature.
So this article introduces version 0.1 of the demming.dev working taxonomy. The definitions below are either explicitly site-specific or qualified where a term remains disputed. This is not an international standard, a legal classification, or a claim that everyone else uses the words incorrectly. It is a practical language for comparing architectures and operating decisions. The structured reference surface will start at version 0.1.0 and carry stable term IDs, aliases, source notes, revisions, and deprecations as the taxonomy evolves.
Scope before vocabulary
The first taxonomy mistake is making agent the only unit of analysis.
ISO/IEC 22989:2022 provides concepts and terminology for artificial intelligence. The EU AI Act separately distinguishes general-purpose AI models, AI systems, and organizational roles such as providers and deployers. Those sources have different purposes—the latter is EU law, and neither supplies my agent definition—but both support a useful enterprise habit: keep the technical component, assembled system, application, and accountable organization distinct.
A model can remain unchanged while its authority changes radically. Put it behind a read-only research interface and the likely consequences are one thing. Give a model-based component a branch-writing identity, CI access, a deployment tool, customer data, and an approval path, and the operational object is quite different. Model capability is only one coordinate.
An enterprise inventory therefore needs to say:
- which model and runtime are used;
- which objective and instructions bound the work;
- which tools, systems, and data are reachable;
- how state is retained and recalled;
- which identity, permissions, and approvals apply;
- which harness scopes and functions constrain execution;
- which evaluations and delivery gates produce evidence; and
- which human owns acceptance, interruption, and consequences.
That list is a house prescription, not a universal inventory schema. Its value is prosaic: a permission, tool, or rollout change becomes visible even when the model name did not change.
Eighteen load-bearing terms
The full reference needs more than eighteen terms. This article does not. These are the load-bearing boundaries for the first version, grouped by the job they perform. Site working means a demming.dev definition, not a quoted standard. Disputed means that common ecosystems use the label at materially different scopes.
Execution components
| Term | Working definition here | Boundary that matters | Status |
|---|---|---|---|
| Model | A trained computational component that produces outputs from inputs according to learned and configured behavior. | Capability is not tooling, organizational authority, or an application outcome. | Site working |
| Model runtime | The execution layer that invokes a model and manages model-facing configuration, requests, responses, and provider integration. | Routing or runtime configuration can change the system without retraining the model. | Site working |
| Agent | A model-based execution component that pursues a bounded objective through instructions and context, tools, state, and an execution boundary, under defined authority and evidence rules. | This deliberately includes operational concerns that lightweight SDK definitions may omit. | Disputed; site working definition |
| Tool | A callable capability through which model-directed execution can read, compute, communicate, or change state outside immediate inference. | Tool availability does not grant permission or make the result trustworthy. | Site working |
| Skill | A reusable package of task guidance that may bundle instructions with scripts, references, or assets. | A skill shapes work; it is neither an IAM grant nor necessarily an external callable tool. | Disputed; one narrower package meaning is specified by Agent Skills |
| Orchestration | Coordination of steps, routing, retries, handoffs, concurrency, and termination across model-based components and deterministic services. | Coordination may be deterministic, model-directed, or mixed. Calling all of it intelligence hides failure boundaries. | Site working |
Three adjacent terms matter here. A workflow is the declared progression of states, activities, decisions, and transitions toward an outcome. Orchestration is what coordinates an execution of that workflow; an orchestrator is the component performing that coordination. And memory is a mechanism that persists, selects, or reconstructs prior information for a later model step. It is not a flattering name for everything the system happens to retain, and it is not the model’s weights.
The Agent Skills specification gives
skill one concrete package shape: a directory containing instructions and
optional scripts, references, and assets. Its optional, experimental
allowed-tools field can name tools a compatible client treats as pre-approved.
That is a package-and-client convention. It does not confer IAM permission on
the underlying system.
Likewise, the OpenAI Agents SDK combines agents expressed through instructions and tools with handoffs, guardrails, sessions, and tracing. Useful implementation vocabulary, yes. A universal ontology, no.
These six rows are descriptive. An organization can identify every component correctly and still operate it recklessly. Prompt engineering remains an important input-design discipline, but once execution gains tools, state, delivery access, and authority, prompt quality is nowhere near a sufficient control model.
Control and evidence artifacts
| Term | Working definition here | Failure exposed by keeping it separate | Status |
|---|---|---|---|
| Prompt | Invocation-scoped input that requests or conditions an output for a particular interaction. | A clear request can still rely on stale context, unsafe tools, or the wrong objective. | Site working |
| Instructions | Behavioral directives applied to a model-based component across a declared scope. | Instructions can be followed faithfully while the intended outcome is wrong; precedence and scope have to be knowable. | Site working |
| Context | Information assembled for a current inference request or bounded model step, including source material, architecture, examples, history, retrieved knowledge, and relevant runtime state. | Presence does not prove currency, completeness, relevance, or authority. Memory remains a separate mechanism. | Disputed; site working definition |
| Specification | A systematic, reviewable description of a named subject’s required, proposed, or implemented properties, qualified by purpose, scope, authority, abstraction, lifecycle status, representation, and evidence relation. | A long prompt may contain specification material without establishing what is authoritative or how conformance will be assessed. | Site working |
| Policy | A rule governing what is allowed, forbidden, required, or subject to approval for a defined actor and situation. | Persuasive prose is not enforcement; deterministic enforcement cannot resolve every judgment either. | Site working |
| Evidence | A retained observation or artifact used to assess execution, conformance, or outcome: a diff, test result, review finding, provenance record, or rollout signal. | A confident model explanation is still a claim unless an independent process makes it probative. | Site working |
These artifacts can live in one repository, even in one file. Their semantic jobs remain different. A prompt changes per invocation. Durable instructions should change less often. Context is selected for an inference. A specification belongs to an outcome or system. Policy belongs to an authority boundary. Evidence is produced while the work is performed and checked.
Conflating them creates very ordinary bugs. Repository instructions become acceptance criteria. Retrieved documentation becomes current policy. A test generated alongside an implementation is treated as independent verification. Or a trace is retained and everyone quietly assumes the trace proves correctness.
It does not.
Platform capabilities
| Term | Working definition here | Enterprise consequence | Status |
|---|---|---|---|
| Evaluation | A defined procedure that assesses a model, component, or system against criteria and produces interpretable results. | The subject, scenario or dataset, metric, threshold, and decision use must be stated. A score alone is not governable. | Site working |
| Guardrail | A pre-execution, in-execution, or post-execution control that constrains, checks, interrupts, or routes behavior. | It is one control, not a safety guarantee. Coverage and implementation differ. | Disputed; vendor-documented variants |
| Authority profile | The combined record of identity, permissions, reachable systems, data access, approval rights, interruption paths, and expected blast radius for an execution context. | Capability and authority change independently. Risk review has to inspect both. | Site working |
| Trace | An ordered technical record of model, tool, handoff, or control activity during execution. | It supports diagnosis and attribution; it neither proves correctness nor stops sensitive inputs being recorded. | Site working |
| Harness | The surrounding operational structure joining model-based execution to tools, context, controls, workflow, and evidence at an explicitly named scope. | A repository wrapper and an enterprise control plane are not interchangeable. Always name the layer. | Disputed; site layered definition |
| AI platform | A shared product and control surface integrating governed AI and SDLC capabilities for human and model-based actors across a lifecycle. | Model endpoints alone do not provide identity, evidence, promotion, recovery, or accountable service ownership. | Site working |
I use IAM conventionally for the systems and practices that establish identity and govern permissions to resources under stated conditions. The authority profile is the operational view for one execution context: not just what a principal can technically call, but which data, approvals, interruption paths, and likely blast radius travel with it. The identity of a model-based actor should not be borrowed invisibly from a human’s interactive session.
I use control plane more narrowly than platform: the capabilities that register actors and resources, distribute or enforce policy, authorize actions, collect control evidence, and reconcile desired with observed state. It is borrowed systems language, so the governed resources and actions must be named. An AI platform includes a control plane, but also the product surfaces and delivery capabilities through which people and model-based actors do useful work.
Tracing illustrates the difference between a capability and assurance. The OpenAI Agents SDK tracing documentation describes traces and spans for model generations, tool calls, handoffs, and guardrails, together with controls for sensitive data. That can help answer what happened. It cannot decide whether the outcome was correct, permitted, or safe.
Protocols stop at a boundary too. The Model Context Protocol defines client-server roles and capability negotiation for exposing context and tools. Its authorization specification adds an optional HTTP authorization flow and leaves resource-owner access policy with the server. Protocol conformance does not grant a particular actor permission to use a tool, validate its output, or make the task safe. Those are system and platform responsibilities.
Harness has a scope and a function
People now use harness for almost anything surrounding a model: an SDK loop, a coding CLI, repository instructions, a team’s delivery workflow, or an enterprise platform. Arguing over the one true meaning is not useful. Leaving the scope implicit is worse.
Version 0.1 therefore defines five organizational scopes. They are responsibility boundaries, not ranks on a maturity ladder. A production system will often contain all five, nested and owned by different parties.
| Harness scope | Primary responsibility | What it cannot establish alone |
|---|---|---|
| Agent runtime | Model invocation, output handling, tool-call plumbing, session mechanics, retries, and local controls for one execution loop. | Repository intent, enterprise IAM, or production approval. |
| Vendor coding environment | Workspace interaction, task loop, built-in tools, and product-specific permissions and telemetry in an editor, CLI, sandbox, or coding-agent product. | Organization-wide source truth, cross-vendor policy, or release authority. |
| Repository | Instructions, specifications, commands, invariants, changed-file boundaries, tests, and issue or pull-request evidence for one governed repository. | Cross-repository system truth or enterprise-wide controls. |
| Team | Shared work taxonomy, review roles, risk classes, metrics, escalation, onboarding, and exception handling across delivery practices. | Enterprise identity federation or common production policy. |
| Enterprise platform | Identity, IAM, data boundaries, policy, audit, CI/CD integration, environment promotion, observability, interruption, and recovery across organizational systems. | Business intent, ethical judgment, or accountability merely by existing. |
Scope is only one axis. Function is the other:
- model-directed execution invokes a model, processes its output, and mediates a bounded sequence of model-directed tool or control steps;
- a workflow or behavior layer supplies reusable procedures, roles, state transitions, and artifacts;
- orchestration coordinates components, dependencies, routing, and termination;
- an evaluation harness runs defined assessments and retains results; and
- a harness optimizer proposes or applies changes to another harness’s configuration or artifacts.
These functions are orthogonal to scope. A repository harness may contain a workflow layer and evaluation harness. An enterprise platform may orchestrate several runtimes. An optimizer is not automatically entitled to change the harness it evaluates. Scope answers where is responsibility held? Function answers what job is being done?
That distinction also improves portability. A skill may move between coding environments. Repository invariants usually should not. Enterprise policy certainly should not arrive as an unreviewed task package.
Three operating contexts, not a ladder of intelligence
| Context | Useful capability | Missing claim |
|---|---|---|
| Individual experimentation | A person explores prompts, tools, and local workflows in a disposable boundary. | Local success does not prove repeatability, shared controls, or a right to touch production state. |
| Team-standardized engineering | Repository and team harnesses establish specifications, shared skills, CI, review roles, risk classes, and comparable evidence. | Repeatable team practice is not yet an enterprise control system. |
| Enterprise-governed operation | Registered components and systems operate under explicit identity, authority, data policy, evaluations, audit, promotion, interruption, and recovery controls. | Governance does not make a weak use case valuable or transfer accountability away from people. |
More autonomy is not automatically more capability or maturity. It may only mean fewer enforced checks. A multi-agent system is not above a single agent by definition either. Additional components may improve decomposition or specialization, but they also add coordination, state, observability, cost, and new failure modes. The architecture should earn that complexity.
The established disciplines still own their questions
Agentic engineering is not a replacement discipline into which everything else disappears. It coordinates several existing disciplines around a faster and partly model-directed execution loop. This crosswalk is mine; it is not a normative mapping supplied by the cited standards.
| Established discipline | Terms it sharpens | Question it stops us skipping |
|---|---|---|
| Prompt and interaction engineering | Prompt, instructions, context, skill | What information and behavior does this invocation need, and how are conflicts resolved? |
| Requirements engineering | Specification, acceptance criteria, evidence | Which need and outcome are being pursued, under which constraints, and what counts as acceptable? |
| Systems engineering and architecture | Agent, workflow, orchestration, harness | What is the system boundary, how do components interact, and where can a locally plausible action create a system failure? |
| Testing, verification, and AI evaluation | Evaluation, guardrail, evidence, trace | Which property is actually checked, by what method, and what decision may the result support? |
| Security and IAM | Policy, authority profile, tool, blast radius | Which actor may cause which effect on which resource, and how is privilege limited and revoked? |
| Platform engineering, SRE, and delivery | Harness, AI platform, evidence, trace | How does the capability become repeatable, observable, promotable, supportable, and reversible? |
Requirements and lifecycle standards matter because useful structure already exists. The public scope for ISO/IEC/IEEE 29148:2018 covers requirements-engineering processes and their information items; ISO/IEC/IEEE 15288:2023 establishes a common system-lifecycle process framework. NIST’s Secure Software Development Framework is outcome-based guidance intended to be integrated into an SDLC. Those are bounded observations from the official catalog records and publication. None of them defines this taxonomy. They do show why reducing production agentic engineering to prompt craft throws away quite a lot of useful engineering.
The crosswalk also sets the follow-up boundary. I am not going to smuggle a complete requirements lexicon, documentation taxonomy, systems-analysis method, or evaluation handbook into this inception article. Those deserve their own references. This map says where they attach so we do not invent a second, incompatible language for the agentic platform.
Make the taxonomy operate
A taxonomy becomes useful when it changes a decision. At minimum, an enterprise agent or agent-system record should be able to point to:
inventory unit and accountable owner
model and runtime versions
bounded objective and specification
instructions, context sources, and memory policy
tools and reachable systems
identity and authority profile
harness scopes, functions, and control owners
evaluations, deterministic gates, and retained evidence
interruption, escalation, promotion, and recovery pathsThat record should describe a deployed configuration, not a marketing name. Two versions should be comparable. If a new tool, data source, permission, or approval right changes the authority boundary, the change should be visible even when the model does not.
My operating assumption is that stable terms and identifiers reduce translation work between teams, suppliers, repositories, risk reviews, and audit records. That is an economic argument for standardization, not an argument for one runtime. The existing AI-maturity series names the larger organizational property safe delegation capacity. This taxonomy supplies some of the nouns needed to discuss that capacity without redefining its readiness model.
There will be disagreement. Good. The reference should expose it at the boundary where it matters. If one team calls a prompt template a skill and another reserves skill for a package with scripts, record both senses and require a qualifier. If a supplier calls a model endpoint an agent, inventory it as a model-based component until tools, state, execution boundary, and authority are actually present.
The immediate test is simple. When someone proposes “deploying an agent”, ask which inventory unit is changing, which harness scopes and functions own it, what authority profile it receives, which evidence gates that authority, and who can stop it. Record the answers before the proposal reaches IAM or production review. If the inventory has nowhere to put them, that gap—not a new agent demo—is the next platform decision.