Glossary – Agentic Work in Real Life
This glossary brings together the technical vocabulary used throughout “Agentic Work in Real Life” and adds several terms that frequently appear in the current AI and agentic-engineering discourse even when they are not central to the articles themselves.
The explanations are intentionally concise and practice-oriented. Some terms – especially AGI, ASI, Agentic AI, Frontier Model, Memory, Skill, and Vibe Coding – are not standardized and may be used somewhat differently by different providers or communities.
Product, model, organization, and paper names are not included exhaustively. Names such as SWE-bench or ARC-AGI are exceptions where they have effectively become widely used technical terms or benchmark families.
| Term / Acronym | Expanded form | In short |
|---|---|---|
| Acceptance Criteria | — | Criteria used to decide whether a requirement or change is considered functionally and technically fulfilled. |
| Acceptance Test | — | Test that checks whether a system or feature meets defined functional acceptance criteria. |
| Accepted Change | — | A change that can be adopted after sufficient technical and functional verification. |
| Access Control | — | Mechanisms that determine who or what may access data, functions, or systems. |
| Active Parameters | — | In Mixture-of-Experts models, the subset of all model parameters actually activated for a specific token or computation step. |
| ADR | Architecture Decision Record | A short, versioned document recording an important architecture decision, its context, and rationale. |
| Affected Analysis | — | Determining which projects, modules, or tests are actually affected by a change so work and verification can be scoped precisely. |
| Agent | — | A system that pursues a goal across multiple steps by combining a model, context, tools, and other mechanisms. |
| Agent File | — | A project- or workspace-specific instruction file for agents, for example containing architecture, build, or working rules. Explored in depth in Article 04. |
| Agent Harness | — | The software environment that turns a model into an agent by orchestrating context, tools, loops, state, and execution. |
| Agent Infrastructure | — | Reusable technical and organizational foundations for agentic work, such as rules, skills, tests, tooling, and verification mechanisms. |
| Agent Skill | — | A reusable playbook or procedure that tells an agent how to handle a particular kind of task. |
| Agent Time | — | Time during which an agent works on a task autonomously. |
| Agent-readable | — | Property of a system whose relevant structure, rules, and information are discoverable and understandable for an agent. |
| Agent-verifiable | — | Property of a system in which an agent can check results with executable mechanisms such as builds, linting, tests, or architecture rules. |
| Agentic AI | — | Umbrella term for AI systems that do more than generate answers: they can pursue goals across multiple steps and perform actions. |
| Agentic Coding | — | Software development in which coding agents autonomously perform parts of the development process such as analysis, modification, and testing. |
| Agentic Work | — | A way of working in which AI agents handle multi-step tasks with some degree of autonomy. |
| AGI | Artificial General Intelligence | A non-standardized term for AI with broad, generalizable capabilities at or near human level across many domains. |
| AI | Artificial Intelligence | Umbrella term for computer systems that perform tasks typically associated with perception, language, learning, planning, or problem solving. |
| AI Coding Assistant | — | AI tool that helps developers write or modify code; compared with a coding agent, it often has less autonomous tool use and autonomy. |
| AI Safety | — | Research and engineering field concerned with limiting harmful, unwanted, or uncontrolled behavior in capable AI systems. |
| Alignment | — | Work aimed at making an AI system act in accordance with intended goals, rules, and human oversight. |
| Anonymization | — | Transforming data so individuals can no longer be identified; truly anonymized data must be distinguished from pseudonymized data. |
| API | Application Programming Interface | A defined interface through which software components or services communicate. |
| ARC-AGI | Abstraction and Reasoning Corpus for Artificial General Intelligence | Benchmark family for generalization and acquiring new skills; a high score is not universal proof that AGI has been achieved. |
| Architecture Constraint | — | An architecture rule that permits or excludes certain structural solutions and therefore narrows the solution space. Explored in depth in Article 08. |
| Architecture Review | — | A review focused on whether a change fits the responsibilities, boundaries, dependencies, and architecture of the system. |
| ASI | Artificial Superintelligence | Hypothetical term for AI whose general cognitive capabilities substantially exceed human capabilities; definitions vary. |
| Authorization | — | Decision about whether a user, agent, or system may access a resource or perform an action. |
| Benchmark | — | A standardized task or task set used to measure specific capabilities or properties of a model or system. |
| Benchmark Contamination | — | The problem that benchmark tasks, or very similar data, may have been present in model training and can distort results. |
| Benchmark Overfitting | — | Over-optimizing models or systems for known benchmarks without a corresponding improvement in general capability. |
| Big Ball of Mud | — | Term for a system with little recognizable structure, high coupling, and many historically accumulated exceptions. |
| Broken Windows | — | Metaphor for the tendency of visible neglected exceptions or rule violations to encourage further similar deviations. |
| Build | — | Process that turns source code and other artifacts into an executable or deliverable form and often reveals errors along the way. |
| Cached Tokens | — | Input tokens from recurring context whose previously computed states may be reused by a provider. |
| CapEx | Capital Expenditure | Capital expenditure on assets used over a longer period, such as owned AI hardware. |
| Chain of Thought (CoT) | Chain of Thought | Term for intermediate reasoning steps of a model; visible summaries are not necessarily the model’s complete internal reasoning trace. |
| CI | Continuous Integration | Automated integration and verification of changes, typically including build, linting, and tests. |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment | Automated pipeline for checking, building, and, depending on the setup, delivering or deploying software. |
| Cloud Model | — | AI model used through infrastructure operated by an external or internal cloud provider. |
| Coding Agent | — | Agent that can inspect codebases, modify files, run tools, handle errors, and produce coherent software changes. |
| Cohesion | — | Measure of how closely the responsibilities within a module or component belong together conceptually. |
| Compute Budget | — | Limited amount of compute available for a model request, agent run, or evaluation. |
| Computer Use | — | Ability of an AI system to operate graphical user interfaces using mouse, keyboard, or comparable actions in a human-like way. |
| Constraint | — | An explicit rule or boundary defining which solutions, data flows, or actions are allowed. |
| Context | — | Information actually available to a model for the current processing step. |
| Context Engineering | — | Deliberate selection, structuring, and ongoing maintenance of relevant context for models and agents. Explored in depth in Article 04. |
| Context Window | — | Maximum amount of context a model or specific endpoint can consider in one processing run. |
| Contract | — | Explicit agreement about interface, data format, behavior, or responsibility between parts of a system. |
| Converge | — | Phase in which, after decisions have been made, implementation proceeds as disciplined as possible within the remaining solution space. Part of Diverge · Decide · Converge, explored in depth in Article 10. |
| Coordination Time | — | Human time spent on handoffs, questions, synchronization, context switching, and coordination between agents or work steps. |
| Cost per Accepted Change | — | Engineering metric for the total cost required until a desired change has been sufficiently verified and accepted. Explored in depth in Article 13. |
| Cost per Run | — | Cost of a single model or agent run. |
| Cost per Successful Run | — | Cost per technically successful agent run, including failed attempts needed to reach it. |
| Cost per Token | — | Price or cost at the level of tokens processed or generated by a model. |
| Coupling | — | Degree of dependency between modules or components; high coupling usually makes independent changes harder. |
| CQRS | Command Query Responsibility Segregation | Architecture pattern that deliberately separates read operations from state-changing operations. |
| Credit | — | Product-specific billing unit of an AI service; technically not the same as a token. |
| CRUD | Create, Read, Update, Delete | Four basic operations for creating, reading, updating, and deleting data. |
| Data Minimization | — | Principle of processing or providing only the data actually necessary for a specific purpose. |
| Decide | — | Phase in which open alternatives are evaluated and relevant decisions are made deliberately. Part of Diverge · Decide · Converge, explored in depth in Article 10. |
| Dependency Direction | — | Architecture rule specifying in which direction dependencies between modules or layers are allowed to point. |
| Dependency Graph | — | Graphical or technical representation of dependencies between modules, libraries, services, or other system parts. |
| Determinism | — | Property of a system that reproducibly produces the same result for the same state and input. |
| Developer Experience (DX) | Developer Experience | Quality of the working environment for developers, including clarity, tooling, feedback speed, and local executability. |
| Diff | — | Representation of differences between two versions of files or code. |
| Discovery | — | Phase for understanding and clarifying the problem, requirements, open decisions, risks, and technical context before implementation. |
| Distillation | — | Technique for transferring knowledge or behavior from a larger model into a smaller model. |
| Diverge | — | Phase in which multiple solution paths, hypotheses, or options are deliberately opened up and explored. Part of Diverge · Decide · Converge, explored in depth in Article 10. |
| DPA / AVV | Data Processing Agreement / Auftragsverarbeitungsvertrag | Contract governing the processing of personal data by a data processor; in German law commonly called an Auftragsverarbeitungsvertrag (AVV). |
| Drift | — | Gradual deviation from desired rules, architecture, meaning, or behavior across multiple decisions or steps of action – within a single run or across multiple changes. Explored in depth in Article 06. |
| DRY | Don’t Repeat Yourself | Principle of avoiding unnecessary duplication of knowledge or logic; not a mandate to abstract every similarity. |
| GDPR / DSGVO | General Data Protection Regulation / Datenschutz-Grundverordnung | German abbreviation for the EU General Data Protection Regulation (GDPR), governing the protection and processing of personal data. |
| DTO | Data Transfer Object | Data structure used to transfer information between system parts or interfaces, usually without its own business logic. |
| E2E | End-to-End | Test or view of a complete flow across multiple parts of a system. |
| Embedding | — | Numerical vector representation of content used to compare semantic similarity or relationships computationally. |
| Engineering Capability | — | Ability of a person or organization to reliably understand, develop, change, verify, and operate software. |
| Eval | Evaluation | Targeted assessment of a model or agent system using defined tasks, criteria, and measurement methods. |
| Evaluation Harness | — | Infrastructure that runs evals, provides tools and environments, records execution, and scores results. |
| Executable Architecture | — | Architecture rules that are not merely documented but made mechanically verifiable through tools, tests, or static checks. |
| Feedback Loop | — | Repeated cycle of execution, observation, verification, and correction through which work is improved incrementally. |
| File Boundary | — | Boundary at file or storage-access level; it does not automatically guarantee that the same information is inaccessible by other routes. |
| Fine-Tuning | — | Additional training of an already trained model in which its parameters are adjusted deliberately. |
| Fixed Cost | — | Cost incurred independently of the number of later uses, for example for agent infrastructure or owned hardware. |
| Foundation Model | — | Broadly trained base model that can serve as a foundation for many different tasks and applications. |
| Frontier Model | — | Informal term for models that, at a given time, sit near the capability frontier of publicly or industrially available AI. |
| Function Calling | — | Mechanism that lets a model request structured calls to external functions or tools. |
| Generative AI | — | AI systems that generate new content such as text, images, audio, video, or code. |
| GPU | Graphics Processing Unit | Parallel processor frequently used for AI training and inference because of its high matrix-computation throughput. |
| Ground Truth | — | Reference value or assumed-correct target answer against which a model or system is evaluated. |
| Grounding | — | Connecting a model response to concrete external data, sources, or system state to limit unconstrained plausibility generation. |
| Guardrails | — | Technical or organizational safeguards intended to restrict unwanted inputs, outputs, or actions of an AI system. |
| Hallucination | — | A plausible-sounding but false or unsupported model output. |
| Happy Path | — | Ideal system flow without errors, exceptions, or special cases. |
| Human Active Time | — | Time during which a human must actively analyze, decide, explain, verify, or correct. |
| Human Capital | — | Human knowledge, skills, experience, and judgment as a long-term economic resource. |
| Human Review | — | Review of a result by a human, especially where domain expertise, accountability, or contextual judgment is required. |
| Independent Evidence | — | Verification evidence that does not merely repeat the same assumptions or generation path as the result being checked. |
| Inference | — | Using an already trained model to compute an output from an input. |
| Inference-Time Compute | — | Compute spent while using a model on a specific task, for example for additional reasoning. |
| Information Boundary | — | Boundary defining which information may leave a domain, process, agent, or trust area. |
| Information Flow | — | Path information takes through sources, systems, agents, tools, storage, and outputs. |
| Information Hiding | — | Architecture principle of hiding internal decisions and details behind stable interfaces. |
| Input Tokens | — | Tokens entering a model request, including visible information and system-provided context. |
| Invariant | — | Rule or property that should always hold in a system regardless of a specific change. |
| Jailbreak | — | Attempt to bypass an AI system’s safety or behavioral boundaries using specially crafted input. |
| KI (German AI abbreviation) | Künstliche Intelligenz | German abbreviation for Künstliche Intelligenz, meaning AI; the series generally uses the internationally common abbreviation AI. |
| KV Cache | Key-Value Cache | Cache of attention states that can avoid repeated computation during token generation. |
| Layer | — | Architectural layer with a specific responsibility and defined dependency rules. |
| Least Privilege | — | Security principle that gives a user, agent, or process only the minimum permissions necessary. |
| Legacy System | — | Existing system, often grown over a long period, whose structures and dependencies can make changes difficult. |
| Lint / Linter | — | Static checking of source code against defined quality, style, or error rules. |
| LLM | Large Language Model | Large language model that processes token sequences and typically generates new tokens step by step. |
| LLM-as-a-Judge | — | Method in which a language model evaluates the quality or correctness of outputs from other models. |
| Local Evidence | — | Examples, structures, and rules found in the existing repository or system that provide an agent with clues about desired solutions. |
| Local Inference | — | Running an AI model on owned or otherwise self-controlled infrastructure. |
| Local Model | — | Model that can be run locally or on self-controlled infrastructure. |
| Long-Horizon Agent | — | Agent that works on complex tasks across long periods and many steps. |
| Machine Learning | — | Subfield of AI in which models learn behavioral patterns from data instead of having every rule explicitly programmed by humans. |
| Marginal Cost | — | Additional cost caused by one more unit, such as another agent run or another change. |
| MCP | Model Context Protocol | Open protocol through which AI applications can connect to tools and external data sources in a standardized way. |
| Memory | — | Persistent storage outside model weights from which information can later be brought back into the current context. |
| Model | — | Trained mathematical system that processes inputs and computes outputs. |
| Model Card | — | Documentation describing a model’s capabilities, evaluations, limitations, risks, and intended uses. |
| Model Review | — | Review of a result by another model; useful, but not automatically independent of the assumptions of the generating model. |
| Model Routing | — | Selecting different models or configurations depending on task, risk, cost, or required capability. |
| Model Score | — | A model’s score on a benchmark; for agents it can be strongly influenced by harness, tools, context, and compute. |
| Module Boundary | — | Defined boundary of a module specifying which internals remain hidden and through which interfaces other parts may access it. |
| MoE | Mixture of Experts | Model architecture with multiple expert subnetworks, only a subset of which is activated for each processing step. |
| Monorepo | — | Repository in which multiple applications, libraries, or services are versioned and managed together. |
| Multi-Agent System | — | System in which multiple agents coordinate on subtasks or a shared goal. |
| Multimodal | — | Capability of a model or system to process or generate multiple modalities such as text, images, audio, or video. |
| Noise | — | Unnecessary, irrelevant, or low-quality output that obscures the useful information. |
| Non-Determinism | — | Property that identical or very similar inputs do not necessarily produce exactly the same solution path or output. |
| Open Source | — | Software whose source code is available for use and modification under an appropriate license; in AI this is not automatically the same as open weights. |
| Open Weights | — | Models whose learned weights are available; this does not imply that training data, training code, or the full pipeline are open. |
| OpEx | Operating Expenditure | Ongoing operating expenditure, such as API usage, electricity, hosting, or administration. |
| Output Tokens | — | Tokens generated by a model during a request. |
| Paradigm Drift | — | Gradual deviation from an originally chosen architecture or development paradigm toward competing patterns. |
| Parameters | — | Learned numerical values of a model that help determine its behavior. |
| Pass@1 | — | Benchmark metric indicating whether the first generated solution attempt is successful. |
| Pass@k | — | Benchmark metric for the probability that at least one successful solution exists among k generated attempts. |
| Path Dependency | — | Property that early decisions influence the later available solution path and context. |
| Personal Data | — | Information relating to an identified or identifiable natural person. |
| Post-Training | — | Training and adaptation phases after base pre-training, for example for behavior, reasoning, safety, or task specialization. |
| Pre-Training | — | Initial training phase in which a model learns broad patterns and capabilities from large datasets. |
| Privacy by Design | — | Principle of incorporating privacy into system architecture and design from the outset rather than adding it later. |
| Probabilistic | — | Describes systems whose outputs are based on probability distributions; identical inputs therefore need not produce exactly identical outputs. |
| Progressive Disclosure | — | Principle of loading information or skills into context only when they become relevant to the current task. |
| Prompt | — | Input or instruction given to a model for a specific processing task. |
| Prompt Caching | — | Reuse of previously computed states for recurring parts of a prompt or context to reduce cost or latency. |
| Prompt Engineering | — | Design of instructions and inputs for models; in agentic systems increasingly intertwined with requirements and context engineering. |
| Prompt Injection | — | Attack or unwanted instruction in which content inside the context tries to steer a model toward actions contrary to the user’s or system’s actual intent. |
| Pseudonymization | — | Processing in which direct identifiers are replaced or separated; if re-identification remains possible, the data is still personal data. |
| Quantization | — | Reducing numerical precision of model values to lower memory use and compute requirements. |
| RAG | Retrieval-Augmented Generation | Technique in which external information is retrieved before or during generation and supplied as additional context. |
| Reasoning | — | Additional internal or explicit processing steps intended to solve more complex tasks systematically. |
| Reasoning Effort | — | Configuration controlling how much compute or reasoning effort a model should spend on a task. |
| Reasoning Model | — | Term for models optimized for multi-step problem solving and additional inference-time computation. |
| Reasoning Tokens | — | In some APIs, separately accounted tokens or computation steps used for internal reasoning and not necessarily fully visible as output text. |
| Red Teaming | — | Deliberate search for vulnerabilities, failure modes, or undesirable edge cases through adversarial testing. |
| Reinforcement Learning (RL) | Reinforcement Learning | Training approach in which behavior is optimized using feedback or reward signals. |
| Repository | — | Version-controlled collection of source code, configuration, tests, and other project artifacts. |
| Requirements | — | Functional and technical needs specifying what a system or change should do and which conditions it must satisfy. |
| Requirements Engineering | — | Systematic elicitation, clarification, documentation, and verification of requirements for a system or change. |
| Responsibility Drift | — | Gradual shift of responsibilities so code or components take on tasks that were originally meant to live elsewhere. |
| Responsibility Verification | — | Checking not only that a change works, but that it is located in the correct functional or technical responsibility. |
| Retrieval | — | Targeted discovery and provision of external or stored information for a current task. |
| Review | — | Assessment of a change by humans or other systems for correctness, quality, risks, and fit with the surrounding system. |
| Review Bottleneck | — | Bottleneck that arises when changes are produced faster than they can be meaningfully reviewed and accepted. |
| RLHF | Reinforcement Learning from Human Feedback | Reinforcement-learning approach that uses human preferences or evaluations as a signal to adapt model behavior. |
| ROI | Return on Investment | Ratio between the economic benefit of an investment and the cost required for it. |
| Sampling | — | Process of selecting a concrete next token from the possible tokens scored by the model. |
| Scaffold | — | Alternative term for the agent or evaluation structure built around a model; often used similarly to harness. |
| Scope | — | Defined extent of a task or change, including what is explicitly out of scope. |
| SCS | Self-contained System | Architecture approach in which functionally sliced systems operate as independently as possible and expose only clearly defined integration points. |
| Semantic Search | — | Search based on semantic similarity rather than only identical words, often using embeddings. |
| Separation of Concerns | — | Principle of deliberately separating different responsibilities and problem types. |
| SLM | Small Language Model | Loose umbrella term for relatively small language models, often optimized for lower cost, local execution, or specialized tasks. |
| Solution Space | — | Set of fundamentally possible solution paths for a problem; requirements and constraints can narrow it. |
| Specification | — | As concrete as possible a description of desired behavior, a change, or a system. |
| Static Analysis | — | Analysis of code without executing it, for example for type errors, lint rules, or architecture violations. |
| Stop Condition | — | Predefined condition at which an agent stops autonomous work and requires a question or human decision. |
| SWE | Software Engineering | Discipline of systematically designing, developing, verifying, operating, and evolving software. |
| SWE-bench | Software Engineering Benchmark | Benchmark family using real GitHub issues and repository changes to evaluate coding models and agents. |
| SWE-bench Pro | — | More difficult SWE-bench variant with a broader repository and task mix and stronger focus on realistic agentic software work. |
| SWE-bench Verified | — | Human-reviewed subset of SWE-bench intended to reduce problematic or ambiguous tasks. |
| Synthetic Data | — | Artificially generated data that imitates or supplements real data and can be used for training, testing, or privacy purposes. |
| System Prompt | — | High-level instructions defining a model’s behavior, role, or boundaries for a session or application. |
| System Score | — | Score of the complete evaluated system consisting of model, harness, tools, context, and other runtime conditions. |
| TDD | Test-Driven Development | Development approach in which tests are written before, or closely before, implementation and actively shape the design. |
| Technical Debt | — | Future extra effort caused by short-term technical decisions, missing maintenance, or deliberately deferred quality work. |
| Temperature | — | Sampling parameter influencing how strongly more likely token options are favored over less likely ones. |
| Test-Time Compute | — | Alternative term for additional compute used while operating a model; largely related to inference-time compute. |
| Token | — | Processing unit of a language model; a token can represent a word, part of a word, a character, or another text sequence. |
| Token Budget | — | Maximum or planned number of tokens for context, generation, or an agent run. |
| Tokenizer | — | Component that converts text into token IDs processed by a language model. |
| Tool | — | External capability a model or agent can use, such as file access, search, shell, browser, or an API. |
| Tool Calling | — | Mechanism by which a model can trigger structured actions through external tools. |
| Top-K | — | Sampling method that considers only the k most likely next-token candidates for selection. |
| Top-P | Nucleus Sampling | Sampling method that considers the smallest set of likely token candidates whose cumulative probability reaches at least p. |
| Total Parameters | — | Total number of parameters in a model, regardless of whether all of them are active at every computation step. |
| Training | — | Process of adjusting model parameters using data and optimization objectives. |
| Trajectory | — | Recorded sequence of an agent’s observations, model steps, tool calls, actions, and intermediate states. |
| Transformer | — | Neural-network architecture based on attention that has been central to the development of modern LLMs. |
| Trust Boundary | — | Boundary between areas with different trust or protection levels whose crossing should be deliberately controlled. Explored in depth in Article 09. |
| Unit Test | — | Test of a small, ideally isolated unit of software. |
| Validation | — | Checking whether the right problem is being solved or the intended functional outcome is met; in practice often not sharply separated from verification. |
| Variable Cost | — | Cost that increases with usage or production volume, such as API or token costs. |
| Vector Database | — | Database that stores vector representations such as embeddings and supports similarity search. |
| Verification | — | Assessment of what reliable evidence exists that a change or claim is correct and acceptable. |
| Verification Debt | — | Deferred or missing verification work that creates uncertainty and additional checking cost later. Explored in depth in Article 12. |
| Verification Diversity | — | Combination of different verification methods so that not all checks share the same assumptions and failure classes. Explored in depth in Article 12. |
| Verification Surface | — | The complete set of aspects of a change that must be checked before it can be responsibly accepted. Explored in depth in Article 12. |
| Vibe Coding | — | Informal development style in which software is created primarily through natural language and AI-generated code; in the narrow sense with little direct code review. |
| VLM | Vision-Language Model | Model that processes visual information and language together; the term is increasingly used for multimodal systems. |
| VRAM | Video Random Access Memory | Memory on a GPU; for local inference it is often a major limiting factor for model size and context. |
| Wall Clock | — | Actual elapsed time from the start to the end of a process, regardless of how much of it is active human work. |
| Weights | — | Learned numerical values of a neural network; in everyday LLM usage often nearly synonymous with model parameters. |
| Workflow Lock-in | — | Increasing switching costs when processes, tools, data, and agent infrastructure become tightly coupled to a specific provider or workflow. |
| World Model | — | Internal or explicit representation of how an environment works and how actions can change its state. |
Last updated: September 2026. The glossary describes these terms as they are used in this series and in the current technical discourse. For non-standardized terms, the short explanation is intentionally a practical interpretation rather than a normative definition.