Problem
The agent label is applied to both deterministic automations and open-ended systems. Without an architectural distinction, teams can grant unnecessary autonomy or build expensive loops for tasks that a workflow would solve more reliably.
Introduction
The term AI agent is now applied to systems as different as a scripted chatbot, a model that can call one search tool, a coding system that edits repositories for hours and a network of autonomous services. That breadth makes the label commercially useful and technically weak. Architecture requires a sharper distinction.
An AI workflow uses predefined code paths to orchestrate models and tools. A model may classify an input, produce a draft or evaluate a result, but the application substantially determines what happens next. An AI agent gives a model more control over the sequence of actions. The model can inspect a situation, choose tools, observe results, revise a plan and continue until it believes the objective is complete or a stopping rule intervenes.
Neither pattern is universally better. Workflows provide predictability, testability and cost control. Agents provide flexibility when the correct path cannot be known in advance. Most serious systems should be hybrids: deterministic software defines authority and invariants, while models handle interpretation and open-ended decisions inside those boundaries.
The basic workflow
A simple AI workflow might receive a document, classify its type, select a prompt template, generate metadata, validate required fields and send uncertain cases to a human. The sequence is explicit. Each step has known inputs and outputs. Failures can be associated with a stage, and the system can retry or stop according to policy.
Prompt chaining is one common pattern. One call creates an outline, another checks it against criteria, and a third writes the article. Routing sends different inputs to specialized paths. Parallelization runs independent analyses and combines them. Evaluator-optimizer loops generate, critique and revise under a fixed control structure. These workflows can include sophisticated model behavior without granting the model control of the entire process.
The strength of a workflow is boundedness. Engineers can estimate the maximum number of calls, define schemas, test branch behavior and review logs. The weakness is rigidity. If a task requires an unanticipated investigation or tool sequence, the predefined path may fail even when a capable model could adapt.
The basic agent loop
An agent usually combines an objective, model, tools, state and environment. The model receives the current objective and observations. It chooses an action, such as searching, reading a file, querying a database or executing code. The environment returns a result. The model incorporates that result and chooses the next action.
This loop continues until a completion condition, human checkpoint, error, budget limit or iteration cap. The key architectural difference is that the action sequence emerges at runtime. The developer defines available actions and constraints, but not every transition.
Agents are valuable for tasks where the number and type of steps depend on what is discovered. Investigative research, repository-wide code changes, incident diagnosis and complex information gathering fit this pattern. The environment provides feedback that lets the system correct itself.
The same flexibility creates risk. A bad early assumption can influence later decisions. Repeated model calls increase latency and cost. Tool results may be misunderstood. Completion can be difficult to verify when objectives are vague.
Architecture
An agent architecture combines objective, model, tools, state, environment, permissions, observation loop and stopping rules. A workflow architecture fixes more transitions in code. Hybrid systems place model-directed choices inside deterministic control boundaries.
Agency belongs to the system
A language model alone is not an agent. It produces output from context. Agency appears when application architecture treats some outputs as decisions that change the environment or determine later steps.
The complete system includes tool schemas, credentials, memory, logs, approval gates, budgets, evaluators and user interface. A model with read-only search access has different agency from the same model with permission to publish, purchase, deploy or delete. A high-capability model inside a narrow sandbox may be less risky than a weaker model with broad credentials.
This distinction prevents anthropomorphic confusion. The operational question is not whether the model “wants” something. It is which actions the system permits, which observations it supplies, how state persists and who remains accountable for consequences.
Tool design
Tools are the agent-computer interface. A tool should expose one clear action with explicit parameters, bounded output and useful error information. Overlapping tools create ambiguity. Hidden side effects make planning unreliable. Loose natural-language parameters increase the chance that a model produces an invalid or dangerous request.
Strong tools use schemas, enums, identifiers and validation. They distinguish reading from writing. They support dry runs where possible. Consequential actions can require a confirmation token or human approval. Idempotency keys prevent accidental repetition. Results should state what changed rather than returning only a success message.
Tool descriptions matter because the model selects actions from those descriptions. Documentation should include purpose, boundaries, required context and common failure cases. Tool evaluation deserves as much attention as prompt evaluation.
Memory and state
Agent memory is often described as if it were a single faculty. In practice it includes several stores. The current context contains recent instructions and observations. A task state record tracks goals, completed steps and pending work. Long-term memory may store summaries, preferences or retrieved documents. Environment state lives in files, databases and external services.
Each store has different truth and retention properties. A generated summary is not equivalent to an authoritative database record. A conversation memory may contain user preference but should not silently override current permissions. A tool result may become stale.
For Electronic Artefacts, graph identity provides a stronger memory model than unstructured notes alone. An agent can refer to canonical entity IDs, typed relations, publication status and provenance. Context can be assembled from the graph according to task and permission rather than copied indiscriminately into a prompt.
Contextual permissions
Traditional access control asks whether a user or service can call an operation. Agentic systems need more context. The permission may depend on who initiated the task, which entity is targeted, whether the record is public or restricted, what evidence supports the change, and whether the action is reversible.
This is the connection to Contextual Execution. VASTE can model a publication agent that may draft metadata for public concepts but cannot publish a speculative research record. An archive agent may read internal preservation metadata but only expose a curated projection. An ORETH analysis agent may inspect private audio files while publishing only derived observations approved by a human.
The agent should receive capabilities scoped to the current task, not permanent broad credentials. Short-lived authorization, isolated workspaces and explicit entity boundaries reduce blast radius.
Reliability patterns
The first reliability pattern is to prefer a workflow when the path is known. Classification, extraction, formatting and simple transformations rarely need open-ended autonomy.
The second is to make agent actions observable. Logs should include task identity, model configuration, tool calls, results, state transitions, approvals and final outcome. Hidden reasoning need not be stored as authoritative evidence, but operational decisions must be reconstructable.
The third is to separate proposal from execution. A model can propose a plan or patch; deterministic code and humans can validate it before changing production state.
The fourth is to define stopping conditions. Success criteria, maximum iterations, time budgets and escalation rules prevent loops that continue without measurable progress.
The fifth is to test failure recovery. Tools should return actionable errors. Agents should know when to retry, choose an alternative, ask for help or stop. Unbounded retry is not resilience.
Evaluation
Workflow evaluation can measure each stage independently. Did routing choose the correct branch? Did extraction satisfy the schema? Did the evaluator catch unsupported claims? This modularity makes regression testing straightforward.
Agent evaluation must include trajectories, not only final answers. Two agents can reach the same output with very different cost and risk. Metrics may include task completion, action count, tool error rate, policy violations, human interventions, latency and reversibility.
Representative environments are essential. An agent tested only on clean examples may fail when files are missing, APIs time out or tool output contains adversarial instructions. Sandboxed testing should include misleading evidence, ambiguous goals, partial permissions and conflicting state.
For knowledge work, source attribution is a primary metric. A research agent should not merely produce a plausible report; it should expose which sources support which claims and where uncertainty remains.
Human oversight
Human-in-the-loop does not mean placing a confirmation button at the end of an opaque process. Useful oversight requires legible state, meaningful choices and enough time to intervene. The interface should show proposed action, target, evidence, consequence and rollback path.
Approval should be concentrated at consequential boundaries. Requiring confirmation for every read operation creates fatigue. Allowing an agent to batch irreversible actions behind one vague approval creates false control.
Humans also define quality. Creative, editorial and cultural tasks cannot always be reduced to automated scores. An agent can gather sources, generate alternatives or check structure, but publication remains an accountable editorial decision.
Choosing the architecture
Use a single model call when the task is narrow and context is sufficient. Use a workflow when steps and validation can be defined in advance. Use an agent when discovery determines the path and environmental feedback can guide correction. Use a hybrid when open-ended planning is valuable but actions require deterministic controls.
A useful decision test is: can the system enumerate the valid path before seeing the input? If yes, a workflow is likely enough. If no, ask whether the objective has measurable completion criteria and whether the environment can provide reliable feedback. Without those conditions, an agent may generate activity rather than progress.
Cost matters. Agent loops can multiply model calls and tool operations. A simpler workflow may deliver better reliability at lower latency. Architectural sophistication is not an outcome.
Implementation
Start with one bounded workflow and expose a small tool set with typed schemas. Add model-directed planning only where the correct path depends on discoveries. Log action trajectories, enforce budgets and require approval before irreversible effects.
Evidence
Anthropic’s engineering guidance distinguishes workflows with predefined orchestration from agents whose models direct tool use dynamically. NIST’s AI RMF provides a broader framework for mapping context, measuring risk and governing AI systems.
Electronic Artefacts applications
The Knowledge Hub can use workflows for frontmatter validation, link checking, relation generation proposals and SEO checks. Agents are better suited to investigating a topic across many source types, tracing missing graph relations or updating a set of connected pages whose scope cannot be known beforehand.
VASTE provides the deeper research context. An agent operating on a graph can use identity and relation semantics as constraints. Vestiges could support contribution agents that propose links between people, techniques and institutions while preserving human validation. ORETH could support exploratory audio-analysis agents that choose measurements based on observed signal structure.
In every case, the agent should strengthen human understanding rather than conceal the system behind a conversational surface.
Future of agentic systems
Future systems will likely combine smaller specialized models, deterministic services, retrieval, event streams and human review. Agent-to-agent communication may become useful, but multiplying agents does not remove the need for contracts. It increases the importance of identity, authority and traceability.
The durable research questions are not how many agents a system contains. They are how goals are represented, how authority is scoped, how environmental truth is obtained, how actions are evaluated and how humans retain meaningful control.
Limitations
Terminology remains inconsistent across products and research. Some systems combine workflow and agent properties, so classification should describe actual control, permissions and runtime behavior rather than rely on a vendor label.
Related concepts
Read AI Agent, Large Language Model, Autonomous System, Contextual Execution and Graph Runtime.
Related programs
See VASTE for graph runtime, identity and contextual execution.
Glossary
Workflow: a predefined sequence or graph of processing steps.
Agent: a system in which a model selects actions dynamically.
Tool: a bounded external capability exposed to a model.
Trajectory: the sequence of observations, decisions and actions taken during a task.
Guardrail: a control that constrains or checks system behavior.
References
- Anthropic. Building Effective Agents. 2024.
- NIST. AI Risk Management Framework. 2023.