flowchart TB A[Human goal and operating context] B[Product and business process] C[Workflow, orchestration, multi-agent coordination] D[Agent loop and runtime] E[Tools, permissions, action environment] F[Context, retrieval, memory, state] G[Inference service and model API] H[Model artifact] I[Data, training, post-training, evaluation] J[Compute, storage, network, power] J --> I --> H --> G --> F --> E --> D --> C --> B --> A R1[Security and identity] -. crosses .- G R1 -. crosses .- E R1 -. crosses .- C R2[Evaluation and observability] -. crosses .- H R2 -. crosses .- D R2 -. crosses .- B R3[Reliability and cost] -. crosses .- G R3 -. crosses .- C R4[Human control and governance] -. crosses .- D R4 -. crosses .- A
Understanding AI
How a trained model becomes a useful product, an agent, and eventually a governed system.
Executive summary
The most useful fact in AI engineering is also the easiest to lose: the model is not the system. A model is a learned computational artifact. It becomes usable when an inference engine runs it; situated when an application constructs context around it; informed when retrieval brings in external knowledge; capable of action when a runtime exposes controlled tools; agentic when the model can repeatedly choose what to do next; and operational only when the surrounding system can survive failures, enforce authority, produce evidence, involve humans, and remain governable over time.
The original “model → agent” ladder is therefore necessary but incomplete. It is better represented as a technical spine crossed by production rails. The spine runs from compute and data through training, model artifact, serving, context, tools, agent, orchestration, and product. The rails—identity, security, memory/state, evaluation, observability, reliability, human control, and governance—cross several or all stages. They do not appear only after the agent is built.
“Above the agent” is not another kind of smarter model. It is a widening control scope: a workflow or orchestrator coordinates tasks; durable execution preserves progress through time and failure; a platform governs shared models, tools, memory, identities, and budgets; a product embeds the capability in a human process; and an organization assigns ownership, risk, audit, incident response, and accountability. At each step, the engineering problem becomes less about generating the next token and more about controlling state, authority, coordination, and consequence.
Tip
The recommendation, in one line. Name the boundary before discussing “the AI”: model, model call, workflow, agent, multi-agent system, product, platform, or governed organizational capability.
Headline numbers
Technical spine
10
stages from compute substrate to human-facing product and process
Human-AI activities
16
domain-independent activities in the NIST AI Use Taxonomy
Agentic security risks
10
top-level categories in OWASP's 2026 agentic taxonomy
Risk functions
4
Govern, Map, Measure, Manage in NIST AI RMF 1.0
Methodology
This report started from a supplied model-to-agent study note, then widened it against external taxonomies so the surrounding system would not disappear behind the model. The primary anchors were ISO/IEC 23053 for generic ML-system components, ISO/IEC 5338 for lifecycle processes, the OECD classification framework and NIST AI RMF for applied-system dimensions and actors, NIST AI 200-1 for human-AI activities, NIST’s agent-tool taxonomy, and the OWASP Agentic Top 10 for 2026.
The map was then rotated by technical layer, lifecycle, source of control, failure mode, actor/counterparty, and deployment form. The result is deliberately scoped to modern LLM-centric application systems. Non-LLM AI, robotics, formal methods, semiconductor production, and jurisdiction-specific law remain visible on the niche and residual shelves but do not receive equal depth.
Note
Scope discipline. This is a total map of the LLM-centric application system, not a claim to contain every branch of artificial intelligence as a scientific field.
The whole system in one picture
The stack has a spine and rails. The spine answers “what is assembled on top of what?” The rails answer “what must remain true across the assembly?”
The arrows do not mean every product owns every lower layer. A developer using a hosted model API consumes the lower layers as a service. The responsibility does not disappear; it is split across providers, integrators, deployers, operators, users, and affected parties.
1. The boundary glossary
Many AI arguments are vocabulary collisions. The following terms are related, but not interchangeable.
| Term | What it is | What it is not |
|---|---|---|
| Algorithm / architecture | The structure of a computation or learning method | The learned numerical state produced by training |
| Weights / parameters | Learned numbers controlling the model’s computation | A searchable database of exact training facts |
| Checkpoint | Saved training state at a particular moment | Necessarily the complete deployable package |
| Model artifact | Architecture/configuration, weights, tokenizer, precision, templates, metadata | A complete end-user product |
| Inference | Running a trained model on input to produce output | Training, retrieval, tool execution, or workflow control |
| Model service/API | Managed access to inference over a software interface | The model itself or raw infrastructure |
| Context | Information visible to the model for the current call | Persistent memory or guaranteed attention |
| External knowledge | Documents, databases, APIs, websites, or other sources outside weights | Automatically available to the model |
| RAG | A pipeline that retrieves and places selected external knowledge into context | A synonym for vector database |
| Memory | Stored state that can later be selected and returned to context or control flow | The context window itself |
| Tool | A typed interface to observe or affect an environment | Permission to do anything the interface could theoretically do |
| Harness/runtime | Code that constructs calls, exposes tools, applies policy, executes actions, and manages state | Learned intelligence |
| Workflow | Code-defined control flow through model calls, tools, and steps | Necessarily an autonomous agent |
| Agent | A system in which the model can repeatedly direct parts of its process and tool use toward a goal | Merely a chatbot, a memory store, or one tool call |
| Orchestrator | A coordinator that decomposes, dispatches, joins, budgets, and terminates work | Necessarily a model; it can be deterministic code |
| Multi-agent system | Multiple agent processes with coordination and communication | Automatically more capable, reliable, or correct |
| Product | User experience, application logic, data, operations, policy, and business process containing AI capability | The model name shown in marketing |
| AI management system | Organizational policies, roles, processes, measurement, and improvement for responsible AI use | A runtime framework or agent library |
Important
A language instruction is not a security control. The model may decide what it wants to do; code outside the model must decide what is actually allowed and execute it within a defined boundary.
2. Below the model: the intelligence factory
2.1 Compute is the physical floor
A model exists as a deployable capability only because a substrate can store and execute it. That substrate includes accelerators, CPUs, host memory, high-bandwidth accelerator memory, storage, network/interconnect, cluster scheduling, power, and cooling. At small scale it may be one laptop or one GPU. At large scale it becomes a distributed system with data, tensor, pipeline, and expert parallelism; checkpoint distribution; failure recovery; and capacity planning.
The lower layer matters twice:
- Training needs enough compute, communication, storage throughput, and power to optimize the model.
- Inference needs enough memory capacity, bandwidth, concurrency, and scheduling efficiency to meet latency and throughput targets.
ISO’s public AI overview frames the foundation as a triad of data, compute infrastructure, and algorithms. Removing any corner changes what can be trained and served.
2.2 Data is a governed system, not raw fuel
The data branch expands into:
- acquisition and licensing;
- consent, privacy, and rights;
- provenance and lineage;
- parsing and normalization;
- filtering, quality scoring, and deduplication;
- language, domain, and demographic coverage;
- labeling, preference data, and feedback;
- synthetic-data generation and validation;
- train/validation/test partitioning and contamination control;
- versioning, retention, deletion, and audit.
The ISO/IEC 5259 series treats data quality as its own discipline across measurement, management, process, and governance. This is why “the same architecture” can produce very different models: the training distribution and its treatment are part of the learned result.
2.3 Training is several pipelines, not one event
flowchart LR A[Acquire and curate data] --> B[Tokenize or encode] B --> C[Pretraining objective] C --> D[Base checkpoints] D --> E[Post-training and alignment] E --> F[Capability and safety evaluation] F --> G[Release candidate] G -->|failure or gap| A G --> H[Model artifact]
For a language model, pretraining commonly learns through a self-supervised prediction objective. Post-training may then include supervised demonstrations, preference optimization, reinforcement learning with human or verifiable feedback, safety training, tool-use training, distillation, or domain adaptation. The InstructGPT paper is a clear early example of supervised instruction tuning followed by preference-based reinforcement learning.
The scaling literature also corrects the folk story that model size is the only variable. Scaling Laws related loss to data, parameters, and compute; Chinchilla showed that balanced scaling of parameters and training tokens mattered under a fixed compute budget. Architecture, data, compute allocation, optimization, and post-training jointly shape capability.
2.4 What exactly is “the model”?
The Transformer established the attention-based architecture underlying most modern LLMs, but a runnable artifact still has several parts:
| Artifact part | Job | Typical mismatch symptom |
|---|---|---|
| Architecture/config | Defines layers, dimensions, attention, experts, position scheme | Weights cannot load or produce nonsense |
| Weights | Encodes the learned numerical state | Different capability/behavior despite same architecture |
| Tokenizer/vocabulary | Converts inputs and outputs between symbols and model IDs | Broken text, wrong token counts, incompatible special tokens |
| Precision/quantization | Chooses numerical representation and memory/performance tradeoff | Quality loss, unsupported kernels, memory overflow |
| Chat/generation template | Serializes roles, messages, and special markers | Poor instruction following or malformed turns |
| Model documentation | Records intended uses, limits, tests, provenance | Downstream misuse and untraceable assumptions |
This boundary lets us say precisely what changes:
| Change | Updates learned weights? | Can materially change behavior? |
|---|---|---|
| System prompt or context | No | Yes |
| Retrieval/index/reranker | No | Yes |
| Tool set or permission | No | Yes, including real-world consequences |
| Workflow or agent loop | No | Yes, especially multi-step reliability |
| LoRA/adapter/fine-tune | Yes, through added or modified trained parameters | Yes |
| Continued pretraining | Yes | Yes |
| New architecture or pretraining run | Yes, fundamentally | Yes |
LoRA is a useful example: it freezes the base model and trains small low-rank adapter parameters. The product can also change dramatically without any weight update at all.
3. Running the model: inference and serving
3.1 A model call has its own pipeline
sequenceDiagram
participant App as Application
participant Gate as Model gateway
participant Sched as Scheduler
participant Model as Inference engine
App->>Gate: request, context, model, limits
Gate->>Gate: authenticate, authorize, quota, policy
Gate->>Sched: tokenized request
Sched->>Model: batch and route
Model->>Model: prefill input and create KV state
loop decode
Model-->>App: stream generated token or chunk
end
Gate-->>App: usage, finish reason, trace metadata
The engine usually performs a highly parallel prefill over the input, then an autoregressive decode in which each generated token depends on prior state. The KV cache stores attention state so previous tokens need not be recomputed on every decode step. Queue time, tokenization, prefill, first-token latency, per-token latency, network time, and total completion time are different measurements.
3.2 Sampling is where probabilities become one output
The model produces scores over possible next tokens. A decoding policy turns that distribution into a selected token using techniques such as greedy choice, temperature scaling, top-k/top-p sampling, penalties, constrained decoding, or structured-output grammars. “The same model” can therefore produce different outputs under different generation settings.
3.3 Serving is a systems problem
Production serving adds:
- request routing and model selection;
- admission control and rate limits;
- batching and continuous scheduling;
- KV-cache allocation and reuse;
- prefix/prompt caching;
- streaming;
- quantization and optimized kernels;
- speculative decoding;
- multi-GPU placement and autoscaling;
- overload behavior, cancellation, and fallback;
- usage accounting and cost allocation.
PagedAttention and vLLM showed how better KV-cache memory management and scheduling could raise throughput by 2–4x in the paper’s studied configurations. Speculative decoding demonstrated 2–3x acceleration in its experiments by letting a cheaper model propose tokens that the target model verifies. These are not changes to the user’s prompt or business logic; they are changes to how inference is executed.
MLPerf Inference separates Offline, Server, Interactive, SingleStream, and MultiStream scenarios. That taxonomy exposes why a single “tokens per second” number is insufficient.
| Metric | What it answers |
|---|---|
| Time to first token/chunk | How quickly does useful output begin? |
| Inter-token latency | How smoothly does output continue? |
| End-to-end latency | How long until the requested result is complete? |
| Throughput | How much work completes per time unit? |
| Concurrency/tail latency | What happens when many requests arrive together? |
| Utilization/energy/cost | What resources were consumed per useful outcome? |
| Quality under optimization | Did quantization, routing, or caching alter acceptable behavior? |
3.4 A hosted model API is not IaaS
NIST SP 800-145 formally defines SaaS, PaaS, and IaaS. “Model as a Service” is useful descriptive vocabulary, but not one of those canonical NIST models. A hosted inference API is clearly not IaaS: the consumer does not manage virtual machines, the operating system, accelerator drivers, weights, or serving engine. Depending on the offering it behaves more like a managed application capability or a platform building block.
4. Constructing the model’s situation
4.1 Context is what is visible now
The application, not the model alone, builds the working desk:
governing instructions and policy
+ application/developer instructions
+ current user input
+ selected conversation history or summary
+ retrieved documents and provenance
+ tool definitions
+ tool results and observations
+ retrieved memory
+ plans or structured task state
+ output format/schema
= model-visible context for this callA large context window is capacity, not persistent memory and not guaranteed use. Lost in the Middle found that some models used relevant information less reliably depending on where it appeared in long input. Context engineering is therefore a selection and ordering problem, not merely a token-maximization exercise.
4.2 Four kinds of “knowledge” must stay separate
| Kind | Where it lives | How it becomes available |
|---|---|---|
| Parametric model knowledge | Distributed through learned weights | Activated by the current input; not exact database lookup |
| Current context | Request-visible token sequence | Assembled by the application now |
| External knowledge | Documents, databases, search, APIs | Retrieved or queried through software/tools |
| Persistent memory | Stored records about prior state/experience | Selected by a memory policy and placed back into context/control flow |
4.3 RAG is an information system
The original RAG paper combined parametric and external non-parametric memory. A production implementation expands into a full pipeline:
flowchart LR A[Sources] --> B[Parse, normalize, chunk] B --> C[Provenance, metadata, access policy] C --> D[Index and embed] Q[User task] --> E[Query understanding] E --> F[Retrieve candidates] D --> F F --> G[Filter and rerank] G --> H[Pack context] H --> I[Generate grounded answer] I --> J[Citation, evaluation, feedback] J -->|refresh or correction| D
Each stage can fail independently. The right document may not be ingested; a chunk may lose context; the index may be stale; retrieval may miss; authorization may filter incorrectly; reranking may select noise; the model may ignore good evidence; citations may not support the claim.
4.4 Memory is storage plus policy
The memory basket is larger than “vector store”:
| Memory/state type | Example | Primary risk |
|---|---|---|
| Working state | Current plan, completed steps, open questions | Context overflow or corrupted task state |
| Conversation state | Messages or summaries in one thread | Lossy summaries, role confusion |
| Episodic memory | “The last deployment failed because…” | Stale or false recollection |
| Semantic memory | Project facts, user preferences | Conflict, leakage, overgeneralization |
| Procedural memory | Skills, playbooks, operating rules | Malicious or outdated instruction |
| External knowledge | Handbook, codebase, database | Freshness, authorization, provenance |
| Durable execution state | Task status, artifacts, idempotency keys | Double execution or unrecoverable partial work |
MemGPT drew an operating-system analogy for managing memory tiers beyond the context window. Generative Agents used observation records, retrieval, reflection, and planning. Both reinforce the architectural point: useful memory needs decisions about what to write, consolidate, retrieve, expose, correct, expire, and delete.
5. Tools and the harness: intention becomes execution
5.1 Two actors are always present
sequenceDiagram participant M as Model participant H as Harness/runtime participant P as Policy and identity participant T as Tool/environment M->>H: propose tool and arguments H->>H: validate schema and intent H->>P: authorize this actor, resource, action, context P-->>H: allow, require approval, or deny H->>T: execute bounded operation T-->>H: typed result, receipt, or error H-->>M: observation safe for model context
The model generates a proposal. The harness owns the side effect. This split is the foundation of safe tool use.
5.2 Tools are more than read versus write
NIST’s agent-tool workshop taxonomy provides a stronger external anchor:
| Purpose | Tool basket |
|---|---|
| Perception | databases, monitoring, diagnostics, GUI, voice, internet search, physical sensors |
| Reasoning support | planning, decomposition, pathfinding, scratchpads, calculators, simulations, resource management |
| Action | authentication, computer use, code execution, software/API extensions, physical devices, human communication, agent interaction |
The same tool must also be classified by access pattern, risk, reliability, modality, observability, autonomy, reversibility, and whether its environment is trusted. A browser reading public pages is different from a browser logged into payroll. A shell in an ephemeral sandbox is different from root access on a production host.
5.3 Permissions should express verbs and consequences
discover → read → propose → preview → approve → execute → verify → reverseA mature system separates these permissions. “Can access calendar” is too coarse; reading availability, drafting an invitation, sending it, cancelling it, and changing attendee permissions have different consequences.
5.4 MCP standardizes capability access, not trust
The current MCP 2026-07-28 specification standardizes how hosts, clients, and servers expose resources, prompts, tools, elicitation, and optional extensions. The current core uses stateless, self-contained JSON-RPC requests; the Tasks extension supports long-running operations with durable handles and mid-flight input.
MCP belongs primarily between the application/agent runtime and capabilities. It does not decide whether a tool is appropriate for a user, does not eliminate prompt injection, and does not replace application authorization or business policy.
6. Where agency begins
6.1 Not every multi-step AI system is an agent
Anthropic’s production guidance draws a useful line:
- Workflow: predefined code controls how models and tools are orchestrated.
- Agent: the model dynamically directs parts of its own process and tool use.
The bars show increasing control complexity, not quality or maturity.
6.2 Common code-controlled workflows
- Prompt chaining: one model step prepares input for the next.
- Routing: code or a classifier chooses a specialized path.
- Parallelization: independent model/tool calls run concurrently and are merged.
- Orchestrator-workers: a coordinator decomposes work and dispatches workers.
- Evaluator-optimizer: one step creates, another critiques, and the loop stops by a defined rule.
These patterns can be powerful, testable, and easier to govern than an open-ended agent.
6.3 Agent anatomy
ReAct popularized interleaving reasoning and action. A production-grade anatomy is broader:
goal and success criteria
+ model and instructions
+ context construction
+ perception/tools
+ action tools
+ working state
+ plan or policy for choosing the next step
+ budget: time, tokens, money, actions
+ verification and error recovery
+ stopping and escalation conditions
+ optional persistent memory
= agent runtimeThe canonical loop is:
flowchart LR
A[Goal] --> B[Observe]
B --> C[Decide or plan]
C --> D[Act through runtime]
D --> E[Observe result]
E --> F[Update state and verify]
F --> G{Done, blocked, unsafe, or continue?}
G -->|continue| B
G -->|done| H[Return outcome and evidence]
G -->|needs intent or approval| I[Escalate to human]
G -->|unsafe or budget exhausted| J[Stop safely]
Without a budget and a stopping rule, an agent loop is an unbounded process. Without external verification, a fluent final message is not evidence that the goal was achieved.
7. What sits above an agent
This is the branch the original note only named as “production system.” It contains several distinct coordination scopes.
7.1 Workflow and orchestrator
An orchestrator decides how work is decomposed and recombined. It may be deterministic code, a model-directed supervisor, or a hybrid.
Responsibilities include:
- task decomposition and dependency graph;
- routing to models, tools, services, humans, or agents;
- concurrency and priority;
- budget allocation;
- shared-state boundaries;
- join/merge and conflict resolution;
- retries, fallback, and escalation;
- termination and acceptance criteria.
The orchestrator is “above” the agent only when it coordinates one or more agents. Inside a single agent, similar logic may be part of its runtime.
7.2 Durable execution
Reasoning is not durability. A long-running task must survive process restarts, network failures, timeouts, and human delays. Temporal’s workflow documentation is one concrete implementation of event history and replay; the general responsibilities are platform-independent:
- persist state transitions and artifacts;
- make mutation idempotent or deduplicated;
- retry with bounded policy and deadlines;
- wait for timers, external events, or approvals;
- support cancellation and cleanup;
- compensate for partially completed side effects;
- resume after worker or machine failure;
- version workflows without corrupting in-flight work.
sequenceDiagram participant U as User or event participant W as Durable workflow participant A as Agent participant T as Tool/service participant H as Human approver U->>W: start task W->>A: bounded subgoal A->>T: propose and execute allowed work T--xA: transient failure W->>W: record state, backoff, retry A-->>W: artifact and evidence W->>H: request consequential approval H-->>W: approve later W->>T: idempotent mutation W-->>U: completed outcome
7.3 Multi-agent coordination
Multiple agents can add specialization, independent perspectives, parallelism, or containment. They also add communication overhead, duplicated work, correlated failure, conflicting goals, false consensus, shared-memory hazards, and a larger security surface.
| Topology | Shape | Useful when | Main failure |
|---|---|---|---|
| Supervisor-workers | One delegates and merges | Tasks decompose cleanly | Bottleneck or biased supervisor |
| Hierarchy | Delegation tree | Large nested programs | Context loss and accountability diffusion |
| Peer handoff | Agents transfer ownership | Work crosses specialties | Dropped or looping handoffs |
| Blackboard | Shared workspace | Agents build on common artifacts | Poisoned/stale shared state |
| Pipeline | Fixed specialist stages | Stable repeatable process | Error propagation and rigidity |
| Debate/committee | Competing proposals and judge | Independent critique matters | Correlated beliefs and false consensus |
| Market/auction | Capability/cost-based allocation | Dynamic heterogeneous supply | Gaming, opaque incentives, coordination cost |
| Swarm | Local rules, emergent coordination | Simulation or highly parallel exploration | Unpredictability and weak global guarantees |
Why Do Multi-Agent LLM Systems Fail? reported 14 failure modes grouped under specification/system design, inter-agent misalignment, and verification/termination. “Add more agents” is not a reliability strategy.
7.4 A2A and agent opacity
The current A2A 1.0 specification provides discovery through agent cards, message and artifact exchange, task lifecycle, streaming, asynchronous updates, cancellation, and standard authentication schemes. It lets independent agents collaborate without revealing their internal tools, memory, or implementation.
The boundaries are complementary:
| Interface | Primary relationship |
|---|---|
| MCP | Application/agent runtime to resources and tools |
| A2A | Independent agent system to agent system |
| Durable workflow/event bus | Coordination across time, services, and failures |
| API/RPC | Ordinary typed service-to-service operation |
| UI/approval surface | Human to system decision and control |
7.5 Agent platform and control plane
Once several products or teams share agents, the “above-agent” layer becomes a platform:
model gateway and routing
tool registry and secure execution gateway
knowledge and memory services
agent registry and versioning
identity, delegation, and policy engine
sandbox and secrets broker
workflow/durable task service
budget, quota, rate, and cost controls
trace, evaluation, and audit plane
deployment, rollout, rollback, and kill controlsThis resembles a service platform more than a prompt library. Its most important outputs are consistent boundaries and evidence.
7.6 Product, process, and institution
The product layer decides what the user can ask, see, approve, interrupt, correct, and appeal. The business-process layer decides where records live, who owns exceptions, how separation of duties works, and what counts as completion. The organizational layer inventories systems, assigns risk owners, reviews suppliers, trains operators, monitors impacts, handles incidents, and decides when a capability should be changed or retired.
ISO/IEC 42001 calls this an AI management system. ISO/IEC 42005 adds lifecycle impact assessment. These are genuinely above any individual agent because they govern the organization’s relationship with an AI portfolio.
8. The production rails
8.1 Reliability rail
Agentic systems inherit ordinary distributed-systems failure modes and add probabilistic decision errors.
| Control | Why it exists |
|---|---|
| Deadlines and timeouts | Prevent dependencies or loops from consuming unbounded time |
| Bounded retries with backoff/jitter | Recover transient failures without synchronized overload |
| Idempotency and deduplication | Make repeated mutation safe after ambiguous outcomes |
| Admission control and concurrency limits | Keep demand inside capacity |
| Backpressure and load shedding | Prevent queues and stale work from becoming a collapse loop |
| Circuit breakers and isolation | Contain failing dependencies |
| Cancellation and cleanup | Stop work whose user or workflow no longer needs it |
| Checkpoint/replay | Recover progress after process or machine failure |
| Compensation | Reverse or offset partial multi-step side effects |
| Fallback/degradation | Preserve a safe smaller capability during failure |
| Version pinning and lineage | Reproduce which model, prompt, tool, policy, and data acted |
| Canary, rollback, incident response | Limit and repair change-induced regressions |
Google’s secure and reliable systems guidance emphasizes idempotency and understandability because distributed operations may be retried after an outcome becomes ambiguous. Agent tools that send, purchase, delete, deploy, or publish need the same discipline.
8.2 Evaluation rail
Model benchmarks are only the first layer of evidence.
| Evaluation level | Central question | Example evidence |
|---|---|---|
| Model | Can the model perform relevant primitives safely and efficiently? | Capability, calibration, robustness, bias, toxicity, efficiency |
| Context/prompt | Does the call follow instructions and use supplied evidence? | Schema validity, grounding, long-context tests |
| Retrieval | Did the right authorized evidence reach context? | Recall, ranking, freshness, citation support |
| Tool | Was the correct operation called safely? | Selection, arguments, authorization, side-effect receipt |
| Memory | Is remembered state useful, isolated, correct, and deletable? | Recall, conflict, poisoning, deletion tests |
| Trajectory | Was the process sound? | Plan, step necessity, recovery, budget, stopping, escalation |
| Task/system | Did the real goal complete under realistic conditions? | End-to-end success, latency, cost, failure recovery |
| Human | Did the system improve outcomes without miscalibrated trust or harm? | Effectiveness, effort, satisfaction, accessibility, recourse |
| Operational/business | Does deployment remain valuable and governable? | Incident rate, containment, process quality, downstream impact |
HELM made the case for multi-scenario, multi-metric model evaluation. AgentBench moved evaluation into interactive environments; SWE-bench required real repository edits against issue-level tasks. The August 2026 NIST TEVV-Athlon initial public draft explicitly targets customizable assessment across models and agentic systems. It is promising but still a draft, not a final standard.
Verification asks whether the build meets specified requirements. Validation asks whether the resulting system works for the intended use and context. Production monitoring asks whether those claims continue to hold after deployment.
8.3 Observability rail
The emerging OpenTelemetry GenAI conventions distinguish model operations, planning, tool execution, agent invocation, and workflow invocation. That hierarchy matches the system boundary:
workflow trace
├── agent invocation
│ ├── plan
│ ├── model call
│ ├── tool execution
│ └── verification
├── human approval wait
└── final side effect and receiptUseful telemetry includes trace/task IDs, model and component versions, token/cache usage, latency by stage, tool authorization and result, state transitions, retries/cancellations/approvals, termination reason, evaluation results, cost/budget, and artifact lineage. Prompt, completion, retrieved content, and tool arguments may contain secrets or personal data; full-content logging must be an explicit governed choice.
8.4 Security rail
The OWASP Top 10 for Agentic Applications 2026 provides a current failure anchor:
| ID | Risk | Primary boundary |
|---|---|---|
| ASI01 | Agent goal hijack | Instructions, external content, intent integrity |
| ASI02 | Tool misuse and exploitation | Tool design, validation, policy, consequence |
| ASI03 | Identity and privilege abuse | Authentication, delegation, least privilege |
| ASI04 | Agentic supply-chain vulnerability | Models, data, tools, plugins, protocols, dependencies |
| ASI05 | Unexpected code execution | Sandbox, interpreter, shell, generated code |
| ASI06 | Memory and context poisoning | Retrieval, memory writes, provenance, isolation |
| ASI07 | Insecure inter-agent communication | Agent identity, message integrity, authorization |
| ASI08 | Cascading failures | Multi-step and multi-agent error propagation |
| ASI09 | Human-agent trust exploitation | UX, explanation, approval quality, overtrust |
| ASI10 | Rogue agents | Misalignment, concealment, uncontrolled action |
Security principles:
- authenticate users, services, tools, and agents where relevant;
- authorize consequential actions outside the model;
- grant least privilege, least duration, and least agency;
- keep credentials and secrets out of model-visible text;
- sandbox code and computer use;
- carry provenance and trust labels with external content;
- validate tool schemas, arguments, results, and side-effect receipts;
- separate read, propose, approve, and execute;
- prefer reversible or compensatable operations;
- inventory and verify models, adapters, data, tools, and dependencies;
- preserve audit evidence and define containment, kill, rollback, and incident response.
NIST AI 600-1 expands the risk view beyond attacks to confabulation, privacy, bias/homogenization, information integrity, IP, environmental impact, human-AI configuration, and component/value-chain integration. NIST SP 800-218A applies secure-software-development practices to model producers, AI-system producers, and acquirers.
9. The human and organizational system
9.1 Start from the human activity, not the model technique
NIST AI 200-1 enumerates 16 domain-independent human-AI activities:
| Cluster | Activities |
|---|---|
| Create and transform | Content creation, content synthesis |
| Judge and anticipate | Decision making, detection, prediction, recommendation |
| Find and understand | Discovery, image analysis, information retrieval/search |
| Assist and adapt | Digital assistance, personalization, performance improvement |
| Operate and automate | Monitoring, process automation, robotic automation, vehicular automation |
This prevents technique-first design. A recommendation system and a decision-making system may use the same model but need different authority, explanation, evaluation, and recourse.
9.2 Human oversight is a set of decision rights
“Human in the loop” is too vague. Oversight may happen:
- Before work: scope, tools, data, budget, and policy selection.
- During planning: preview, edit, or reject the plan.
- Before mutation: require approval for consequential or irreversible action.
- During execution: pause, cancel, redirect, or narrow scope.
- At uncertainty: agent asks for missing intent or domain judgment.
- After execution: verify outcome, audit evidence, correct, reverse, or appeal.
- At system level: change permissions, model, policy, workflow, or deployment.
The right gate depends on consequence, reversibility, uncertainty, time pressure, affected parties, and the human’s actual ability to judge. A confirmation button on an unreadable plan does not create meaningful control.
9.3 Governance is continuous system ownership
The NIST AI RMF core wraps the lifecycle in four functions:
flowchart LR G[Govern: roles, policy, risk tolerance] --> M[Map: context, purpose, people, impact] M --> E[Measure: test, evaluate, monitor] E --> A[Manage: prioritize, treat, respond] A --> G
An organization operating AI needs at least:
- a current system and dependency inventory;
- named business, technical, data, security, and risk owners;
- documented intended use, prohibited use, limits, and affected parties;
- supplier and model/tool/data due diligence;
- pre-deployment evaluation and approval evidence;
- production monitoring, incident response, redress, and rollback;
- change control for model, prompt, retrieval, tool, workflow, and policy updates;
- operator training and user communication;
- impact assessment and periodic review;
- retirement, data deletion, and record-retention processes.
This is the final conceptual leap: an AI capability becomes an institution when other people depend on its decisions and actions. The institution needs ownership and repair mechanisms, not only better prompts.
10. The complete tree
Status labels: Live common and operational now; Emerging real but immature or uneven; Niche important outside the mainstream path; Dormant visible but not a default action branch.
Wing A — intelligence production
- Live Compute substrate
- accelerators, CPU, host memory, high-bandwidth memory;
- local and distributed storage;
- network/interconnect and cluster scheduling;
- power, cooling, capacity, hardware supply chain.
- Live Data system
- acquisition, rights, privacy, provenance;
- quality, filtering, deduplication, labeling;
- synthetic and preference data;
- partitioning, contamination, versioning, lineage.
- Live Learning pipeline
- objective, optimization, distributed training;
- checkpointing, evaluation, post-training;
- safety, distillation, adaptation, release.
- Live Model artifact
- architecture, weights, tokenizer, configuration;
- precision/quantization, templates, documentation.
- Niche here Other model families
- diffusion, state-space, graph, probabilistic, symbolic;
- classical ML, control, reinforcement learning.
Wing B — application assembly
- Live Inference serving
- routing, batching, prefill/decode, KV cache;
- sampling, streaming, caching, quota, gateway.
- Live Context engineering
- instructions, history, retrieval, tool schemas/results;
- state selection, ordering, compression, output contracts.
- Live Knowledge and RAG
- ingestion, index, retrieval, ranking;
- permissions, grounding, citation, freshness.
- Emerging Memory
- working, episodic, semantic, procedural, durable execution;
- write, consolidate, retrieve, correct, expire, delete.
- Live Multimodal system
- text, image, audio, video, sensor input and generated output.
Wing C — action and agency
- Live Tool runtime
- discovery, schema, validation, policy, execution, result, audit.
- Live Deterministic workflow
- chain, route, parallelize, evaluator, orchestrator-worker.
- Live Single-agent loop
- goal, observe, plan, act, update, verify, stop/escalate.
- Emerging Durable long-running agent
- persisted state, timers, recovery, cancellation, human approval.
- Emerging Multi-agent system
- supervisor, hierarchy, peers, blackboard, debate, market, swarm.
- Dormant/high-risk Self-modifying or replicating agent
- controlled self-improvement belongs under strict change management;
- unconstrained self-replication is not a default production pattern.
Wing D — above-agent coordination
- Live Orchestrator
- decomposition, dispatch, dependency, budget, merge, termination.
- Live Durable workflow engine
- event history, retries, idempotency, compensation, async waits.
- Emerging Capability and agent registry
- discovery, ownership, health, policy, version, compatibility.
- Emerging Interoperability
- MCP, A2A, API/RPC, events, identity and delegation.
- Emerging Agent platform/control plane
- model/tool/knowledge gateways, policy, sandbox, budget, trace, deploy.
- Niche/dormant Agent market/economy
- machine identity, negotiation, payment, reputation, dispute, liability.
Wing E — product, people, organization
- Live User experience and control
- intent, progress, preview, explanation, approval;
- cancel, correction, rollback, recourse.
- Live Business process
- case state, records, separation of duties, exceptions, accountability.
- Live Operations
- SLOs, observability, incident response, capacity, cost, rollout/rollback.
- Incomplete Assurance
- model and component tests, journey tests, red teaming, monitoring, audits.
- Mandatory Security and privacy
- identity, privilege, isolation, provenance, supply chain, containment.
- Emerging/live Governance and management system
- inventory, ownership, risk, impact, procurement, change, compliance.
- Often omitted Societal and environmental impact
- affected non-users, labor/process change, access, energy and externalities.
Niche shelf
- Embodied agents and autonomous vehicles: perception, real-time control, physical safety, simulation, certification, and fail-safe behavior dominate.
- Edge/on-device agents: intermittent connectivity, constrained power/memory, privacy, local models, and hardware diversity dominate.
- Neuro-symbolic and formal systems: learned perception or generation is combined with rules, solvers, proof, planning, or verification.
- Non-language multi-agent systems: robotics, games, operations research, economics, and control have older coordination traditions than LLM agents.
- Human-agent organizations: incentives, labor design, authority, institutional memory, and power matter more than prompt syntax.
- Privacy-preserving/federated/confidential AI: compute and data boundaries are redesigned around confidentiality and distributed ownership.
- Agent economies: machine identity, delegated payment, contract, reputation, liability, and dispute resolution remain immature.
- Controlled self-improvement: agents may propose changes to prompts, tools, memory policy, code, or adapters, but evaluation and approval must govern promotion.
Residual bucket
The report does not descend fully into semiconductor manufacturing, every learning paradigm, diffusion-first media systems, robotics safety standards, formal verification, every regional law, the philosophy of intelligence, or speculative AGI/ASI governance. These are real branches outside the chosen LLM-application depth. A map claiming no residue would be dishonest.
11. What the original draft had—and what was added
| Surface | Seed note | This report |
|---|---|---|
| Model, weights, checkpoint | Strong foundation | Added artifact package and adaptation boundaries |
| Training and inference | Clear distinction | Added data lifecycle, scaling, post-training basket, serving mechanics |
| API/service | Clear intuition | Corrected MaaS as useful, not canonical NIST service taxonomy |
| Context and RAG | Correct basics | Added construction pipeline, long-context limits, full RAG lifecycle |
| Tools and permissions | Strong conceptual split | Added NIST tool taxonomy, authority dimensions, MCP boundary |
| Agent loop | Correct core | Added workflow distinction, anatomy, budgets, stopping, autonomy dimensions |
| Memory | Correct separation | Added memory types and write/retrieve/correct/delete policy |
| Above the agent | Named only as production | Added orchestrator, durability, multi-agent, A2A, platform, product, institution |
| Evaluation and observability | Introduced | Expanded into component, trajectory, task, human, operational evidence |
| Reliability and security | Partial | Added distributed-systems controls and complete OWASP agentic categories |
| Human use and governance | Thin | Added NIST 16 activities, oversight rights, RMF loop, ISO management/impact |
The source was not wrong. It had the right skeleton. The expansion adds the connective tissue that makes the skeleton usable in production.
Recommendations
1. Teach the system as boundaries, not a buzzword ladder
Use one reconstruction sentence:
A company uses compute and data to train a model; serves the resulting artifact through an inference system; constructs context, knowledge, and memory around each call; exposes controlled tools through a runtime; lets a model direct repeated action when agency is needed; coordinates longer or multi-party work through durable workflows; and surrounds the whole capability with product design, evidence, security, operations, human control, and governance.
2. Ask seven questions whenever someone says “the AI”
- What human goal and activity is being served?
- Which behavior comes from the model, and which from code, context, data, or tools?
- Who controls the next step: human, deterministic workflow, or model?
- What may the system read, propose, approve, or change?
- What state must survive, and how is it recovered, corrected, or deleted?
- What evidence proves the components, trajectory, and full system work here?
- Who owns the outcome, monitors the system, and can stop or repair it?
3. Earn complexity one constraint at a time
direct call
→ add retrieval only when external knowledge is required
→ add tools only when the system must observe or act
→ add a workflow when the repeatable path is known
→ add an agent when the path cannot be predetermined
→ add multiple agents only when specialization or parallelism beats coordination cost
→ add durable orchestration when work must survive time and failure
→ add a platform and management system when capability becomes shared or consequential4. Treat “above agent” as control, not more intelligence
Do not search for a mystical noun above “agent.” The practical progression is:
agent
→ orchestrated task graph
→ durable multi-agent/service workflow
→ shared agent platform and control plane
→ human-facing product and business process
→ governed organizational capabilityEach level must add explicit state, authority, evidence, ownership, and repair.
5. Keep the map maximal and the build selective
The tree is an atlas, not a backlog. Most applications should not build a multi-agent platform, durable memory hierarchy, marketplace, and governance office on day one. Keep dormant and niche branches visible, then activate only what the use case, consequence, and operating scale require.
Important
The stopping rule. If a direct call or deterministic workflow can meet the goal with better predictability, do not add an agent merely to make the architecture sound advanced.
Methodology notes
Seed material. /Users/hamulia/Downloads/AI_101_From_Model_to_Agent.md, created 2026-08-28. The seed supplied the original distinctions and teaching metaphors. It was treated as a research seed, not as a source of external factual authority.
External anchors. ISO/IEC 22989:2022 terminology; ISO/IEC 23053:2022 ML-system framework; ISO/IEC 5338:2023 lifecycle processes; ISO/IEC 42001:2023 AI management systems; ISO/IEC 42005:2025 impact assessment; ISO/IEC 5259 data quality; OECD AI system classification; NIST AI RMF 1.0 lifecycle, actors, and Govern/Map/Measure/Manage; NIST AI 200-1 human-AI activities; NIST agent-tool taxonomy; NIST AI 600-1; NIST SP 800-218A; NIST TEVV-Athlon initial public draft.
Technical papers and primary documentation. Transformer; Scaling Laws; Chinchilla; InstructGPT; LoRA; RAG; Lost in the Middle; MemGPT; Generative Agents; Toolformer; ReAct; PagedAttention/vLLM; speculative decoding; HELM; AgentBench; SWE-bench; multi-agent survey and failure taxonomy; Anthropic agent architecture and trustworthy-agent guidance; MCP 2026-07-28; A2A 1.0; OpenTelemetry GenAI conventions; Temporal durable execution; MLPerf Inference; Google secure and reliable systems guidance; OWASP Agentic Top 10 2026.
Generators walked. (1) vertical stack, (2) lifecycle, (3) source of control, (4) failure surface, (5) actor/counterparty, and (6) deployment form. Their union created the spine-and-rails model and the four distinct scopes above a single agent.
Anchor diff result. The seed covered the conceptual core from model through memory. The largest misses were data and serving depth, workflow-versus-agent control, durable execution, multi-agent coordination and protocols, product/human activity, layered assurance, full agentic security, and organizational governance.
Caveats. ISO public pages summarize standards whose full normative text may require purchase. OpenTelemetry GenAI agent conventions remain under development. NIST TEVV-Athlon is an initial public draft as of August 2026. MCP and A2A are rapidly evolving protocols. Vendor architecture guidance is used as practitioner evidence, not as a universal standard. The report intentionally prioritizes LLM-centric application systems and labels other AI traditions as niche or residual rather than pretending equal coverage.
Audit line. Anchored against external lifecycle, system, tool, use, risk, telemetry, and interoperability taxonomies; six generators rotated; the supplied “agent” example expanded into workflow, durable execution, multi-agent topology, platform, product, and institution; niche shelf populated; residual declared. Coverage is standard-depth totality for the scoped LLM-centric system.