<!-- The AI Transformation Field Guide, v2026.09.1, section: The 25 Concepts I Would Learn First, https://erikcaldwell.com/field-guide/twenty-five-concepts-i-would-learn-first/ -->

If time only permits 25 items from this entire document, this is the ranked list. It cuts across domains deliberately: the highest-leverage concepts for an executive are not evenly distributed by department, and security, architecture, and measurement concepts outrank several strategy concepts because getting them wrong is harder to reverse.

**1. The agent loop.** An AI agent perceives its environment, reasons about what to do, takes an action through a tool, and observes the result: repeating until the task is done or it stops itself. *Ranks #1 because every other agent concept in this document (memory, autonomy levels, sandboxing, cost) is a modification of this one loop, and most confusion about "what agents can and can't do" comes from not having this model in your head.*

**2. Context engineering, not prompt engineering.** The discipline of designing the whole system around a model (what data it retrieves, what tools it can call, what history it carries) because a model's output quality is dominated by what surrounds it, not by prompt wording. *Ranks #2 because it reframes nearly every AI initiative from "which prompt is best" to "what system did we build," which is the correct frame for architecture and investment decisions.*

**3. Model Context Protocol (MCP).** An open standard, now governed by the Linux Foundation's Agentic AI Foundation, for connecting AI models to external tools and data sources in a consistent way. *Ranks #3 because it has become the default integration layer across the industry in under two years: you will encounter it in nearly every vendor conversation, and it carries its own security surface you need to know exists.*

**4. The software engineering continuum.** Autocomplete → coding assistant → coding agent → agent-directed engineering → autonomous software factory: a progression of how much of the engineering task the AI owns versus the human. *Ranks #4 because it's the single frame that tells you where your organization actually sits today versus where a vendor pitch is implying you should be.*

**5. Human approval and autonomy levels.** The explicit, documented decision of how much an agent is allowed to do without a human checking first: from suggest-only to fully autonomous. *Ranks #5 because it is the primary governance lever you actually control, and most AI incidents trace back to an autonomy level nobody deliberately chose.*

**6. Retrieval-Augmented Generation (RAG).** Giving a model access to your organization's own documents and data at query time, rather than relying only on what it learned in training. *Ranks #6 because it's the mechanism behind almost every "AI that knows our business" product you'll evaluate, and its failure modes (stale data, wrong permissions, bad retrieval) are where most enterprise AI complaints originate.*

**7. Permissions-aware retrieval.** Ensuring an AI system only surfaces information the requesting user was already allowed to see: access control has to be enforced at retrieval time, not assumed. *Ranks #7 because getting this wrong is a data breach with an AI-shaped excuse, and it's the security gap least visible in a vendor demo.*

**8. Non-human / workload identity.** Giving each AI agent its own verifiable identity (distinct from a shared service account or a human's credentials) so its actions can be authorized and audited individually. *Ranks #8 because "which agent did this" is unanswerable without it, and it's the prerequisite for nearly every other security and governance control in this document.*

**9. Least privilege and audit attribution for agents.** Limiting what an agent can do to the minimum required, with hard transaction limits, and keeping a record of what it did and why. *Ranks #9 because this is where "who authorized this AI to take this action, with this data, at this time" gets answered, or doesn't, when an incident happens.*

**10. Prompt injection.** An attack where instructions hidden in content an AI processes (a document, an email, a webpage) hijack its behavior: direct if the user does it, indirect if a third party embeds it in data the AI later reads. *Ranks #10 because it is the most common and least solved security problem in production LLM systems today, and no vendor has "fixed" it: only mitigated it.*

**11. Excessive agency / goal hijacking.** An agent given too much autonomy or too many tool permissions pursues its interpretation of a goal in ways nobody intended or authorized. *Ranks #11 because it's the agent-specific failure mode that traditional application security doesn't have a playbook for.*

**12. AI evals and golden datasets.** A curated, versioned set of test cases with known-correct answers, run automatically to check whether an AI system's outputs are still good before and after every change. *Ranks #12 because without this, you have no way to know if a model update, a prompt change, or a new feature made things better or worse: you're flying on vibes.*

**13. Hallucination and groundedness.** A model can produce fluent, confident, and completely wrong output; groundedness measures whether an answer is actually supported by the retrieved source material. *Ranks #13 because "it sounded right" is not a quality bar, and every AI-native product decision about citations, confidence, and human review traces back to this problem.*

**14. Token economics and cost-per-outcome.** Thinking about AI cost in terms of tokens processed is the wrong unit; the right unit is cost per successfully completed business outcome, which can vary by orders of magnitude across implementations of the "same" feature. *Ranks #14 because it's the difference between a FinOps conversation that controls spend and one that just watches a number go up.*

**15. AI gateway / model gateway.** A centralized layer that all AI traffic passes through, enforcing authentication, rate limits, data-loss prevention, content filtering, and cost controls consistently, regardless of which team or model is behind it. *Ranks #15 because it's the architectural choice that determines whether your governance policies are enforced everywhere or only in the systems someone remembered to configure.*

**16. Multi-model strategy and vendor dependency.** Deliberately architecting so you can swap or run multiple model providers, rather than hard-coding a dependency on one vendor's API, pricing, and roadmap. *Ranks #16 because model capability and pricing are both moving fast, and single-vendor lock-in compounds risk you can avoid with modest up-front design discipline.*

**17. Build vs. buy vs. configure.** The recurring decision, per use case, between building custom, buying a vendor product, or configuring a platform around your own data, and knowing that coding agents are shifting this calculus in ways that need scrutiny, not just enthusiasm. *Ranks #17 because it's the decision you'll be asked to make dozens of times, and getting the framework right once saves re-litigating it every time.*

**18. DORA's AI-era engineering metrics and the velocity/stability tension.** Research showing AI coding assistance can increase throughput while simultaneously straining delivery stability: the two don't automatically move together. *Ranks #18 because "engineers say they're faster" is not the same claim as "we ship more reliably," and conflating them is the most common measurement mistake in AI-assisted engineering.*

**19. Skill-segmented productivity gains.** Field research shows AI tools help less-experienced workers close skill gaps significantly more than it helps already-expert workers: productivity gains are not a flat percentage applied evenly across your workforce. *Ranks #19 because it changes how you should think about training investment, tool rollout sequencing, and what "average productivity lift" claims are actually hiding.*

**20. Vanity metrics vs. outcome metrics.** Seats provisioned, prompts sent, and "AI-assisted" tickets closed measure activity, not value; revenue enabled, cost reduced, and capacity released measure value. *Ranks #20 because nearly every AI dashboard you'll be shown defaults to the easy-to-measure activity metrics, and it's your job to insist on the harder outcome ones.*

**21. Agent memory and persistent state.** Unlike a single chatbot exchange, an agent that operates over hours or days needs a designed way to remember what it already tried, decided, or learned, and that memory can be poisoned or corrupted just like any other data store. *Ranks #21 because "it's just a chatbot" thinking badly underestimates the data-governance surface a persistent agent actually has.*

**22. The knowledge-worker maturity ladder.** Chat assistants → connected assistants → workflow automation → autonomous agents → autonomous business processes: a progression parallel to the software engineering continuum, for non-technical work. *Ranks #22 because it gives you the same "where do we actually sit" clarity for your knowledge-worker population that the SWE continuum gives you for engineering.*

**23. NIST AI Risk Management Framework (Govern-Map-Measure-Manage).** A voluntary, non-regulatory structure for identifying and managing AI risk across a system's lifecycle, increasingly treated as reference vocabulary by regulators and auditors even where it isn't mandatory. *Ranks #23 because it gives you a shared language with your legal, security, and audit functions that doesn't require waiting for binding regulation to be useful.*

**24. The EU AI Act.** Risk-tiered regulation (unacceptable, high-risk, limited, minimal) with a phased implementation timeline now extending into 2027-2028 for high-risk obligations: relevant even without EU operations because vendor compliance postures are converging toward it globally. *Ranks #24 because "we have no EU presence" is not the same as "this doesn't affect our vendor contracts and product roadmap."*

**25. Zero-trust for agents and continuous red teaming.** Treat every agent as potentially compromised and verify its actions continuously, rather than trusting it once it's inside your perimeter; test this assumption adversarially and on an ongoing basis, not just before launch. *Ranks #25 because agentic systems change behavior over time in ways a one-time security review can't catch, and this is the mindset shift that keeps governance from going stale.*
