An AI agent can look impressive in a controlled demonstration. Give it a goal, connect a few tools and watch it assemble a plan. The hard questions begin when the same agent is allowed to read business data, make decisions, change records, send messages or trigger financial and operational processes.
At that point, the model is only one component. The production system also needs bounded authority, trusted context, predictable execution, identity, security controls, recovery, evaluation, monitoring and a named owner.
This field guide provides a working vocabulary for those decisions. It is not a list of fashionable terms. Each concept answers a production question that an architecture, risk or delivery team should be able to resolve.
If you would rather start with plain-language explanations and worked examples, read the companion piece, 22 production concepts for AI agents, in plain language. It takes the concepts that most introductions to agents leave out and explains each one with an everyday comparison and an example.
The CloudNala production model
CloudNala groups the 48 concepts into seven layers.
| Layer | The question it answers |
|---|---|
| 1. Purpose and authority | What is the agent trying to achieve, and what is it allowed to do? |
| 2. Reasoning and execution | How does it decide, plan and act? |
| 3. Context, knowledge and memory | What information can it use, retain and trust? |
| 4. Tools and interoperability | How does it connect to systems and other agents? |
| 5. Reliability and recovery | How does it behave when systems, models or actions fail? |
| 6. Security and human control | How are access, policy, data and high-impact actions protected? |
| 7. Quality and operations | How do we prove it works and keep it safe after launch? |
The first layer is deliberately purpose and authority. Starting with the model or orchestration framework encourages teams to build capability before deciding where that capability may be used.
1. Purpose and authority
1. Agent objective
The specific outcome the agent is expected to pursue. “Help the customer” is too vague. “Answer questions from the approved knowledge base and escalate account-specific requests” is testable and creates a boundary.
Related terms: goal, outcome, scope, success criteria.
2. AI agent
A software system that interprets an objective, maintains execution state, selects actions and uses permitted tools or services to pursue that objective within defined limits.
An agent is more than an LLM response. It has some ability to choose the next action and affect an environment.
Related terms: perceive, decide, act, observe.
3. Autonomy level
The degree of independent action permitted. This may range from recommendation only, through draft-and-approve, to bounded automatic execution. Autonomy should vary by task risk, not by how capable the model appears.
Related terms: assist, recommend, approve, execute.
4. Control boundary
The systems, data, users, actions and environments placed inside the agent’s permitted scope. The boundary should identify what the agent cannot access as clearly as what it can.
Related terms: scope, trust zone, environment, exclusion.
5. Policy
Machine-enforced and human-governed rules that determine which actions are permitted, denied or sent for approval. A policy should be enforced near the action or data boundary. A sentence in a system prompt is not a reliable security control on its own.
Related terms: allow, deny, condition, enforcement.
6. Risk tier
A classification based on the possible effect of an agent’s action. Reading a public FAQ and releasing a payment should not share the same controls. Risk tiers determine approval, identity, testing, logging and recovery requirements.
Related terms: impact, reversibility, sensitivity, assurance.
2. Reasoning and execution
7. Foundation model
The model used to interpret inputs, generate outputs or select actions. It may be a large language model, a smaller specialist model or a multimodal model. Model capability does not define the authority of the agent using it.
Related terms: inference, tokens, multimodal, reasoning.
8. Agent harness
The runtime around the model that manages instructions, tool definitions, context assembly, execution state, policies and responses. “Agent harness” is useful industry language, but it is not one universally standardised component.
Related terms: runtime, SDK, controls, execution.
9. Workflow
A predefined sequence of tasks and decision paths. A workflow is preferable when the business process is known and repeatability matters more than open-ended planning.
Related terms: steps, rules, branches, state machine.
10. Planning
The process of turning an objective into actions and dependencies. Plans may be generated once, revised after observations or constrained by a workflow. A plan is a proposal until the system validates that its actions are permitted.
Related terms: tasks, dependencies, decomposition, revision.
11. Agent loop
The repeated cycle of interpreting state, choosing an action, executing it, observing the result and deciding whether to continue. Every loop needs termination criteria and resource limits. For a longer treatment, see the AI agent loop.
Related terms: decide, act, observe, repeat.
12. Routing
Selecting the next model, tool, specialist, workflow or approval path according to intent, policy, confidence, cost and availability.
Related terms: intent, selection, fallback, escalation.
13. Structured output
Model output constrained to a machine-readable schema. Schema validation reduces ambiguity between reasoning and execution, but does not prove that the values are correct or authorised.
Related terms: JSON schema, validation, contract, parser.
14. Stop condition
A defined reason to end, pause or escalate execution. Examples include success, failure, timeout, budget exhaustion, low confidence, repeated actions or a required human decision.
Related terms: success, failure, timeout, escalation.
3. Context, knowledge and memory
15. Context engineering
Selecting, ordering, transforming and compressing the information supplied for a model call. Good context is relevant, authorised, attributable and small enough to reason over effectively.
Related terms: selection, ordering, compression, provenance.
16. Execution state
The durable facts describing the current task: status, completed steps, pending actions, identifiers, approvals and outputs. State belongs to the application. It should not be hidden only inside a conversation transcript.
Related terms: variables, progress, status, persistence.
17. Working memory
Information retained temporarily to support the current interaction or task. Working memory may include recent messages, intermediate results and a scratchpad, subject to the platform’s security and retention design.
Related terms: session, recent context, intermediate result.
18. Long-term memory
Information retained across tasks or sessions and retrieved when relevant. It needs explicit rules for consent, provenance, retention, correction, deletion, access and protection against poisoned or outdated memories.
Related terms: preference, history, recall, retention.
19. Knowledge source
An approved system or collection from which the agent may obtain business facts. Ownership, freshness and authority should be known. A document being searchable does not make it correct.
Related terms: system of record, owner, freshness, authority.
20. Retrieval-augmented generation
Retrieving selected information and including it in model context to support an answer or decision. RAG can improve grounding, but retrieval quality, source quality and answer faithfulness must still be evaluated.
Related terms: search, retrieve, rank, ground.
21. Provenance
Evidence showing where context, claims, instructions and tool results came from. Provenance supports verification, dispute handling and protection against untrusted content.
Related terms: source, lineage, citation, trust.
22. Context boundary
Rules controlling which data may enter a model call or cross between users, agents, tenants and security domains. Context isolation is essential in multi-user and multi-organisation systems.
Related terms: tenant, classification, isolation, redaction.
4. Tools and interoperability
23. Tool calling
The model requests a named capability using defined arguments; the runtime validates the request, executes the capability and returns a result. The tool, not the model, should enforce permissions and input constraints. There is more on this in tools: how AI agents actually do work.
Related terms: function, arguments, schema, result.
24. Tool contract
The machine-readable definition of a tool’s purpose, inputs, outputs, errors and side effects. Clear contracts reduce accidental misuse and make tools testable independently of the model.
Related terms: schema, validation, error, side effect.
25. Tool risk class
A rating based on data sensitivity, financial or operational effect, reversibility and reach. Read-only search, record update and money movement require different approval and monitoring controls.
Related terms: read, write, destructive, external effect.
26. Model Context Protocol
An open protocol for connecting AI applications to servers that expose tools, resources and prompts. An MCP host, such as an AI application, creates a client for each server it connects to. MCP standardises the connection and capability-discovery layer. It does not make a server trustworthy or grant safe permissions automatically. The specification itself says clients must treat a server’s tool annotations as untrusted unless the server is trusted.
Related terms: host, client, server, tools, resources, prompts.
27. Agent2Agent protocol
An open protocol for agent discovery, communication and task collaboration across systems. A2A defines concepts such as Agent Cards, tasks, messages and artifacts. It does not replace business authorisation, trust decisions or workflow ownership.
Related terms: Agent Card, task, message, artifact.
28. Agent card
Metadata describing an agent’s identity, endpoint, capabilities, skills and authentication requirements. Discovery information should be verified before another agent trusts or delegates work to it.
Related terms: discovery, capability, endpoint, authentication.
29. Handoff
The controlled transfer of task responsibility, context, authority and expected output to another agent or a person. A handoff needs an explicit owner and acceptance state.
Related terms: transfer, context, authority, ownership.
30. Multi-agent system
A system in which agents have distinct responsibilities and coordinate toward an outcome. Multiple agents add communication, security, evaluation and failure complexity. Use them when role separation or parallel specialisation provides measurable value.
Related terms: specialist, delegation, coordination, boundary.
5. Reliability and recovery
31. Orchestration
Coordinating models, tools, workflows, agents, state and approvals across an execution. Orchestration owns the sequence and should expose what is currently responsible for the task.
Related terms: sequence, coordination, state, ownership.
32. Checkpointing
Persisting sufficient state to resume safely after a pause, failure or approval wait. A checkpoint needs versioned inputs and completed-action records, not only a conversation snapshot.
Related terms: snapshot, persist, resume, version.
33. Idempotency
Designing an operation so that retrying the same request does not create unintended duplicate effects. Idempotency keys and deduplication records are particularly important for messages, orders and payments.
Related terms: key, deduplicate, replay, side effect.
34. Retry policy
Rules for retrying transient failures with limits, backoff and jitter. Permanent validation or authorisation errors should not be retried blindly.
Related terms: classification, backoff, jitter, attempt limit.
35. Timeout and deadline
Limits for a single operation and the complete task. Deadlines prevent stalled dependencies from consuming resources indefinitely and help the orchestrator choose a fallback or escalation path.
Related terms: duration, cancellation, expiry, escalation.
36. Circuit breaker
A control that stops calls to a failing or unsafe dependency after a defined threshold, allowing the system to fail predictably while the dependency recovers.
Related terms: threshold, open, recover, fallback.
37. Compensation
A defined action that reverses or offsets a completed side effect when a later step fails. Not every action is reversible, so the design must state where compensation is impossible.
Related terms: rollback, saga, reversal, reconciliation.
38. Failure queue
A durable place for failed or uncertain tasks that require retry, investigation or manual resolution. Silent failure is not a recovery strategy.
Related terms: dead letter, replay, triage, resolution.
6. Security and human control
39. Agent identity
A verifiable workload identity used by the running agent or service. It should be distinguishable from the model, the application, the developer and the human on whose behalf an action is performed.
Related terms: principal, credential, workload, attribution.
40. Delegated authority
The permission for an agent to act on behalf of a specific user or service, within stated scopes and time limits. The user’s identity should not be replaced by a shared system credential.
Related terms: consent, scope, token, on-behalf-of.
41. Least privilege
Granting only the data access and actions required for the current task. Permissions should be narrowed by tenant, resource, operation and time where supported.
Related terms: role, scope, resource, duration.
42. Sandbox
An isolated execution environment that restricts files, processes, network access and other resources. A sandbox limits impact but still requires secure configuration and monitoring.
Related terms: isolation, filesystem, network, process.
43. Guardrail
A preventive or detective control applied to model input, output, plans or actions. Guardrails may filter content, validate policy or block unsafe tool calls. They are layers of control, not a substitute for authorisation at the underlying system.
Related terms: validation, filter, policy, enforcement.
44. Human approval
A deliberate decision point before a selected action proceeds. The approver needs enough context to understand the action, evidence, impact and alternatives. Approval must be bound to the exact action so that later changes cannot reuse it silently.
Related terms: review, decision, evidence, binding.
45. Prompt-injection defence
Controls that treat instructions found in documents, websites and tool outputs as untrusted data. Defence requires content isolation, instruction hierarchy, tool restrictions and action validation. Prompt wording alone is insufficient. OWASP ranks prompt injection first in its Top 10 for LLM Applications.
Related terms: untrusted content, indirect injection, exfiltration, validation.
46. Secrets boundary
Keeping credentials out of model-visible context and exposing only the minimum capability through a trusted runtime. The model should request an action rather than receive a reusable secret.
Related terms: vault, token, rotation, broker.
7. Quality and operations
47. Evaluation
Testing the complete agent against representative tasks and risks. Evaluation covers outcome quality, groundedness, tool choice, policy compliance, safety, latency, cost and recovery. Model benchmarks alone do not evaluate the agent. See also evaluation: how do we know an AI agent is working?
Related terms: test set, scoring, regression, red team.
48. Observability and auditability
Observability uses traces, logs and metrics to explain system behaviour and diagnose failures. Auditability provides durable evidence of who or what acted, under which authority, using which inputs and approvals. Production systems need both, with appropriate privacy and retention controls.
Related terms: trace, log, metric, evidence, attribution.
Six production controls that cut across every layer
The 48 concepts are useful only when they influence the design. Six controls should be visible across the complete agent lifecycle.
A. Budget. Set limits for tokens, tool calls, elapsed time, retries, concurrent tasks and financial exposure. Budget exhaustion should trigger a defined stop or escalation path.
B. Version and change control. Record the model version, prompts, policies, tool schemas, knowledge sources, evaluation set and orchestration code associated with a release. A model change is a production change even when application code stays the same.
C. Service levels. Define measurable availability, latency, completion, escalation and recovery objectives. Avoid a service level that measures only whether the chatbot endpoint responded.
D. Operational ownership. Name the teams responsible for knowledge, model and prompt changes, integrations, access, incidents, quality review, cost and vendor escalation.
E. Incident response. Prepare for harmful output, unauthorised action, data exposure, runaway execution, corrupted memory, provider failure and quality regression. Include containment and evidence preservation.
F. Retirement. Define how the agent, model version, credentials, memory, indexes and scheduled work will be disabled or migrated. Agents should not become invisible operational dependencies.
A simple production-readiness test
Before an agent receives write access, the team should be able to answer these questions with evidence:
- What exact outcome is the agent authorised to pursue?
- Which actions can it take automatically, which require approval and which are prohibited?
- Which identity is used for every tool call, and whose authority is being exercised?
- Which context sources are trusted, and how are freshness and provenance checked?
- How are untrusted instructions in retrieved content prevented from controlling actions?
- What happens when a tool times out after creating an uncertain side effect?
- Can the task resume without repeating an irreversible action?
- Which evaluation set demonstrates acceptable quality and policy compliance?
- What limits contain cost, duration, retries and operational reach?
- Who monitors, supports, changes and retires the agent after launch?
If these answers are missing, the system may still be a useful prototype. It is not ready for unobserved production authority. The practical route from one to the other is covered in from local prototype to production-ready AI agent.
The practical architecture lesson
Teams often describe an agent using a short chain: user, model, tools and answer. That view explains the happy path. A production view needs to show authority, data boundaries, state, policy enforcement, approvals, failure handling, evidence and ownership.
The model proposes. The runtime coordinates. Tools enforce. Policy limits. People remain accountable.
That is the production system.
Primary references
Checked on 11 September 2026:
- Model Context Protocol, Architecture overview
- Model Context Protocol, Specification (version 2026-07-28 at the time of checking)
- Agent2Agent Protocol, A2A specification (version 1.0.0 at the time of checking)
- NIST, Artificial Intelligence Risk Management Framework
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
- OWASP, Top 10 for Large Language Model Applications (2025 edition)
- OWASP, Agentic AI security initiative
- OpenAI, Agents SDK documentation
- Microsoft, Azure Architecture Center: AI agent orchestration patterns
- AWS, Amazon Bedrock Agents
- Google Cloud, Choose a design pattern for your agentic AI system
Some of the 48 concepts are established software architecture practices applied to agent systems. Others are current agent-engineering terminology. None should be read as a formal standard in its own right.
How CloudNala can help
CloudNala helps organisations design agentic AI as an operating capability rather than a demonstration. The work includes use-case and risk classification, architecture, model and tool selection, context and knowledge design, identity, security, evaluation, cost controls, production readiness and the ownership model after go-live. We often start with the ten readiness questions above: the answers, and the gaps, shape the rest of the plan.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za