{"slug": "agentic-ai-vocabulary-for-devops-12-terms-you-already-operate-under-another-name", "title": "Agentic AI Vocabulary for DevOps: 12 Terms You Already Operate Under Another Name", "summary": "A developer argues that most agentic AI vocabulary maps directly to concepts DevOps teams already use, such as agent loops being reconciliation loops and guardrails being admission control. The post provides a translation table and highlights where the analogies break, noting that agents are non-deterministic unlike traditional controllers.", "body_md": "There is a genre of infographic doing the rounds at the moment: twelve must-know agentic AI terms, a leader's guide to the language of agents. They are aimed at executives, and for that audience they are fine. The trouble is what happens next, which is that the executive brings the vocabulary to the platform team and asks how soon an agent can have production access.\n\nIf you run infrastructure, the honest reading of that list is not that twelve new things have arrived. It is that ten of them are concepts you already operate, under names you already use, and two of them are genuinely new and are the ones that will hurt you. An agent loop is a reconciliation loop. Guardrails are admission control. Sandboxing is what you have been doing to untrusted workloads since cgroups.\n\nThis post is the translation table, and then the part the infographics leave out: exactly where each analogy breaks. The breaks are the interesting bit. If an agent were just a controller, you would already know how to run one.\n\nStart here. This is the whole argument in one screen.\n\n| The agentic term | What you already run | Where it lives in your stack |\n|---|---|---|\n| Agent loop | A reconciliation loop | Kubernetes controllers, Argo CD sync |\n| Tool use | An API client with credentials | IAM roles, service accounts, tokens |\n| MCP | A plugin interface for tools | Like CSI or CNI, but for capabilities |\n| Sandboxing | Workload isolation | Containers, seccomp, gVisor, network policy |\n| Guardrails | Policy enforcement | OPA, Kyverno, admission webhooks, RBAC |\n| Grounding | Reading real state before acting | Metrics, logs, traces, the actual API |\n| Human-in-the-loop | A change approval gate | PR review, manual approval on a pipeline |\n| Orchestrator | A scheduler and work queue | Kubernetes scheduler, Airflow, Temporal |\n| Subagent | A worker process on a narrow job | A job, a sidecar, a lambda |\n| Multi-agent | A distributed system | Every distributed system you have debugged |\n| Memory | Persistent state | The thing that turns a Deployment into a StatefulSet |\n| Context window | A resource limit | Like a memory limit, and it evicts the same way |\n\nTen of those twelve are re-labellings. That is not a criticism of the vocabulary. It is the reason infrastructure people are unusually well equipped to reason about agents, and unusually badly served by explainers pitched at executives.\n\nNow the parts worth going into properly.\n\nEvery agentic explainer draws the same cycle: perceive, plan, act, observe, repeat. If you have written a Kubernetes controller, you have drawn that cycle yourself and called it something else.\n\n**The same loop, twice**\n\nThe shape is identical. A controller watches the API server, compares actual state to the spec, acts to close the gap, and observes the result. An agent reads its context, plans a step, calls a tool, and observes the output. If you want the mechanics of the first one in detail, [Write a Simple Kubernetes Operator](https://devops-daily.com/posts/write-simple-kubernetes-operator) builds one from scratch, and everything in it transfers. For the loop from the agent side, including why the thing that judges the work has to be separate from the thing that does it, see [Stop Prompting, Start Looping](https://devops-daily.com/posts/stop-prompting-start-looping).\n\nHere is the difference, and it is not a small one. **A controller is deterministic and an agent is not.**\n\nGive a controller the same cluster state twice and it produces the same action twice. That single property is load-bearing for almost everything you know about operating control loops. It is why you can test a controller, why you can reason about a stuck reconcile, why a rerun is a diagnostic tool rather than a gamble, and why \"it did something different this time\" is a bug report rather than expected behaviour.\n\nAn agent given identical inputs may take a different path. Not usually a wildly different one, but different enough that the following all stop being reliable:\n\nEverything else in this post follows from that one property. The infrastructure analogies hold right up until they depend on determinism, and then they stop.\n\nThis is the term that causes the most confused conversation, and it is the one with the cleanest answer.\n\nAn agent cannot do anything except through a tool. The model produces text. Text becomes an action only when something on your side takes that text and calls an API. So the question \"what can this agent do to my infrastructure\" has an exact answer, and it is not a question about the model at all:\n\nAn agent's blast radius is the union of the permissions held by every tool you gave it.\n\nThat is an IAM audit, and you already know how to do one. If the agent has a tool that calls `kubectl`\n\nwith a kubeconfig bound to `cluster-admin`\n\n, then the agent is `cluster-admin`\n\n. No amount of instruction in a system prompt changes that, in the same way that telling an intern to be careful is not an access control mechanism.\n\nThe practical consequence is that the safety conversation should start with credentials, not with the model:\n\n```\n# The only question that actually bounds what an agent can do.\nkubectl auth can-i --list --as=system:serviceaccount:agents:incident-responder\n```\n\nIf that output frightens you, the model choice is irrelevant. If it is tightly scoped, then a bad plan produces a rejected API call rather than an outage.\n\nTipThe useful mental model is that an agent is a user, not a service. Give it its own identity, scope it to exactly what it needs, and make its actions attributable in the audit log. An agent sharing your platform team's service account is the same mistake as a CI pipeline sharing a human's credentials, and it fails in the same way at the same time: during the incident review.\n\nModel Context Protocol is the term most likely to be presented as more novel than it is. It is a protocol for exposing tools, data and prompts to an agent through a consistent interface, so a capability written once can be used by any client that speaks it.\n\nStructurally, that is the same idea as CSI for storage or CNI for networking: a stable interface so that vendors write one implementation instead of one per consumer. We have written about [when to reach for MCP versus a plain CLI](https://devops-daily.com/posts/cli-vs-mcp-when-to-use-each), and the short version is that the answer is usually both.\n\nWhat matters operationally is that a plugin interface is a supply chain. Each MCP server is code, from someone, running with access to whatever you gave it. That is the same trust question as a Helm chart, a Terraform provider or a GitHub Action, with the added wrinkle that an MCP server's tool descriptions are themselves text that reaches the model. Our writeup of the [MCP design flaw and the RCE it enabled](https://devops-daily.com/posts/mcp-design-flaw-rce-supply-chain-risk) covers where that went wrong in practice.\n\nTreat MCP servers the way you treat any third-party admission webhook or CSI driver: pin versions, read what you install, and do not run one you cannot attribute.\n\n\"Guardrails\" in most explainers means rules and policies that limit unsafe actions. Written down like that, it sounds like something you configure inside the AI product.\n\nThe version that survives contact with production is the one you already run: **policy enforced at the boundary the agent cannot reach past.** An admission webhook does not ask the workload to behave. It rejects the request. RBAC does not trust the client's intent. It evaluates the call.\n\nThat distinction is the whole game. There are two places to put a guardrail:\n\nPrompt-level rules are worth having, in the same way that documentation and linting are worth having. They are not controls. If a guardrail matters, it belongs in RBAC, in OPA or Kyverno, in a network policy, or in the absence of a credential.\n\nWarningThe failure mode to watch for is a guardrail that is described in a system prompt and nowhere else, then presented in a design review as a control. Ask where it is enforced. If the answer is \"we told it not to\", it is documentation.\n\nGrounding means connecting the model's output to real data instead of what it inferred. For infrastructure work, \"real data\" is your telemetry: metrics, logs, traces, and the live state of the API.\n\nThe upside is genuine, and it is the part of AI operations that is actually working today. An agent that reads real metrics before proposing a cause is doing what a good on-call engineer does. Our assessment of [what AI SRE agents fix and break](https://devops-daily.com/posts/ai-sre-agents-what-they-fix-and-break) found the investigation half to be the solid half, and grounding is why.\n\nThe part the infographic cannot fit in a box is that grounding makes your telemetry an input to a decision-making system. Logs are attacker-influenced data. A log line is written by a request, and a request can be crafted. Once an agent reads logs and can act on them, a string in a log becomes a potential instruction.\n\nThis is prompt injection, and for infrastructure people the clearest framing is that **it is privilege escalation with a content payload**. The classic escalation path is untrusted input reaching a privileged interpreter. Here the interpreter is the model and the input is anything it reads: log lines, ticket text, commit messages, alert annotations, HTTP user agents.\n\nThe mitigations are the ones you would expect from that framing, and none of them are AI-specific:\n\nHuman review and approval before sensitive actions. You run this already: pull request review, a manual approval step on a deploy pipeline, a break-glass procedure with a second pair of eyes.\n\nWhich means you already know how it fails. **Approval gates decay into rubber stamps in direct proportion to how often they fire and how little context they carry.** A reviewer facing the fortieth \"agent wants to restart a pod\" prompt of the day is not reviewing, they are clicking.\n\nThe lesson from change management transfers exactly:\n\n`replicas: 3 -> 30`\n\nis.If your agent's approval prompt does not contain enough information to make an informed no, it is theatre with an audit trail.\n\nThe last group is presented as the frontier: a manager layer that assigns tasks, specialised workers with narrow jobs, several agents collaborating on a workflow.\n\nThat is a distributed system. Specifically it is a scheduler, a set of workers, and shared state, which is the architecture of nearly everything you already operate.\n\nSo the fun part is that you can predict the failure modes without having run one:\n\nThe design questions are the ones you would ask of any worker pool. What happens when a worker dies halfway? Is the unit of work idempotent? Where is the shared state, and what happens when two workers write it? Our [on-call agent built on Mastra](https://dev.to/devopsdaily/we-built-an-on-call-agent-in-mastra-where-it-won-and-where-it-would-not-obi) was killed with SIGKILL at the worst possible moment specifically to answer those, which is the right instinct to bring.\n\nThese two get flattened together in most explainers and they are quite different.\n\n**Memory** is persistence. An agent with memory carries information between runs, which means it has state, which means all your stateful-workload instincts apply. Where does it live, what happens when it is lost, who can read it, and is it in your backup. The [Deployment versus StatefulSet](https://devops-daily.com/posts/kubernetes-deployments-vs-statefulsets) distinction is exactly the right lens: an agent with memory is not a stateless replica you can reschedule freely, and if that memory holds anything derived from production data, it inherits the same handling requirements as the data itself.\n\n**Context window** is a resource limit. It is the amount the model can consider at once, and the operational behaviour when you exceed it is familiar: things get evicted. Early context drops out, and the agent forgets a constraint it was given at the start, in exactly the way a process forgets nothing gracefully when it hits a memory limit.\n\nThe practical consequence is that **an instruction given early in a long-running agent session is not a durable constraint.** It is a value in a buffer that is being evicted. This is another reason enforcement belongs outside the model: a rule in RBAC is still there on hour six, and a rule in the opening prompt may not be.\n\nStrip out the re-labelled concepts and two things remain that have no clean equivalent in the infrastructure you already run.\n\n**Nondeterminism in the control loop.** Every operational practice you have for control loops assumes reproducibility. Testing, staged rollout, incident reproduction, \"revert and see if it stops\" all lean on it. An agent breaks that assumption, and the honest response is not to pretend otherwise but to move the guarantees somewhere deterministic: enforce in policy, verify with checks the agent cannot influence, and treat its output as a proposal until something deterministic has validated it.\n\n**Runtime cost as a variable.** A controller's cost is roughly fixed and predictable. An agent's cost is a function of how much it reads and how many times it loops, both of which vary per run and can be influenced by the input. A pathological case is not just slow, it is expensive, and there is no equivalent of a `resources.limits`\n\nblock that the loop cannot argue with. Budget caps and iteration limits are not optimisations here, they are the same category of control as a memory limit.\n\nNone of this needs a policy document. It needs five answers.\n\n`can-i --list`\n\nfor its identity. That output is the blast radius, and everything else is commentary.Answer those and the model choice becomes what it should have been all along: an implementation detail you can change later.\n\nThe vocabulary is not the hard part, and it is mostly not new. An agent loop is a reconciliation loop, tool use is an IAM boundary, guardrails are admission control, grounding is observability, human-in-the-loop is a change gate, and orchestrators with subagents are a worker pool with all the partial-failure problems that implies.\n\nReading it that way does two useful things. It tells you that your existing instincts mostly transfer, which is more than most explainers will tell you. And it isolates the two places where they do not: a control loop that is not reproducible, and a running cost that is not bounded.\n\nThose two are where the work is. Everything else you have been doing for years.\n\n**Is an agent really just a control loop?**\n\nStructurally, yes, and the comparison holds until it depends on determinism. A controller given the same state acts the same way; an agent may not. Testing, reproduction and rollback all rest on that property, so they all need rethinking.\n\n**What is the single most useful control to add first?**\n\nA scoped identity. Most agent risk is credential risk, and giving the agent its own least-privilege service account bounds the damage from every other mistake, including a successful prompt injection.\n\n**Are prompt-level guardrails worthless then?**\n\nNot worthless, but they belong in the same category as documentation and linting: they improve the common case and they do not stop the adversarial one. Anything that must not happen belongs in RBAC, policy or the absence of a credential.\n\n**How is prompt injection different from ordinary injection?**\n\nMostly in the payload. It is untrusted input reaching a privileged interpreter, which is a shape you already defend against. The awkward part is that the interpreter has no reliable syntax boundary between instructions and data, so escaping and parameterisation, the usual fixes, are not available.\n\n**Do I need a multi-agent setup?**\n\nUsually not at first. It is a distributed system, and it brings coordination overhead, partial-failure handling and token cost. Start with one agent and narrow tools, and split only when a single loop is demonstrably the bottleneck.\n\n**Where does MCP fit if we already have CLIs?**\n\nMCP standardises capability exposure across clients, and a CLI is often cheaper in tokens and already known to the model. [Our comparison](https://devops-daily.com/posts/cli-vs-mcp-when-to-use-each) goes through the tradeoff properly; in practice most teams end up running both.\n\n*Originally published at devops-daily.com.*", "url": "https://wpnews.pro/news/agentic-ai-vocabulary-for-devops-12-terms-you-already-operate-under-another-name", "canonical_source": "https://dev.to/devopsdaily/agentic-ai-vocabulary-for-devops-12-terms-you-already-operate-under-another-name-4la7", "published_at": "2026-08-19 14:00:00+00:00", "updated_at": "2026-08-19 14:12:22.009150+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "mlops"], "entities": ["Kubernetes", "Argo CD", "OPA", "Kyverno", "Airflow", "Temporal", "gVisor"], "alternates": {"html": "https://wpnews.pro/news/agentic-ai-vocabulary-for-devops-12-terms-you-already-operate-under-another-name", "markdown": "https://wpnews.pro/news/agentic-ai-vocabulary-for-devops-12-terms-you-already-operate-under-another-name.md", "text": "https://wpnews.pro/news/agentic-ai-vocabulary-for-devops-12-terms-you-already-operate-under-another-name.txt", "jsonld": "https://wpnews.pro/news/agentic-ai-vocabulary-for-devops-12-terms-you-already-operate-under-another-name.jsonld"}}