30 Core Agentic Engineering Concepts, Explained Simply
Published on 17.06.2026
The Agentic Engineering Vocabulary You Actually Need
TLDR: Agentic systems are not magic, they are the same handful of ideas rebranded repeatedly. This breakdown cuts through six layers of the stack, from what an agent fundamentally is to how you know what it actually did.
Summary: Let me tell you what I appreciate about a good mental model: it outlasts the tools. New frameworks ship constantly, each with its own vocabulary. One calls it a skill, another calls it a rule, a third calls it a plugin. Underneath, it's the same job. The article I want to talk about today organizes agentic engineering into six layers, and I think that framing is genuinely useful, so let's walk through it.
The foundation is simpler than the hype suggests. An agent is an LLM running in a loop with tool access. That loop is think, act (a tool call), observe the result, then repeat. That's it. Where things get interesting is state management. The context window is ephemeral, gone when the session ends. Anything you want to survive needs to land in files, a database, or some memory system. The article makes a point I agree with strongly: files are the right default for agent state. They're diffable, versionable, and debuggable. And if you're running parallel agents that might write to the same file, git worktrees solve that race condition cleanly by giving each agent its own working directory against a shared repository.
Configuration shapes behavior before a single line of code runs. System prompts are set at the harness level. Project-level config files like CLAUDE.md or AGENTS.md add rules specific to your codebase. The guidance here is worth repeating: keep those files short, under a hundred lines, specific, and treat them like code rather than documentation. There's also a genuinely interesting data point about skills files. A study called SkillsBench showed that Claude Haiku with human-curated skills outperformed Claude Opus without them. A smaller model with better scaffolding beat a larger model flying blind. That result should inform how you think about where to invest your configuration effort.
The capability layer covers what agents can actually reach for. MCP has become the standard interface for connecting agents to external tools, and deferred loading matters more than you'd think, a fully loaded MCP server costs around 5,500 tokens whereas a deferred one runs about 607. Multiply that across sessions and it adds up. The observability layer is where I think most teams are underinvested. Tracing in agentic systems should produce a step-by-step tree of tool calls with timing, inputs, outputs, and model reasoning. A flat log is not enough. Replay capability, where you feed the same inputs back and get the same outputs, is what makes debugging tractable rather than a guessing game.
Guardrails deserve serious attention. Sandboxing with tools like bwrap on Linux or Apple Sandbox on macOS can restrict what agents can read and write. Deny lists for tool calls are not optional: block reads of .env files, block force-pushes to main, block curl-piped-to-shell patterns. Pre-commit hooks that include structural linting via AST-grep catch LLM-specific anti-patterns that regular linters miss, things like mutable defaults and swallowed exceptions. Supply chain risk is real too. Treat config files as code, and never auto-load MCP servers from repositories you just cloned. An MCP server runs with agent-level permissions, which is a lot of trust to hand to unknown code.
Key takeaways:
- The agent loop is think, act, observe, repeat. Every agentic framework is a variation on this, and understanding the loop matters more than knowing any specific tool.
- Files are the right default for agent state: diffable, versionable, and recoverable. Git worktrees solve write conflicts when running agents in parallel.
- A smaller model with well-curated skills files can outperform a larger model without them, so invest in your configuration layer before upgrading your model.
- Deferred MCP loading cuts token overhead dramatically, from roughly 5,500 tokens to 607 per server.
- Observability means tree-structured traces, not flat logs, and replay capability is what makes debugging agents possible rather than painful.
- Deny lists for tool calls are non-negotiable: protect .env, block destructive git commands, and never trust auto-loaded MCP servers from cloned repos.
Why do I care: As a frontend architect, the part of this that hits closest to home is the configuration layer and the guardrails. I've watched teams spin up agentic workflows and skip both, and what you get is an agent that confidently uses a deprecated API because nobody wired up live documentation, and that occasionally does something destructive because nobody set a deny list. The SkillsBench result is actionable: before you reach for a bigger model, write better skills files. And the supply chain angle matters a lot in frontend work where we clone repos constantly. Treating MCP config files as code, with review and version control, is the right call, full stop.