Agentic AI Terms

Introduction

Agentic AI goes beyond chat: systems that perceive context, plan steps, use tools, remember state, and act toward goals—with optional human oversight. Whether you are building with Cursor, Claude, or an internal platform, these twelve terms show up in architecture docs, product specs, and team conversations.

This guide groups them the way practitioners think about production agents: what they need (foundations), how they run (reasoning), how you keep them safe (reliability), and how they scale (coordination).

1. MCP (Model Context Protocol)

An open standard that lets AI agents connect to tools, APIs, and data sources through a consistent interface lik

USB-C for agent integrations.

Why it matters: Without a common protocol, every tool needs a custom integration. MCP reduces glue code and makes agents portable across hosts (IDEs, chat apps, automation runners).

How it works (simplified):

1. An MCP server exposes resources (files, DB rows) and tools (search, deploy).
2. The host (e.g. Cursor) discovers capabilities and passes them to the model.
3. The model calls tools with structured arguments; the server returns results.

Example: Claude connects to GitHub via MCP to read repos, open issues, and suggest PRs.

Practical tips:

• Prefer least-privilege MCP servers in production (read-only where possible).
• Document which servers are enabled per environment (dev vs prod).
• Treat MCP tool schemas as part of your API contract—breaking changes affect agents.

Related terms: Tool Use, Guardrails

2. Memory (Short-term & Long-term)

How agents retain and retrieve information—either within a single session or across sessions via external stores.

• Type
• Scope
• Typical storage

Short-term

• Current session / thread
• Chat history, scratchpad
• Follow-up questions, multi-step tasks

Long-term

• Cross-session
• Vector DB, SQL, files
• User preferences, project context, past decisions

Example: An agent recalls your coding style and naming conventions from a vector database when opening a new task.

Practical tips:

• Separate facts (grounded, verifiable) from inferences (model guesses)—store accordingly.
• Use summarization or compaction so memory does not blow the context window.
• Add retention policies and PII review for anything persisted.

3. Context Window (Working Memory Limit)

The maximum amount of text (tokens) a model can read and reason over in one pass, its effective “working memory.”

Example: A larger context window lets an agent review an entire service’s codebase before proposing a refactor; a smaller one forces chunking and retrieval.

Practical tips:

• RAG (retrieval-augmented generation) exists largely because of window limits.
• Prioritize what goes in context: system rules → task → relevant files → history.
• Monitor token usage in logs; it predicts cost and failure modes (truncation).

4. Agent Loop (Perceive → Plan → Act → Observe)

The recurring cycle agents use: take in state, plan next steps, execute actions, then observe outcomes and adjust.

Example: Read a failing CI log → plan a fix → edit code and run tests → observe pass/fail → iterate.

Practical tips:

• Cap max iterations to avoid runaway loops and runaway cost.
• Log each loop step for debugging (“why did it delete that file?”).
• Clear stop conditions in the prompt: “stop when tests pass” or “stop after 3 attempts.”

5. Tool Use (Agent Capabilities)

The model’s ability to invoke external functions—APIs, browsers, shells, databases, search—not only generate text.

Example: An agent calls a weather API for travel planning, or runs grep in your repo to find usages before refactoring.

Practical tips:

• Design tools with narrow, explicit inputs and outputs.
• Return errors in a structured form the model can recover from.
• Version tools; agents break when signatures change silently.

6. Sandboxing (Safe Execution)

An isolated environment where agent-generated code or commands run without full access to the host machine or production systems.

Example: User scripts run in a container or restricted VM; only after review are changes merged to main.

Practical tips:

• Default-deny network and filesystem outside the workspace.
• Time-box executions; kill hung processes.
• Never run unsandboxed agent shell on production credentials.

7. Grounding (Reality Tethering)

Tying model outputs to verified external data—APIs, documents, databases—so answers are factual and traceable, not guessed.

Example: Stock quotes from a live market API with timestamp and source, not plausible-sounding numbers from training data.

Practical tips:

• Require citations or tool call IDs in outputs for high-stakes domains.
• Refresh stale data; show “as of” timestamps to users.
• When retrieval fails, say “I don’t know” instead of hallucinating.

8. Guardrails (Safety Layer)

Rules, policies, and technical controls that block harmful, unauthorized, or out-of-scope actions before or after the model acts.

Examples:

• Block rm -rf on production paths.
• Reject prompts that ask for secrets or PII exfiltration.
• Enforce “no deploy without passing security scan.”

Practical tips:

• Layer guardrails: prompt → tool allowlist → output filter → audit log.
• Test adversarial prompts regularly; models are creative bypassers.
• Align guardrails with compliance (SOC2, GDPR) requirements.

9. Human-in-the-Loop (Approval Gate)

A deliberate pause where a person must approve, edit, or reject an action before it takes effect—especially for irreversible or high-impact operations.

Example: Email drafts, payment transfers, production deploys, or customer-facing messages wait for human sign-off.

Practical tips:

• Define tiers: auto-approve low risk, require approval for medium/high.
• Show diffs and rationale, not just “Approve?” buttons.
• Measure time-to-approve; bottlenecks kill agent ROI.

10. Orchestrator (Agent Manager)

A top-level agent (or service) that decomposes goals into subtasks, assigns work, merges results, and handles failures.

Example: One orchestrator dispatches parallel workers: lint, test, security scan, then deployonly if all succeed.

Practical tips:

• Keep orchestrator prompts focused on delegation and synthesis, not doing every task itself.
• Use explicit task graphs or state machines for critical workflows.
• Centralize logging and correlation IDs across subtasks.

11. Subagent (Specialized Worker)

A focused agent with a narrow role inside a larger workflow research, summarization, code review, test generation.

Example: A summarizer subagent condenses 50 pages of research; a writer subagent produces the final brief from that summary.

Practical tips:

• Give subagents minimal context— only what they need (reduces cost and leakage).
• Standardize handoff format (JSON schema, markdown template).
• Avoid “subagent sprawl”; merge roles when latency or cost hurts.

12. Multi-Agent (Collaborative Intelligence)

Multiple specialized agents cooperating on a goal often with an orchestrator, shared memory, and defined protocols.

Example: Research agent gathers sources → writer drafts → fact-checker validates → editor polishes—coordinated by an orchestrator.

Practical tips:

• Define ownership: who resolves conflicts between agents?
• Watch for duplicate work and circular delegation.
• Start with 2–3 agents; add complexity only when metrics justify it.

A minimal production-minded agent stack often looks like this:

1. MCP + tools connect the model to your world.
2. Memory + context window decide what the model “sees.”
3. The agent loop drives perceive → plan → act → observe.
4. Sandboxing + guardrails + grounding keep actions safe and truthful.
5. Human-in-the-loop gates irreversible steps.
6. Orchestrator + subagents scale to bigger projects.Further reading

• Model Context Protocol — official MCP documentation