AI agents are software systems in which a model helps control a multi-step workflow. An agent may choose from permitted tools, observe their results, update task state, and continue until it reaches a stopping condition or asks for human input. “Agentic” describes delegated control; it does not mean consciousness, independent thought, or guaranteed competence.

A model call maps input to output. An agent adds tools, state, instructions, permissions, validation, and an execution loop around one or more model calls. That flexibility can help with open-ended work, but it also increases latency, cost, security exposure, and failure modes.

Workflow or agent?

A deterministic workflow follows paths defined in code. An agent lets a model choose some next steps. Use ordinary automation when the sequence and decision rules are known. Consider bounded model-directed behavior when tool feedback must shape the next step and the expected benefit justifies higher variance. Hybrid designs are often best: code enforces policy while the model handles ambiguous language.

A practical architecture

  • Model and instructions: interpret current context and propose a structured action. The output may be wrong.
  • Tools: narrow, typed interfaces for reading data or changing state. Validate arguments, authenticate the user, enforce authorization, set timeouts, and define errors in code.
  • State: task details, prior observations, budgets, approvals, and progress. Persistent memory is optional and needs access, retention, privacy, and provenance controls.
  • Control loop: executes allowed actions, records results, checks policy and budgets, then continues, pauses, or exits.
  • Evaluation and observability: traces model and tool behavior, measures task success and side effects, and supports incident review.

Retrieving an old record changes the context supplied to a model; it does not update model weights or prove that the system learned. Call this retrieval or persistent state unless an evaluated training mechanism exists.

Design tools around risk

Separate read, draft, and execute permissions. A research agent may search an approved knowledge base and draft a response, while sending a message, changing an account, making a purchase, publishing content, or deleting data should require independent validation and, where appropriate, accountable approval.

Treat webpages, documents, emails, retrieved records, tool output, and peer-agent messages as untrusted data. They can contain prompt injection designed to override instructions or exfiltrate information. Prompt wording is not a security boundary: constrain tool schemas, isolate execution, minimize accessible data, and authorize every action at the tool boundary.

Evaluate the complete system

Create a representative evaluation set with normal cases, edge cases, adversarial instructions, denied actions, stale data, partial failures, and recovery paths. Measure correct completion, unsupported claims, policy violations, harmful side effects, latency, cost, approval quality, and recovery—not just whether the agent produced a plausible final answer.

Record the model version, instructions, tools, retrieval sources, settings, approvals, and results. Set explicit limits for time, tokens, tool calls, retries, spend, and affected records. Use idempotency and rollback where possible and provide an operator stop control.

When should people approve an action?

Require review when an action is consequential, difficult to reverse, regulated, privacy-sensitive, or outside a previously approved scope. Show the reviewer the exact action, destination, data, and arguments. Approval is only one layer: people can over-trust fluent output, so authorization and validation must remain independent.

Adopt autonomy gradually

  1. Define the task, data boundary, acceptance criteria, and prohibited actions.
  2. Start read-only or draft-only and compare against a deterministic baseline.
  3. Red-team tool and data boundaries, including indirect prompt injection.
  4. Pilot with narrow permissions, budgets, logging, and incident ownership.
  5. Expand autonomy only when measured results justify the added risk.

There is no universal answer to whether an agent is safe for business. Suitability depends on the task, model, tools, permissions, evidence, failure impact, jurisdiction, and controls. For broader policy and oversight, see AI governance best practices. Use LLM evaluation metrics as a starting point, while adding system-level and side-effect measures. For factual failure modes, see the guide to AI hallucination.

Originally published August 18, 2025; technically reviewed and substantially updated September 4, 2026.