An AI agent is software that can interpret a request, identify a goal, break work into tasks and use tools to execute them with limited human direction, according to Proofpoint. That ability to act distinguishes it from generative AI that only responds to a prompt.
At a glance
- An AI agent plans, decides and acts through connected tools or applications, according to Proofpoint.
- A model can propose an action, but surrounding software must validate and execute it.
- Unreal Agent separates sessions, model turns, tool translation and durable operations.
- AnyJev measures typed decisions in isolation and says agent-loop evaluation remains unfinished.
- Builders should give agents limited permissions, record actions and require approval for high-risk work.
What is an AI agent?
An AI agent is software that can interpret a goal, choose a next step, use an external capability and react to the result. Proofpoint describes agentic AI as systems that can plan, decide and act across enterprise systems with limited human direction.
This separates an agent from a chatbot. A chatbot can answer a question or draft text. An agent can also query a database, call an application programming interface, update a record or invoke another application when its deployment gives it that authority.
The word “agent” does not guarantee autonomy, reliability or safety. It describes an action loop. Builders should ask what the system can read, which actions it can request, what checks occur before execution and who is accountable when it makes a bad choice.
FuturPulse working definition: an AI agent combines a decision-making component, software that prepares and executes actions, and controls that limit what those actions can do. This is a practical engineering boundary, not a formal standard.
| Layer | Its job | What it is not | Builder question |
|---|---|---|---|
| Model | Produces text, classifications, plans or proposed tool calls. | Not the actor with permissions or the software that executes work. | Can it produce a useful recommendation? |
| Harness | Runs sessions, builds context, validates tool calls and records results. | Not necessarily the part that decides whether an action is allowed. | Can it recover from failures and preserve history? |
| Decision controller | Selects, constrains or approves the next action against a goal and policy. | Not merely a model-output parser or an API wrapper. | Who can stop a risky action before execution? |
The three layers can live in one application or in separate services. The important point is their role. A model can suggest deleting a record, while a harness can format that suggestion as a tool request and a controller can reject it.
That rejection matters because model output is not authority. A fluent response can be wrong, incomplete or manipulated by untrusted text. A tool call should be treated as a request that requires validation, not as an instruction that automatically deserves execution.
Where is the boundary between the three layers?
The boundary is simple: the model proposes, the harness makes the proposal operable, and the controller decides whether the proposal may become an action. A system becomes agentic when those parts form a loop that can affect an outside environment.
A language model alone is not an agent. It can generate an answer, a plan or structured data. It has no durable state, tool execution path or independent permission unless software around it provides those functions.
A harness alone is not an agent either. Unreal Agent describes an asynchronous harness with a session inbox, coordinator, session store, context builder, model adapter, tool registry, tool translator and operation manager.
That structure makes the distinction concrete. Unreal Agent says its coordinator persists accepted inputs, runs model turns, resolves tool translators and dispatches committed operations. Its session store keeps canonical history and operation state, supporting recovery and forks.
Its tool translator validates a model-produced tool call and converts it into one or more operations. The translator does not perform input and output work itself. The operation manager handles durable operations separately.
This is useful design discipline. A model may ask to use a tool, but the translator checks whether the request matches the tool’s schema. The system can then record the request, submit the resulting operation and return a result to the model without treating the model as the direct operator.
A decision controller can be smaller than a model. It may be a rules engine, a permission service, a risk classifier or a human approval screen. Its basic choices are usually simple: run, ask, escalate or stop.
That means a system can be useful without full autonomy. A coding assistant that writes a patch remains an assistant if a developer decides what to inspect, edit and run. It becomes closer to an agent when it can inspect a repository, invoke tools, assess results and continue within defined limits.
What functions does an agent need?
Proofpoint describes five common parts of an agentic architecture: input, reasoning, planning, action and feedback. These are functions, not mandatory software modules.
Input is the event that starts work. It can be a prompt, file, alert, ticket, email or system record. The input should carry enough context to identify the requester, the task and the resource involved.
Reasoning interprets the task. In many current products, a large language model performs this role by turning a request into a proposed plan or tool call. That does not make the model a trusted policy engine.
Planning turns a broad objective into steps. An agent might need to find relevant records, compare options, request approval and then update an application. Planning can be explicit, with a visible task list, or implicit in repeated model-and-tool turns.
Action is the point where the system affects something beyond its own conversation. It might retrieve permitted data, create a support ticket, edit a file or send a request to another application. This is where permissions, rate limits and approval rules have practical consequences.
Feedback supplies the result of an action to the next decision. A failed query, a denied permission or a successful update should change what the system does next. Without feedback, a product can still automate a task, but it cannot reliably adjust a multi-step workflow.
Builders should not assume that every agent needs a browser, a vector database or a team of sub-agents. Those are implementation choices. The minimum useful loop is a goal, a permitted action, an observed result and a decision about what happens next.
Connected applications create the practical difference between an agent and a text-only assistant. Proofpoint says agents can take several actions in one workflow, including querying databases, calling APIs, updating records and invoking other applications. Those connections also expand the attack surface when they expose tools, APIs or sensitive data.
How do agent types differ?
Proofpoint groups enterprise agents by how they perceive information, make decisions and act. The categories overlap, so they are better treated as design patterns than fixed product labels.
- Reactive agents: respond to a current event using rules or learned patterns. They usually do not maintain long-term plans.
- Goal-based agents: compare possible actions against a defined objective and can plan a sequence of steps.
- Learning agents: change future behaviour using feedback, new data or observed outcomes.
- Autonomous agents: plan, decide, use tools and execute multi-step work with limited human oversight.
Workday similarly describes agents as a spectrum, from simple rule followers to systems that reason, learn and collaborate. This is a useful warning against binary labels: a product may automate one narrow action while requiring human approval for every consequential step.
Choose the least capable design that completes the job. A password-reset process may only need fixed rules and identity checks. A research workflow may need a goal-based system that gathers sources but leaves conclusions to a person.
A production deployment tool needs stronger controls than either. It may benefit from planning, but its authority to alter infrastructure should remain narrow. Approval points should protect irreversible, costly or privilege-expanding actions.
Agentic AI can combine probabilistic components, such as language models, with deterministic components that execute fixed rules. Workday describes that combination as orchestration across systems, often using deterministic components for execution. The distinction matters because a flexible recommendation and a controlled execution step solve different problems.
What do current projects show about the stack?
Open-source projects illustrate that an “agent” product can contain several distinct layers. A repository may offer a terminal interface, a model connection, a tool runner or a decision component without demonstrating complete autonomous performance.
| Project | What the project says it includes | What builders should infer |
|---|---|---|
| ZCode | An AI coding workbench with desktop, browser and terminal interfaces, plus Agent CLI and runtime source. | It packages an agent-oriented product stack rather than only a model interface. |
| Unreal Agent | A harness with sessions, model turns, tool translation and durable operations. | It shows the execution and recovery layer around a model. |
| AnyJev | A typed-decision system that returns choices and probabilities from model states. | It can support a controller, but it does not itself constitute a tool-using agent. |
ZCode’s repository says version 3.14.3 was updated on 23 September 2026. The repository includes client, backend, shared user-interface and Agent CLI components, and says its command-line distribution includes a terminal user interface, web mode and agent.
Unreal Agent offers a clearer view of the harness layer. Its documented session is an append-only persisted history that can be forked. Its inbox performs session-scoped deduplication of external, control and crash inputs.
AnyJev focuses on decisions rather than tool execution. It describes typed questions such as a choice, yes-or-no answer or score, and returns a probability that software can threshold. Its stated goal is to avoid generating or parsing a free-form answer for that decision.
The lesson is not that one project is more “agentic” than another. It is that builders should name the capability they are buying or building. A runtime, a harness, a decision head and a complete controlled workflow solve different problems.
Unreal Agent also separates a tool request from the work it causes. Its glossary defines a tool call as a model-produced request, while an operation is a serializable description of work produced by the translator for asynchronous execution. That split gives a builder a place to validate, record and constrain work before an external system changes.
What does the AnyJev comparison table measure?
AnyJev compares its zero-label L0 method with its L2 decision head across five Qwen3 models. The values below are reported accuracy scores for typed decisions, so they do not measure end-to-end agent task success.
| Model | L0 accuracy | L2 accuracy | Reported cost versus one forward pass |
|---|---|---|---|
| Qwen3-1.7B | 0.494 | 0.730 | 0.70× |
| Qwen3-4B | 0.564 | 0.786 | 0.69× |
| Qwen3-8B | 0.647 | 0.771 | 0.68× |
| Qwen3-30B-A3B | 0.630 | 0.799 | Not reported |
| Qwen3-32B | 0.700 | 0.798 | 0.84× |
The comparison shows that AnyJev reported higher L2 accuracy than L0 for each of the five listed Qwen3 models. Its results cover 20 questions, 300 labels and 2,000 held-out decisions, not live agent episodes.
That limitation matters. A decision component can improve a narrow routing choice while an agent still fails because it chooses the wrong tool, lacks context, hits an unavailable service or cannot recover from an earlier error.
AnyJev states that its headline decisions are scored in isolation rather than inside an agent loop. Its roadmap lists agent-loop evaluation, defined as testing the same decisions inside a real agent against the language model they replace, as future work.
The project also cautions that its typed-decision “accuracy” is agreement with a teacher model. Builders should not convert that result into a claim about factual correctness, business value or safe autonomy without evaluating their own task and risk conditions.
AnyJev says an L2 head is fitted for a specific question and model. Its documentation also says a downstream application can require a minimum decision level, causing code to refuse a weaker result. That is a useful controller pattern, but it does not replace checks on the action that follows.
Is ChatGPT an AI agent?
ChatGPT is not automatically an AI agent. A chat application that receives a prompt and returns text is a model-backed application, even if its answer includes a detailed plan.
Proofpoint contrasts generative AI tools, including ChatGPT, with systems that interpret a request, identify a goal, break it into tasks and use tools to execute them. The relevant question is the deployment, not the brand.
A configured chat product may have access to files, search, calendars or business applications. It becomes agent-like when it can select and invoke those capabilities, observe their outputs and continue the workflow with limited direction.
That still does not answer the governance question. Builders should identify which actions are automatic, which require confirmation and which are unavailable. A user interface that makes an action look conversational can hide a consequential permission decision.
How should builders control an agent?
Builders should treat an agent’s decision controller as a security boundary. It should know the agent identity, the requested action, the target resource, the task context and the rule that permits or blocks the request.
NIST SP 800-207 describes a zero-trust architecture with policy decision and policy enforcement functions. Applied to an agent, one component can decide whether an action is permitted while another enforces that decision at the tool gateway.
Zero trust does not mean trusting no software. It means not assuming that a request is safe merely because it originated inside an application. Each request should be evaluated against the resource, identity, policy and context involved.
NIST SP 800-53 provides a catalog of flexible security and privacy controls for managing organisational risk. Its listed control families include access control, identification and authentication, audit and accountability, configuration management and system integrity.
- Give each running agent a distinct identity rather than a shared administrator credential.
- Limit access to the specific tools and resources required for the current task.
- Validate tool arguments against a schema and business rules before execution.
- Record proposed, approved, blocked and completed actions in durable logs.
- Require human approval for irreversible, expensive or privilege-expanding actions.
- Define safe failure behaviour: stop, ask for clarification or escalate to a person.
These controls match risks identified by Proofpoint, including unauthorised actions, data exposure, privilege misuse and unsafe delegation across connected systems. Proofpoint recommends least-privileged access, monitoring, guardrails and human approval for high-risk actions.
Logs should capture more than the final outcome. A useful record links the initiating event, model proposal, policy decision, executed operation and returned result. That makes an incident easier to investigate and a broken workflow easier to repair.
Use separate permissions for reading and writing. An agent that can search customer records does not automatically need authority to change them. An agent that can draft a production change does not automatically need authority to deploy it.
NIST describes its controls as flexible and customisable within an organisation-wide risk-management process. That is important for agents because the same tool call can carry different risks in different contexts. Reading a public document and changing a payroll record should not pass through the same approval path.
What we could not verify?
No source cited here provides a universal technical test for the moment when a model-plus-tools product becomes an AI agent. The model, harness and decision-controller boundary in this article is a practical framework for builders.
We could not verify public end-to-end agent-loop results for AnyJev’s decision layer. AnyJev says its decisions are evaluated in isolation and identifies real agent-loop evaluation as unfinished work.
We also could not verify that any product described here is safe for a particular production workload. Safety depends on the tools connected, the permissions granted, the data handled, the recovery path and the review process around each deployment.
The next useful evidence will be task-level evaluations that report success, failures, cost, intervention rates and the effect of permission limits in complete tool-using episodes.
