The industry has largely converged on what an AI agent is, but not all product labeling has caught up. There are tools that adopted the term early and use it for things that are not agents under the current definition. An “agent” in a product menu may or may not reflect what the term means now, which makes it worth stating the definition clearly before we get to examples, a working proof of concept, and why NetApp is a good fit for Agentic AI.
What Actually Makes Something an AI Agent?
Most modern agents operate in some variation of the following cycle:
- Observe: Gather information from the user, files, databases, APIs, or other systems.
- Reason: Decide what the information means and what should happen next.
- Act: Call tools, execute code, update records, send messages, or perform other tasks.
- Evaluate: Check if the goal has been achieved and whether another cycle is necessary.
Throughout this cycle, agents often maintain state that carries observations, hypotheses, previous tool results, or other context forward between iterations.
The autonomous loop is the core differentiator between an AI workflow and an AI agent:
- AI workflow: The execution steps are determined in advance by code or by a fixed chain of prompts. The LLM performs reasoning within a step but cannot change direction on its own.
- AI agent: The model dynamically determines the next step and selects tools based on observations. It loops until it fulfills the objective or hits a pre-defined boundary.
Now, let’s level set a few things that may not align with the hype:
- Sometimes, an AI workflow is a superior choice to a truly agentic AI solution. Also, and brace yourself for this, a workflow without AI being used at all may still be the best choice!
- Agentic AI is most appropriate when you can’t solve the problem with a structured workflow because you cannot predict what the workflow will need to do. Escalate to using AI in a workflow or as an agent only when one of the simpler options does not solve the problem.
- Human interaction may be part of using an AI agent. If the human is inserted to do something like ensure cost control or confirm potentially dangerous steps, this is not making it less agentic; it makes it a more mature implementation.
Examples of AI Agents
Microsoft Copilot Agents
- What it is: A persistent assistant that scales from a simple prompt shortcut into an active workflow helper.
- How it works: At its simplest, an MS Copilot agent may be nothing more than a packaged prompt, which is more of a naming convention holdover than an agent in the current sense. An MS Copilot agent can also operate in true agentic fashion with connections to enterprise knowledge sources, APIs, and business applications.
- The Goal: Workflow automation. Depending on the configuration, it can retrieve information, orchestrate business processes, invoke workflows, and interact with enterprise systems.
Claude Code Subagents
- What it is: An ephemeral developer tool.
- How it works: It is often driven by a plain text Markdown (.md) file containing instructions and metadata. The configuration may establish context, specify the model, and grant access to local tools. The subagent will evaluate the task, invoke tools, analyze results, and repeat this until the objective is met.
- The Goal: It uses an isolated context to perform research or analysis without polluting the main conversation context. Once complete, it returns a concise summary and disappears.
The Enterprise Agentic Application or Microservice
- What it is: A full-scale application exposed through APIs, webhooks, or other interfaces such as a web browser. This is the type of agent I wrote as a proof of concept and describe later in this article.
- How it works: This is where the LLM becomes a component inside a larger software architecture. The application may receive unstructured input such as log files, emails, documents, support tickets, or chat messages. The LLM extracts meaning, intent, classifications, and possibly creates structured data using various tools and self-evaluation of what needs to be done as an iterative process. Traditional software may then be used to execute business logic or share results with a human operator.
- The Goal: Combine human-language understanding with reliable conventional software systems to automate analysis or actions when the steps required may not be fully known in advance.
A final word on these examples: if you previously created something your framework called an AI agent that doesn’t meet the modern definition, this is completely normal. The term settled into its current meaning fairly recently, and some tools still use it loosely. My goal here is simply to bring some clarity to the current landscape.
The Reality of Enterprise Autonomy
Despite the marketing hype, most enterprise agents are not fully autonomous. A common pattern looks like this:
Analyze -> Recommend -> Request Approval -> Execute
Organizations typically want humans involved before actions such as modifying infrastructure, updating production systems, approving financial transactions, or communicating with customers. As a result, many successful agents function more as intelligent assistants than fully independent workers.
An example in the NetApp Ecosystem
For a working example of an AI agent, I used Claude Code to build a proof of concept called the ONTAP EMS Log Agent. This is a small web app that ingests NetApp ONTAP EMS events and turns them into a short list of risks that a storage administrator should look at, with the agent’s reasoning attached to each one. The code is available here: https://github.com/arndt-netapp/emsagent
The EMS Log Agent runs in two stages; the first is an AI workflow while the second is the AI agent.
Stage 1: A broad scan of all EMS events ingested from a cluster over a specified event count or a time window. The events are deduplicated, summarized, and handed to a single Claude Sonnet 5 API call to return a ranked list of candidate patterns worth further investigation. This stage uses no tools, and no loop; it is simple pre-processing and a prompt to the LLM along with the data. With Claude Sonnet 5, this stage runs about $1.25 per 10,000 events and the token cost scales linearly with event count.
Stage 2: A human picks a candidate from the ranked list we got in Stage 1 and the investigation of this candidate starts a real agent loop that uses up to nine tools included in the package. Tools include the ability to look up event meaning in a static ONTAP EMS message catalog, flag abnormal event rates, check whether a human had already dismissed this pattern, query the live cluster state via REST API, record a hypothesis, and declare when the investigation is complete. Stage 2 is agentic based on the following properties:
- Observe: the agent gathers information related to the EMS candidate being analyzed via the tools previously described.
- Reason: the model determines what the information means and what to check next.
- Act: The model controls the loop and tool use, not pre-determined code. By design, its actions are confined to recording its own findings; it makes no changes to the storage system.
- Evaluate: The model decides when it is done, bounded by a token cost budget of $0.50, and it can determine if an investigation reveals no concern at all.
The agent also uses state as it revises a hypothesis across the loop, and this allows an investigation that hits the $0.50 budget limit to still return something.
In addition to the above agentic properties, note that the path taken by the agent is non-deterministic and therefore must be auditable. Every tool call the agent makes is rendered in the web UI as an expandable trace for the candidate that was investigated. The app also learns from human judgment without code change, with the human's stated reason for dismissed findings included in the prompt of the next EMS event scan. Finally, the human gate between the initial report and the deep agentic investigation is by design, as token cost is a real concern!
I should also be honest about what this POC example does not do, and where it could go from here.
- There is no authentication in the web UI.
- The tool to get current cluster state could be expanded with additional subsystem checks.
- It is not integrated with any ONTAP performance telemetry such as the Harvest MCP Server (
https://netapp.github.io/harvest/nightly/mcp/overview/
).
- It is not intended to make changes to a running system via something like the ONTAP MCP Server (
https://netapp.github.io/ontap-mcp/nightly/
).
- One could envision many other potential enhancements down the road, such as reaching out to NetApp documentation or knowledge base articles as part of an EMS event investigation.
Why NetApp for Agentic AI
If you made it this far, thank you for reading! While this is not an exhaustive list, here is how NetApp provides the foundation for an agentic architecture:
- Deploy anywhere: We solve data gravity, as agents cannot observe what they cannot reach. NetApp solutions run the same on-premises and as a first-party service in all three major public clouds (https://www.netapp.com/unified-storage/). We can put your data where you need it when you need it, and you can operate identically no matter where it is.
- Security: Because agents may have the power to act on your environment, securing the data layer is a requirement. ONTAP provides industry-leading security (https://www.netapp.com/cyber-resilience/) with features such as Autonomous Ransomware Protection, Multi-Admin Verification, and immutable backups.
- APIs and MCP servers: NetApp has wide coverage for our storage systems and management plane with industry-standard and mature REST APIs, as well as a variety of MCP servers ready to plug into your AI workflows and agents (https://github.com/NetApp/mcp).
Final Thoughts
An agent is not a new species of software. What is new is that a model steers the loop rather than pre-determined code, and everything that makes the loop safe to deploy is ordinary engineering: a budget, a human gate, and a trace of the steps it decided to take.
