{"slug": "ai-agents-should-think-in-operations-not-commands", "title": "AI Agents Should Think in Operations, Not Commands", "summary": "Andrii Tkachuk argues that AI agents should reason in terms of operations rather than commands, drawing a parallel to how engineering teams moved from raw SQL to higher-level abstractions. He contends that exposing models to implementation details like CLI commands or MCP tool catalogs forces them to reason about syntax instead of intent, and that operations provide a stable interface independent of underlying execution paths.", "body_md": "Ten years ago, engineering teams stopped writing raw SQL scattered across the codebase and started building repositories, services, and domain layers instead. Not because SQL was bad — SQL was fine. Because SQL was the wrong level of abstraction for business logic to live at.\n\nThat playbook is starting to repeat itself, one layer up the stack.\n\nIf this piece gives you something practical you can take into your own system:\n\n👏 **Leave 50 claps (yes, you can!)** — Medium’s algorithm favors this, increasing visibility to others who then discover the article.\n\n🔔 **Follow me** on [Medium](https://medium.com/@andrii.tkachuk7) and [LinkedIn](https://www.linkedin.com/in/andrii-tkachuk7/) for more deep dives into agentic systems, LLM architecture, and production-grade AI engineering.\n\nA checkout service shouldn’t need to know whether the discount table has an index on user_id. It should just call applyDiscount(order).\n\nI think AI agent architecture is about to go through exactly the same transition, and most of the industry hasn’t noticed yet.\n\nBefore going further, it’s worth looking at how agents actually execute work today.\n\nSome teams expose hundreds of MCP tools. Others give the model access to a sandbox where it can execute shell commands directly. Some wrap internal SDKs. Others expose Python or custom runtimes. On the surface, these architectures look completely different.\n\nThey aren’t.\n\nThey’re all trying to answer exactly the same question:\n\nHow does the model turn intent into execution?\n\nThe only real difference is where the execution logic lives.\n\nTeams building MCP servers end up writing authorization policies around tools. Teams building sandboxed runtimes write authorization policies around shell commands. Teams exposing SDKs build the same policies around function calls.\n\nDifferent interfaces.\n\nThe same architectural problem.\n\nWatching different teams solve the same problem over and over again — just on different execution surfaces — is what led me to the idea behind this article.\n\nWe’ve spent the last year optimizing execution layers. I think it’s time we started optimizing the reasoning layer instead.\n\nRight now, the default way to connect an agent to a system is to teach the model the implementation details of that system directly — either as a giant MCP tool catalog (create_ec2, stop_ec2, list_roles, three hundred more) or, increasingly, as raw CLI commands (kubectl get pods, aws ec2 describe-instances --filters ...). Either way, the model ends up reasoning about *syntax* — which flag, which endpoint, which tool name — instead of reasoning about *what it's actually trying to do*.\n\nThat’s the wrong layer. The model should think: **“restart this deployment.”** Not: **“run ****kubectl rollout restart deployment/api.\"** Everything below that sentence — which tool, which API, which flag — is an implementation detail, and implementation details shouldn't be exposed to the reasoning layer at all.\n\nThis distinction is the actual point of this article, so it’s worth being precise about it.\n\nA **command** is tied to one specific execution path:\n\n```\nkubectl logs api-7d9f\n```\n\nAn **operation** is tied to intent, independent of how it gets carried out:\n\n```\nInvestigate failing pod\naws s3 cp backup/ s3://bucket/  →  Backup deployment artifactsgh pr list                      →  Review open pull requests\n```\n\nIf your agent reasons in commands, every change to your infrastructure is a change the model needs to relearn. Swap kubectl for a Kubernetes SDK, or migrate from the AWS CLI to boto3, and every prompt, every allowlist, every piece of few-shot guidance built around the old syntax needs to be redone.\n\nIf your agent reasons in operations, none of that matters. “Restart Deployment” stays “Restart Deployment” whether it’s implemented with kubectl, an SDK call, a REST request, or something that doesn't exist yet. The operation is stable. The execution path underneath it is disposable.\n\nI also think this is the direction the industry is naturally moving toward.\n\nNot because Skills are replacing anything, but because they’re the only abstraction that continues to scale. Twenty operations fit comfortably in a prompt. Two hundred become expensive. Two thousand become impossible. At that point, the model can’t reason about implementations anymore — it has to reason about operations, while the execution layer takes care of everything below.\n\nThat gives you three distinct layers instead of one flat one:\n\nAnd the full path from a user’s request to an actual system call looks like this:\n\nThe model never touches the bottom row. It shouldn’t have to.\n\nAt this point, it’s worth making one thing absolutely clear.\n\nThis isn’t an argument against MCP.\n\nIt isn’t an argument for replacing Skills with CLI, or Code Mode with MCP.\n\nIf anything, it’s the opposite.\n\nWhat we’re seeing today isn’t one architecture replacing another. It’s several independent ideas gradually converging toward the same architectural model.\n\nMCP standardizes integration.\n\nSkills capture reusable operational knowledge.\n\nCode Mode and sandboxed runtimes provide flexible execution.\n\nMature CLIs offer production-ready execution providers.\n\nNone of these compete with each other.\n\nThey solve different problems at different layers of the stack.\n\nThe interesting question is no longer which one wins.\n\nIt’s how they fit together into a single architecture where reasoning, execution, integration, and policy become cleanly separated concerns.\n\nMCP standardizes integration. Skills capture operational knowledge. Code Mode executes. Together, they form a much stronger architecture than any one of them alone.\n\nThis is worth grounding in something concrete, because the idea is abstract until you see what it replaces.\n\nThe instinct for the last year has been: wrap every action in an MCP tool. create_issue, list_issue, merge_pr, run_workflow — a few hundred thin wrappers, one per action, for every system the agent touches.\n\nBut for systems with a mature CLI — gh, aws, kubectl, terraform, docker — that entire wrapper layer is redundant. These tools already ship a decade of engineering: auth, retries, pagination, structured JSON output, config management. If your agent can execute a sandboxed shell command (Code Mode, or any comparable runtime), it can drive GitHub, AWS, or Kubernetes directly, with no MCP server in between:\n\n```\nAgent → Code Mode → gh pr list / kubectl get pods / aws s3 cp → System\n```\n\nThe catch is that CLI syntax isn’t something a model should have to memorize on the fly — aws ec2 describe-instances --filters Name=tag:Project,Values=checkout --query '...' --output json is not something you want the model improvising. That's what **Skills** are for: a Skill is documentation, scoped to one recurring operation, that tells the model exactly what to run and how to read the result. The model doesn't learn AWS CLI syntax — the Skill already encoded it, once, reusably.\n\n```\nSkill → CLI → System\n```\n\nFor systems that don’t have a CLI at all — Salesforce, Greenhouse, an internal RAG pipeline, any product with only a REST or GraphQL surface — nothing above changes the calculus. MCP remains the right interface there, exactly as it always was. CLI doesn’t compete with MCP; it just removes MCP from the picture wherever a finished, general-purpose interface already exists underneath the agent.\n\nSo the actual question for any integration was never “MCP or CLI.” It’s: is there already a mature execution provider here, or do I need to build one? CLI is just the most common answer for infrastructure tooling. It’s an execution provider — not the architecture.\n\nHere’s the shape I’d actually build, for a team with a moderate number of operations — say twenty to thirty, which covers most real DevOps or platform agents today.\n\n**Skill list, always injected.** Don’t build a discover_skills(query) tool for this scale — that only pays for itself once you're at hundreds or thousands of operations, where even the names get expensive. At twenty operations, just inject the name and a one-line description of every Skill into the system prompt, every turn. Trivial cost, no round trip.\n\n**Progressive disclosure via one MCP tool.** Something like get_skill(name), returning the full instructions — which provider to use, how to parse the result, edge cases — only for the operation actually relevant to the current request. The model sees short descriptions for everything; it only pays context for the one or two it's using.\n\n**Execution via one or more MCP tools, scoped by system.** execute_kubernetes, execute_aws, execute_github — separate tools per system give you a clean boundary for per-user or per-role authorization. The important part is *what* they accept: not a raw command string, but a structured operation —\n\n```\n{  \"operation\": \"restart_deployment\",  \"target\": \"api\",  \"risk\": \"medium\"}\n```\n\n— so the policy check inside the tool evaluates the business action (“can this user restart this deployment”) rather than string-matching for delete inside a kubectl invocation. A policy built around operations survives a provider swap. A policy built around command syntax doesn't.\n\nMCP doesn’t disappear in this picture. It shrinks to exactly two jobs — disclosure and execution — and it becomes the layer that enforces policy, not the layer that enumerates every possible action a system can perform. It’s still the right interface for anything without a mature execution surface of its own. It’s just no longer the place where three hundred hand-written wrappers live.\n\nFor decades, software engineering has moved developers toward higher levels of abstraction. Assembly became C. C became languages with garbage collection. Raw SQL became repositories and domain services. Infrastructure became cloud platforms, and cloud platforms became serverless. Every one of those transitions had the same shape: push implementation detail further away from the layer where decisions get made.\n\nAI agent architecture is walking the same path, just faster. The fix was never going to be fewer tools. It’s fewer implementation details exposed to the model in the first place.\n\n*And that’s a wrap! If you’ve read this far, it probably means you found this article useful or insightful. If that’s the case, consider leaving a few claps or sharing it with your team, please. Thanks for reading! 🚀*\n\n[AI Agents Should Think in Operations, Not Commands](https://pub.towardsai.net/ai-agents-should-think-in-operations-not-commands-04c249a5837d) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/ai-agents-should-think-in-operations-not-commands", "canonical_source": "https://pub.towardsai.net/ai-agents-should-think-in-operations-not-commands-04c249a5837d?source=rss----98111c9905da---4", "published_at": "2026-08-04 15:39:52+00:00", "updated_at": "2026-08-04 16:22:22.413691+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents"], "entities": ["Andrii Tkachuk", "Medium", "LinkedIn", "MCP", "kubectl", "AWS CLI"], "alternates": {"html": "https://wpnews.pro/news/ai-agents-should-think-in-operations-not-commands", "markdown": "https://wpnews.pro/news/ai-agents-should-think-in-operations-not-commands.md", "text": "https://wpnews.pro/news/ai-agents-should-think-in-operations-not-commands.txt", "jsonld": "https://wpnews.pro/news/ai-agents-should-think-in-operations-not-commands.jsonld"}}