October 2026
The word “agent” is getting used for almost everything in AI right now. Sometimes it means a chatbot that can call a tool, sometimes a workflow, sometimes it's a long-running system that operates across multiple apps for hours.
An AI agent is a system that uses a model to pursue a goal by choosing actions, using tools, observing what happened, and deciding what to do next. A model call is not an agent. The model is the decision-making part, the agent is the entire system around the model.
The system includes instructions, context, tools, permissions, memory, runtime, governance that determine when the work is complete.
Goal
What result is the agent responsible for?
Trigger
What causes the agent to run? This can be a user request, an API call, a scheduled time, an event, or another agent.
Scope
Which cases is the agent allowed to handle?
Access
What data can the agent read? This could include Salesforce, NetSuite, Slack, a database, an api, a virtual machine, or the public web.
Tools
What actions can it take? Can it search salesforce, update a contract, create a ticket.
Authority
Which actions can the agent perform by itself? Which actions require human approval?
Completion
What state proves the task is done? Has the model achieved the goal? How is that determined? This should not be left up to model observation.
Escalation
At what stage does the agent escalate to a human?
Limits
How long can it run? How many steps, retries, model calls, or tool calls can it make?
There are many ways to classify agents. A single agent could be event-driven, could be long-running, could be a loop all at the same time. These are the ways that I have seen that I would classify agents as.
Information Agents
Information agents primarily retrieve, analyze, and summarize information. They have read access but do not have the ability to actually complete work.
Copilots
A copilot investigates a task and recommends what should happen but a human is still responsible for taking action. It uses information and provides the next step.
Bounded Autonomous agents
Bounded Autonomous Agents can complete a part of the work without human approval. There is a limited amount of autonomy which exists inside of a defined boundary.
There are many other agent types: event driven, scheduled, long-running and more.
Workflow agents follow a predefined sequence or set of steps. This is a path that would be known ahead of time. The model may still be used for each individual step, but there is no reasoning used in the overall execution of the process.
Loop agents do not know every step ahead of time. Instead it repeatedly observes, reasons, chooses action, acts, observes results over and over again until goal is achieved.
The smartest way to build real operational agents will be a hybrid of these two types. Some parts are deterministic, other parts benefit from model reasoning. It gives the agent flexibility without allowing the model to control every part of the system.
Once you have multiple agents that exist, you need a system that defines and governs them. This is the agent control plane. A platform should have one shared control plane that governs many agents. The control plane answers questions like:
A control plane is used to define how an agent is allowed to operate. It does not actually execute the work. The runtime is the system that actually executes the agent. The runtime maintains state of tasks, calls the model, executes the tools, enforces policies, and handles all sorts of failure modes.
The runtime needs to know the current task, previous actions, tool results, pending approvals, current loop step, retry count, relevant memory. This is called state. Without state, every model call would start over from scratch. The model should also never touch Salesforce, NetSuite, a browser, or a computer. Instead the model picks the best tool and the runtime executes the request. The runtime then gives the result back to the model, creating the next iteration of the same loop.
Once agents can take real actions, security becomes the most important part of the architecture.
How do you give an agent enough power to do its work without giving it unlimited power?
You give it the least privilege. An agent should only receive access required for its job. For tools, it would only get the access to a narrower list of tools necessary for it to do its job. For a policy, the model would never be able to dictate policy, the runtime would check the policy that has been defined.
Putting it together, an agent begins with a trigger, either a user request or an event. The control plane determines which agent should run and loads its definition, including its goal, permissions, tools, policies, model, memory rules, and runtime constraints. The runtime then executes and maintains its state as the agent works on the task. It calls the model with the current relevant context, gets back the next action, makes sure that action is aligned with the policies and permissions and then executes via a tool if necessary. The result of that is now the new state and is now passed back to the model creating a loop that continues until the task is complete. The runtime determines if a task is complete or whether it is not yet. Throughout the entire execution, security controls what the agent is allowed to do.
I think the easiest way for me to think about an agent is that the model is only one part of the system. The model provides reasoning, but the control plane defines the boundaries, and then runtime manages execution. As models become more and more capable of reasoning, the important problem will be making sure the action a model chooses is reliable, secure, and governed. This is what will turn a model into an agent that can actually be trusted to perform real work.