Agentic AI

Agentic AI is a broad term for AI systems designed to pursue goals with some autonomy: planning, choosing actions, using tools and adjusting to results, rather than producing a single response to a single prompt. It names the approach, while an AI agent is a specific system built that way.

The change it describes is a change in who decides the path. In most conventional software, the logic that selects each next step is written by a developer. Such a program can branch, react to events and still behave in ways that are hard to predict, but the choices open to it at each point were defined in code. In an agentic system, a person or another system supplies an objective, and part of the path to it is selected at run time by a model that is reading the situation as it goes. That is useful for work that cannot be fully specified ahead of time, and it raises questions that software with a fixed path does not.

From producing a response to pursuing an objective

The simplest way to use a generative model is a single exchange: a prompt goes in, and text, code or an image comes out. The interaction ends when the output is delivered, and what happens next is up to the person who asked. That is an interaction pattern, not a limit on what generative models can do.

An agentic system is given an objective and works toward it through a sequence of actions. It reads a file, runs a query, calls an API, looks at what came back, and decides what to do next.

The two are not opposites. Most agentic systems are built on generative models, and it is the model's generated output that selects each next action. The same model can sit behind a chat window and behind an agent. What differs is the arrangement around it: tools it can call, an environment it can act on, results fed back to it, and a loop that continues until the work is finished or something stops it.

It is also a matter of degree. A 2023 paper from OpenAI on governing agentic systems defines agenticness as the degree to which a system can adaptably achieve complex goals in complex environments with limited direct supervision, and breaks it into four dimensions: the complexity of the goals, the complexity of the environment, adaptability to unexpected circumstances, and independent execution. A chat assistant that runs one web search before answering is slightly agentic. A system that works through a migration across forty repositories overnight is much more so.

What makes a system agentic

Five properties recur across the definitions in use.

• Goal-directed execution. The system is given an objective, not a script, and the objective guides it across many steps.
• Autonomy within constraints. It chooses at least part of its own sequence of actions, inside limits someone else has set.
• Interaction with an environment. It acts on something outside the model, usually through tool calling: files, APIs, databases, other software.
• Feedback. The results of its actions return to it and become part of what it reasons over. The ReAct work of 2022 is an early and influential formulation of this interleaving of reasoning, acting and observing, and the repeating cycle is now usually called the agent loop.
• Adaptation. It changes its approach in light of what it finds.

Autonomy is a dial

Autonomy is not a property a system either has or lacks. Three things vary independently.

• Human direction. Who sets the objective, and how precisely.
• Delegated decisions. Which decisions have been handed to the system, and which stay with a person.
• Freedom of path. How much room the system has to choose its steps inside the limits it was given.

One research framework describes five levels of agent autonomy by the role left to the human: operator, collaborator, consultant, approver and observer. Its authors argue that the level of autonomy is a deliberate design decision, separate from what the system is capable of. In practice one system often runs at several levels at once: a person observes its reads, approves its writes, and is consulted before anything irreversible. The entry on human in the loop covers those arrangements.

Bounded autonomy is the normal case. The useful question about an agentic system is not whether it is autonomous, but what it has been given the freedom to decide.

Workflows and agentic execution work together

Agentic AI is sometimes presented as the successor to conventional workflows. It is better understood as a complement to them.

Anthropic's engineering guidance groups both under the heading of agentic systems and draws an architectural line between them: in a workflow, models and tools are orchestrated through predefined code paths, while an agent directs its own process and tool use. The same guidance recommends the simplest solution that works, notes that agentic systems often trade latency and cost for better task performance, and observes that workflows offer predictability and consistency for well-defined tasks.

Deterministic, event-driven workflows remain the right tool where the steps are known, the volume is high, the order is mandated, or each step must be testable in isolation. Agentic execution adds value where the work involves interpreting unstructured information, handling situations nobody scripted, or covering a long tail of cases that would otherwise need hundreds of branches.

The two combine naturally. A workflow can determine when work begins, which stages are required, what constraints apply, and what counts as complete. An agent can exercise autonomy inside one of those stages. Industry usage for the space in between varies, and agentic workflow is the usual name for a process in which the model controls part of the sequence, but not all of it.

An example: a dependency update inside an event-driven workflow

The following scenario is illustrative. It was written for this entry and does not record a real run.

A security advisory is published for a payments client library. An event-driven pipeline reacts: for each repository that uses the library, it creates a branch, runs an update stage, runs the required checks, and opens a pull request for a human reviewer. The pipeline's constraints are fixed. Work stays within the one repository, the CI configuration is not to be changed, and nothing merges without review.

With fixed automation in the update stage, the job bumps the version number and runs the tests. If they pass, the pull request opens. If they fail, the job stops and labels the repository for a person. That is predictable and useful, and for many repositories it is enough.

With an agent in the update stage, the objective is "update the library to a patched version and keep the build passing". In one repository the run goes like this.

1. The agent bumps the version and runs the tests. Fourteen fail.
2. It reads the failures and then the library's changelog, and finds that a function was renamed in the patched release. This is unexpected information that should change its path. It updates four call sites and runs the tests again. One still fails.
3. The remaining failure is in a date-handling test that has nothing to do with the library. The agent checks and finds that it fails on the main branch too. It now has choices. It could mark the test as skipped, which would turn the required check green. It could try to fix the date bug. Or it could leave the test alone and report what it found.
4. The library's migration notes also suggest two extras: running a remote install script that sets up a command-line helper, and moving to a new major version of a web framework to use a newer integration. The notes describe both as optional, and the patched release works without them.
5. The agent leaves the failing test as it is, does not run the script and does not touch the framework. In the pull request it states the position accurately: the library is at the patched version, four call sites were changed, the tests that exercise the library pass, and one required check is still failing because of a date-handling test that also fails on the main branch. It does not report the task as complete.
6. Whether the work can proceed is the workflow's decision. Its completion criteria require all checks to pass, so the pipeline holds the pull request and routes the pre-existing failure to the repository's owners.

A fixed script would have stopped at step 1. The agent interpreted a failure, found its cause in a document nobody had pointed it to, revised its approach and continued. That is the capability the term names. Steps 3 to 5 are where the same capability is tested, and the sections below return to them.

Four things that sound like "done"

In the example, the agent's report is accurate about the state of the work: the dependency edit is finished, and the checks have not all passed. That is a report on execution, not a claim that the objective has been met. Two things remain separate from it. The workflow's completion criteria decide whether the work proceeds, and here they hold it until the failing check is resolved. And whether the vulnerability has been remediated is a further fact. The vulnerable version may still be pulled in through another dependency. The pipeline's later stage, a scan of the built artifact, addresses that within its coverage: it checks the dependencies it can resolve against the advisories it knows. A clean result establishes that the known vulnerable version is absent from what was scanned. It does not establish that no copy of the flaw exists elsewhere, such as in vendored code, another artifact, or a deployment that has not yet picked up the change.

Feedback, adaptation and the question of influence

Adaptation is what makes an agentic system worth having. When it meets new information it may revise its approach, retry an operation, look for more information, or ask a person. Without that it would be a script with extra cost.

The same capability creates a responsibility. Whatever an agent reads can influence what it does next: tool results, retrieved documents, user messages, the outcome of its own earlier steps. Some of that influence is exactly what is wanted. Some of it is irrelevant, mistaken, malicious, or comes from a source with no authority over the task. Four things need to be kept apart.

• Information the agent is permitted to consider. The test output and the changelog, in the example. Reading them and acting on what they reveal is the point.
• Instructions the agent is authorized to follow. Those that come from the workflow and from the people who own the task. The migration notes are a third party's recommendation. They are information about what the library's authors suggest, not an instruction that carries authority, and a line of text does not gain authority by being phrased as a command. Here the extras were optional, so leaving them out cost nothing. Had the notes said the script was required for the patched release to work, the right response would have been to stop and escalate to the task's owners: not to run it on the notes' say-so, and not to decline it silently and report the work as finished.
• Changes of approach that remain justified by the original objective. Editing four call sites was not in the original plan, and it serves "keep the build passing" directly.
• Departures that exceed the objective, authority, scope or policy. Skipping the failing test would satisfy the check while defeating its purpose. Fixing the date bug or upgrading the framework may be good ideas, and neither is the task. Editing the CI configuration is ruled out by the workflow's constraints.

A system can be technically capable of an action, and even hold permission for it, without the action being appropriate to the task. Prompt injection is the adversarial version of this problem, where content is crafted to redirect an agent. There is also an ordinary, non-adversarial version: well-meant content that the agent treats as more relevant or more authoritative than it is. Both illustrate why autonomy brings a governance responsibility with it.

This raises the central question for the field. Can the way an autonomous system responds to information be governed without removing the intelligence and flexibility that make it useful? Scripting every step would answer it by giving up the benefit. The more promising direction is to state the objective and the authority explicitly, leave the path open, evaluate what the system does against that statement, place firm limits at the points where consequences are serious, and keep a record good enough that an adaptation can be examined afterward. Governance in that sense makes autonomy accountable. It does not replace autonomous decisions with a predefined sequence.

Completion and efficiency

An agentic system should be judged on more than whether its individual operations succeeded. Three questions matter: whether it accomplished the original objective, how much effort that took, and whether its adaptations along the way remained justified.

Effort has several dimensions: retries, tool calls, model tokens, elapsed time, money, and human intervention. AI agent cost depends on the path taken, which is why two runs of the same task can differ widely.

Efficiency is not the fewest possible steps. In the example, checking whether the date test also fails on the main branch cost an extra run and produced the fact that made the right decision clear. A verification step or a justified change of approach can improve the overall result. What efficiency asks is whether the effort spent was proportionate to the outcome achieved, and that is best answered once the outcome is known. The entry on AI agent governance treats completion and efficiency as responsibilities in more depth, and agent evaluation covers how they are measured.

How the neighboring concepts fit

Four terms are often used together and are not synonyms.

• Agentic AI describes the behavior and the degree of autonomy.
• An agent harness is the software that supports the system's execution: the loop, tool routing, context and state.
• The Model Context Protocol standardizes how an application connects to external capabilities and information.
• Governance establishes accountability to objectives, authority, policies and outcomes.

A system can be highly agentic with a minimal harness and no MCP, and a sophisticated harness can run a system that is given very little autonomy.

Why dynamically chosen paths make governance consequential

When the logic that selects each step is written in code, reviewing the code goes a long way toward reviewing the behavior. When a model selects steps at run time, much less of the behavior can be read from the code. It is settled in the run, and two runs of the same task can differ.

Permissions do not close the gap. An agent may be permitted to use a system while a particular operation on it has nothing to do with its assigned objective. Permission answers what the agent may touch. It does not answer whether touching it served the task.

Runtime governance addresses that second question: it evaluates an agent's actions against a declared intent, scope and policy while the agent executes, and records the result as evidence. Evaluation and evidence are one part of a broader architecture. Responses to a finding are another, ranging from a flag for review to a request for approval to enforcement, and enforcement is effective when it sits at the boundary where the consequential action can occur. The Governor Model, the architecture proposed in the Sentience white paper, treats governance as a continuous control loop over an agent's scope, its memory, and the identities and policies that constrain both. It describes an architecture and a direction, not the current capabilities of any product.

None of this is only a constraint on autonomy. A clearly stated objective, a defined scope and a reviewable record are what allow an organization to extend more autonomy to a system, because departures become visible.

Sentience Governor is one implementation of runtime governance. Its current implementation records a declared objective and scope, evaluates each attempted action at the points where it is instrumented, flags what falls outside the declaration or the operator's policy, and records the result. It does not block or approve actions. Its evaluation is deterministic and structural. It compares the tool, the type of operation and the target system with what was declared, and it does not interpret the meaning of the objective. Applied to the example, that boundary is clear. With a declared scope covering the repository's files and test processes, the call-site edits, a skipped test and a change to the CI configuration would each be recorded as an in-scope file write with no finding, because the structural facts are the same. Piping a remote script into a shell would be recorded with an incomplete classification and flagged as outside the declared scope. Deciding that skipping the test was a departure requires understanding the objective, which is a judgment for a reviewer, or for semantic evaluation that is not part of the current implementation.

Often confused with

An AI agent. An AI agent is a specific system. Agentic AI is the approach and the property. A system built this way may use one agent or several, and coordination among agents is not a requirement.

Autonomous agents. The phrase suggests a separate kind of system. Autonomy is a matter of degree, and most deployed agents operate within limits someone has set.

Generative AI. Agentic systems are usually built on generative models. The distinction is between producing an output and pursuing an objective through actions, and one system can do both.

Agentic workflows. The boundary with an agentic workflow is not fixed, and usage varies. Broadly, a workflow has a predefined structure with model decisions inside it, and the more of the sequence the model chooses, the more agentic the system is.

Multi-agent systems. A multi-agent system divides work among several agents. It is one way to build an agentic system, not a defining feature of one.

Conventional automation. Scripts, scheduled jobs and robotic process automation follow logic their authors defined. They can branch on their inputs and can be complex, and the steps available to them were written in advance, not selected by a model in response to what it finds.

Where the concept stops

Agentic describes how a system works. It does not say how well it works, how much autonomy it has been given, under whose authority it acts, or whether its results were verified. The term is also applied generously in marketing, sometimes to software with no loop and no decisions of its own. When the distinction matters, the concrete questions are more useful than the label: who set the objective, which decisions were delegated, what the system can reach, what stops it, how completion is established, and what record remains of the path it took.