-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This page is a small glossary for readers who are new to agents and agentic AI.
The terminology can be confusing because words such as agent, tool, action, reasoning, state, and workflow are sometimes used as if they meant the same thing. They do not.
The examples in this repository explore these ideas from a scientific-workflow and distributed-computing perspective, using MPI, LangGraph/LangChain, and dispel4py. You do not need to know any of those technologies to use this page.
A useful starting point is:
GOAL
│
▼
AGENT
│
examines context
│
▼
REASONS
│
▼
chooses what to do
│
┌──────┴──────┐
│ │
▼ ▼
call a tool finish
│ │
▼ ▼
tool result final decision
│
└──────► context
│
└────► reason again
The important point is that an agent is more than an LLM call. An agent has a goal, receives context, can choose among permitted capabilities, observes what happens, and continues until it reaches a stopping condition.
| Concept | What does it mean? | Simple example |
|---|---|---|
| Agent | A software component with a role or goal that can inspect its current situation and choose what to do next from a set of permitted possibilities. | A sensor-triage agent decides whether it needs more information, whether maintenance should be requested, or whether a human should inspect the case. |
| Agentic workflow | A workflow containing one or more components that can make choices while working towards a goal, rather than every step being a completely fixed sequence. | A sensor workflow in which an agent may inspect history, compare neighbours, create a ticket, or escalate a case depending on what it observes. |
| LLM | A Large Language Model: a model that can interpret and generate language. It can be used as the reasoning or interpretation component of an agent, but an agent does not necessarily need an LLM. | Interpreting a diagnostic note such as "intermittent buzzing; cause unclear". |
| Goal | What the agent is trying to achieve. | Safely triage a sensor event and decide how it should be handled. |
| Context | The information currently available to the agent when it makes a decision. | The current reading, diagnostic note, previous readings, neighbouring readings, and results of tools already called. |
| State | Information remembered by the workflow or agent as execution progresses. | Pending tasks, recent sensor readings, tool calls, results, tickets, audit logs, or the current decision. |
| Reasoning | The process of examining the available context and deciding what should happen next. Reasoning may be implemented with deterministic Python rules, an LLM, or a combination of both. | "The current reading is unusual. I should compare neighbouring sensors before deciding." |
| Tool | A controlled function or capability that an agent is allowed to call. |
inspect_previous_readings() or create_maintenance_ticket(). |
| Tool call | The agent's request to execute a particular tool, normally with specific arguments. | Call compare_neighbouring_sensors(sensor_id="sensor-001"). |
| Tool result | What comes back after a tool has executed. The result is added to the agent's context and can influence the next decision. | A list of neighbouring temperatures, or confirmation that ticket MT-0001 was created. |
| Evidence | Information that helps the agent make a decision. Evidence may come with the original event or be obtained through tools. | Previous temperatures show that the sensor was stable until the current reading. |
| Action | Something the agent or workflow decides should happen. Depending on the design, an action may be carried out by calling a tool. | Request maintenance, retry a reading, notify an operator, or escalate to a human. |
| Final decision | The bounded conclusion that ends the agent's reasoning loop for the current task or event. |
maintenance or human_review. |
| Memory | State that is retained so that earlier information can be used later. Memory may be short-lived, persistent, local to one agent, or shared explicitly. | Keeping the last five readings from a sensor. |
| Policy / guardrail | Programmer-defined constraints on what the agent may do. | The agent may choose only approved tools and final decisions; a hard low-battery rule may bypass the LLM entirely. |
| Human in the loop | A design in which some decisions are deliberately handed to a person rather than automated. | An ambiguous or safety-relevant sensor event is placed in a human-review queue. |
| Audit trail | A record of what happened: evidence considered, tools called, results returned, and decisions made. |
"Compared neighbours → created maintenance ticket → final decision: maintenance". |
| Event | A piece of data arriving for processing. In streaming workflows, events flow between components. | One sensor reading containing timestamp, temperature, humidity, battery level, and a diagnostic note. |
This is one of the most important distinctions.
Agent ≠ LLM
An agent can be entirely deterministic.
For example:
if task_too_large:
split_task()
elif task_failed:
retry_task()
else:
process_task()This component can inspect a situation, choose between actions, and work towards a goal without using a language model.
An LLM becomes useful when the decision depends on information that is difficult to capture with simple fixed rules, particularly natural language.
For example:
Diagnostic note:
"Intermittent buzzing after condensation;
reading seems plausible but cause is uncertain."
│
▼
LLM
│
▼
human_review
A sensible agentic system often combines both:
clear structured condition
↓
deterministic rule
ambiguous unstructured information
↓
bounded LLM decision
The LLM therefore does not have to control the whole workflow.
In this context, reasoning simply means deciding what to do next from the information currently available.
It does not have to involve an LLM.
The programmer writes the decision explicitly:
battery < 10%
↓
maintenance
The same input follows the same programmed rule.
The programmer defines the goal, instructions, available tools, and boundaries, but an LLM interprets the context and chooses among the permitted possibilities:
diagnostic note
↓
LLM interprets meaning
↓
choose:
accept | retry | maintenance | notify_operator | human_review
In practice, the two can be combined:
Sensor event
│
▼
Deterministic prechecks
│
├── obvious problem ──► fixed action
│
└── ambiguous case
│
▼
LLM agent
This is often preferable to asking an LLM to make decisions that ordinary code can make more reliably.
These terms are especially easy to mix up.
A tool is a controlled capability exposed to the agent.
The agent does not magically gain access to Python, the operating system, a sensor network, or a database. The programmer decides which functions are available.
For a sensor agent we might expose:
These primarily retrieve information:
inspect_previous_readings()
compare_neighbouring_sensors()
For example:
Agent:
"I need to know whether this sensor was already drifting."
│
▼
inspect_previous_readings()
│
▼
Tool result:
21.8°C, 21.9°C, 22.0°C, 22.1°C
│
▼
This becomes new evidence for the agent
These primarily perform a controlled operation:
request_another_measurement()
create_maintenance_ticket()
notify_operator()
escalate_to_human()
For example:
Agent chooses:
create_maintenance_ticket()
│
▼
Python executes the function
│
▼
Tool result:
{
"ticket_id": "MT-0001",
"status": "created"
}
The purpose of the tool was to do something: create a ticket.
However, its result also becomes information in the agent's context. The agent now knows that the ticket was successfully created.
So:
Evidence tool
primarily GETS information
Operation tool
primarily DOES something
Both return a tool result
↓
the result becomes part of the agent's context
This tool is best described as an operation tool in the tutorial because it creates a request:
request_another_measurement()
↓
{
"request_id": "RM-0001",
"status": "request_created"
}
It does not immediately return a new physical sensor reading.
In a real IoT system, the request might eventually cause a device to take another measurement. That later measurement would then become new sensor evidence.
So its immediate purpose is an operation, while its ultimate purpose is to obtain better evidence.
Evidence is information, not an action.
For example:
Current evidence:
temperature = 34.7°C
battery = 81%
note = "possible calibration drift"
The agent may gather more:
inspect_previous_readings()
↓
more evidence
compare_neighbouring_sensors()
↓
more evidence
Evidence does not necessarily prove what happened. It gives the agent information that can support a safer decision.
It is useful to distinguish two kinds of evidence:
DOMAIN EVIDENCE
information about the thing being investigated
Examples:
previous temperatures
neighbour readings
diagnostic notes
EXECUTION EVIDENCE
information about what the workflow has done
Examples:
measurement request created
maintenance ticket created
operator notification sent
Both can become part of the agent's context.
These are also different.
Suppose the agent calls:
create_maintenance_ticket()
The tool may return:
ticket MT-0001 created successfully
That is a tool result.
The agent can observe it and then finish with:
final decision = maintenance
So:
create_maintenance_ticket()
│
▼
TOOL RESULT
"ticket created"
│
▼
agent reasons again
│
▼
FINAL DECISION
"maintenance"
The tool performs an operation. The result tells the agent what happened. The final decision tells the workflow how the event should ultimately be classified or handled.
A useful way to understand an agent is as a loop rather than a single LLM call.
┌──────────────────────────┐
│ │
▼ │
Examine context │
│ │
▼ │
Decide what is needed │
│ │
┌────────┴────────┐ │
│ │ │
need a tool? enough information? │
│ │ │
yes yes │
│ │ │
▼ ▼ │
choose tool submit final decision │
│ │
▼ │
execute tool │
│ │
▼ │
observe result │
│ │
└───────────────────────────────────┘
A three-iteration example might look like this:
ITERATION 1
Agent sees unusual temperature
↓
calls inspect_previous_readings()
↓
receives history
ITERATION 2
Agent sees that the change is sudden
↓
calls compare_neighbouring_sensors()
↓
receives neighbour readings
ITERATION 3
Agent concludes the anomaly is local
↓
calls create_maintenance_ticket()
↓
ticket is created
↓
submits final decision: maintenance
The loop is bounded by rules chosen by the programmer, such as a maximum number of iterations and a restricted set of tools.
Not every component in an agentic workflow needs to be an agent.
A conventional workflow component might do this:
receive event
↓
normalise temperature
↓
return event
There is no choice. It performs one fixed transformation.
An agentic component looks more like this:
receive event
↓
inspect context
↓
choose what is needed
↓
call a permitted tool
↓
observe result
↓
reason again
↓
possibly call another tool
↓
reach final decision
The wider workflow can therefore contain both:
ordinary deterministic components
+
agent components
This is an important design principle. Making one component agentic does not require turning every component into an agent.
These words are related but not identical.
An event is the item currently flowing through the workflow.
For example:
{
"sensor_id": "sensor-001",
"temperature": 34.7,
"humidity": 47.1,
"battery": 81,
"diagnostic_note": "possible calibration drift"
}State is information retained while processing continues.
For example:
recent readings
latest neighbour readings
measurement requests
maintenance tickets
operator notifications
human-review cases
audit log
Context is the information presented to the decision-making component at a particular moment.
It may include:
current event
+
relevant state
+
tool results
+
agent instructions
Memory is the mechanism by which useful information from earlier interactions or events is retained.
For example:
sensor-001
reading 1 ─┐
reading 2 │
reading 3 ├──► recent history ──► agent
reading 4 │
reading 5 ─┘
Memory is therefore one possible part of state, and relevant memory may be selected as context for the agent.
In ordinary language, action and tool are sometimes used loosely, which can be confusing.
A useful distinction for these tutorials is:
ACTION
what the agent decides should happen
TOOL
the controlled mechanism available to make something happen
For example:
Agent decision:
"this device should be sent for maintenance"
↓
Tool call:
create_maintenance_ticket()
↓
Tool result:
ticket MT-0001 created
Some systems use the word action to mean a tool call itself. That terminology is also common. The important thing is to be explicit about which meaning is being used.
"Agentic" does not mean that the software can do whatever it wants.
A useful agent normally has bounded autonomy:
autonomy
+
constraints
=
bounded agent
The programmer can control:
which tools exist
which arguments tools accept
which final decisions are valid
which deterministic rules run first
how many reasoning iterations are allowed
what information the agent can see
when a human must be involved
For example:
LLM may choose only:
accept
retry
maintenance
notify_operator
human_review
It cannot invent:
"shut down the entire building"
unless the programmer explicitly provided such a capability.
Some decisions should not be fully automated.
An agent can deliberately stop and request human input:
ambiguous evidence
↓
agent cannot safely resolve it
↓
escalate_to_human()
↓
human-review queue
↓
person makes the decision
Human escalation is therefore not necessarily a failure of the agent. It can be an intentional part of a safe agent design.
The difference is easier to see side by side.
| Deterministic workflow | Agentic workflow |
|---|---|
| Follows a predefined sequence or explicit branches. | May choose among permitted next actions while working towards a goal. |
| Logic is normally encoded directly by the programmer. | Decisions may use deterministic logic, an LLM, or both. |
| A component normally performs a known operation. | An agent may inspect, gather evidence, call tools, observe results, and decide again. |
| Excellent for predictable computation. | Useful when adaptation, interpretation, recovery, or tool selection is needed. |
| Easy to reproduce and reason about. | Requires additional attention to constraints, validation, observability, and testing. |
They are not competitors. A useful scientific workflow can combine them.
These frameworks are used in one of the tutorials, but they are not requirements for agentic AI.
LangGraph is an orchestration framework for stateful applications. It represents execution using concepts such as:
state
nodes
edges
routers
branches
loops
A simplified graph might be:
START
↓
prepare task
↓
worker
↓
pending work?
├── yes ──► worker
└── no ──► finish
LangGraph executes the graph that the programmer defines. It does not automatically make ordinary Python functions intelligent.
A node is a function registered as one step in a LangGraph graph.
A node might contain:
ordinary Python
validation
database access
an API call
an LLM call
a tool executor
or an entire agent
Therefore:
LangGraph node ≠ automatically an agent
An edge connects nodes.
A router or conditional edge chooses which node should run next.
For example:
if pending_tasks:
return "worker"
return "finish"The Python function makes the decision. LangGraph follows the route.
LangChain provides model integrations and abstractions for prompts, structured output, tools, and agent applications.
In the tutorial it is used to connect Python to an OpenAI chat model and request a structured response.
A useful simplification is:
LangGraph
orchestration and control flow
LangChain
model/tool integration
LLM
language interpretation or model-based decision
These responsibilities can overlap in larger applications, but keeping them separate is useful when learning.
dispel4py is a Python library for describing and executing data-intensive scientific workflows.
A dispel4py workflow is built from Processing Elements (PEs) connected in a graph:
PE
│
▼
PE
│
▼
PE
Data items or events flow between them.
For example:
ReadSensorDataPE
↓
NormalizeDataPE
↓
AnomalyDetectionPE
↓
AggregateDataPE
Each PE performs some part of the processing.
A Processing Element is a computational component in a dispel4py workflow.
A PE might:
read data
transform data
filter data
analyse data
aggregate data
call an external service
or contain an agent
Just like a LangGraph node, a dispel4py PE is not automatically an agent.
A normal PE may simply do:
input
↓
fixed calculation
↓
output
But we can implement agentic behaviour inside a PE:
LLMSensorAgentPE
│
▼
inspect event
│
▼
reason
│
┌───────┴───────┐
▼ ▼
evidence tool operation tool
│ │
└───────┬───────┘
▼
observe result
│
▼
reason again
│
▼
final decision
Nothing has to be added to dispel4py itself to "switch on agent mode".
The agentic behaviour comes from the code implemented inside the PE. dispel4py continues doing what it normally does: representing the workflow, moving data between PEs, and executing the graph using the selected mapping.
This is a central idea of the dispel4py tutorial:
dispel4py provides the workflow; the PE provides the agentic behaviour.
This distinction becomes important when an agent maintains state.
With a simple sequential execution, we can imagine:
event 1 ─┐
event 2 ─┼──► one LLMSensorAgentPE ──► results
event 3 ─┘
│
▼
local memory
The same PE instance sees the events sequentially, so maintaining recent sensor history inside that instance is straightforward.
With a multiprocessing mapping:
┌──► Agent PE copy 1
events ──────────────┼──► Agent PE copy 2
├──► Agent PE copy 3
└──► Agent PE copy 4
the PE instances may live in different processes.
Their ordinary Python memory is not automatically shared:
Agent 1 memory ≠ Agent 2 memory ≠ Agent 3 memory
This matters if an agent needs previous readings or neighbouring sensor information.
One possible design is to attach the evidence required for each event before the parallel agent stage:
raw event
↓
prepare relevant evidence
↓
{
current_reading,
previous_readings,
neighbour_readings
}
↓
parallel agent workers
This is not a new "agent feature" being added to dispel4py. It is an application design decision required because multiprocessing changes where local state lives.
For readers coming from HPC, an MPI process is an independently executing instance of an MPI program, identified by a rank.
rank 0
rank 1
rank 2
rank 3
MPI is excellent for efficient distributed computation and communication. An MPI rank does not become an agent merely because we call it one.
For example:
rank receives chunk
↓
adds +1
↓
returns chunk
is fixed distributed computation.
If a worker can instead inspect the task, choose between several permitted behaviours, recover, request work, or decide how to proceed towards a goal, its behaviour becomes more agent-like.
Agentic systems are therefore not replacements for MPI. They operate at a different level:
MPI
efficient distributed computation
workflow systems
orchestration and data movement
agents
adaptive coordination and decisions
LLMs
optional interpretation/reasoning capability
These layers can coexist.
When an LLM is used inside a workflow, we often do not want an unrestricted paragraph of text.
Instead, the application can require structured output.
For example:
{
"action": "maintenance",
"reason": "The note indicates possible calibration drift."
}A schema can restrict the permitted values.
Conceptually:
free-form language
↓
LLM
↓
structured schema
↓
known fields and allowed values
This makes the model's response easier for ordinary workflow code to validate and use.
Pydantic is a Python library commonly used to define and validate structured data.
For an LLM decision, a schema might say that the response must contain:
action
reason
and that action must be one of:
accept
retry
maintenance
notify_operator
human_review
The schema does not make the model intelligent. It constrains the shape of the response so that the rest of the workflow can handle it safely and predictably.
A bounded LLM-powered sensor agent might therefore look like this:
SENSOR EVENT
│
▼
deterministic checks
│
obvious case│
┌───────────┴───────────┐
│ │
▼ ▼
fixed handling LLM agent
│
▼
reasoning
│
┌─────────────┴─────────────┐
│ │
▼ ▼
evidence tool operation tool
│ │
▼ ▼
retrieve information perform operation
│ │
└─────────────┬─────────────┘
▼
tool result
│
▼
update agent context
│
▼
reason again
│
▼
submit final decision
│
▼
audit trail
The responsibilities remain deliberately separated:
| Component | Responsibility |
|---|---|
| Workflow system | Moves data and orchestrates workflow components. |
| Agent | Works towards a goal and chooses among permitted capabilities. |
| LLM | Optionally interprets ambiguous or unstructured information. |
| Evidence tools | Retrieve information the agent may need. |
| Operation tools | Perform controlled operations. |
| Tool results | Tell the agent what a tool returned or what happened. |
| State / memory | Retains information needed across processing. |
| Structured schema | Constrains model outputs to a form the program understands. |
| Deterministic rules | Handle cases that should not depend on model interpretation. |
| Human | Handles cases deliberately kept outside automatic decision-making. |
| Programmer | Defines the goal, tools, policies, limits, workflow, and safety boundaries. |
If you remember only one diagram from this page, make it this one:
PROGRAMMER
defines goals, tools and limits
│
▼
AGENT
│
"What do I know?"
│
▼
CONTEXT
│
"What should I do?"
│
▼
REASONING
│
┌─────────────┴─────────────┐
│ │
▼ ▼
EVIDENCE TOOL OPERATION TOOL
"tell me more" "do something"
│ │
▼ ▼
RESULT RESULT
│ │
└─────────────┬─────────────┘
▼
UPDATED CONTEXT
│
▼
REASON AGAIN
│
┌────┴────┐
│ │
more tools enough
│ │
└────┐ ▼
│ FINAL DECISION
│
└── loop if needed
Or, in one sentence:
An agent works towards a goal by examining its context, choosing among programmer-provided tools, observing the results, and repeating this process until it can make a bounded final decision.
The LLM is optional. The tools are controlled. The workflow still matters. And sometimes the best decision an agent can make is: ask a human.