Updated July 16, 2026. Product status and source links were checked against the official documentation cited below.
The label “AI agent” covers several kinds of product. Some agents browse websites and work with files. Others operate inside a company workspace, a software repository, or a custom application. The useful question is not, “Which agent is best?” It is, “Which kind fits this workflow, and what controls does it require?”
An agent can do more than generate text. It may select tools, retrieve information, maintain task state, and act across several steps. That creates more ways for work to drift, encounter bad data, use the wrong permission, or stop unexpectedly.
This guide explains the category, compares current product types, and provides a method for a bounded evaluation. The examples illustrate different designs; they are not a ranking or recommendation.
What an AI agent is—and is not
An AI agent is a system configured to pursue a defined outcome by choosing and executing steps with models, tools, data, or software services. The degree of independence varies. One agent may ask for approval before every external action; another may complete a background task until it reaches a checkpoint or limit.
A useful agent design normally has six parts:
- A goal: a task or outcome stated clearly enough to know when work is complete.
- Instructions and boundaries: rules that define what the agent may do, must not do, and should do when uncertain.
- Tools and data: approved access to browsers, files, business applications, code repositories, APIs, or other systems.
- State: enough context to track the task, intermediate results, decisions, and progress.
- An execution loop: a way to choose a next step, use a tool, inspect the result, and continue or stop.
- Oversight and recovery: approval gates, logs, cancellation, fallback paths, and a named person responsible for the result.
A language model alone is not an agent. A chat assistant that answers a question does not necessarily plan or act across a workflow. A builder or framework supplies components for creating an agent but is not, by itself, a finished agent.
These distinctions prevent feature-list comparisons between unrelated products. A personal web agent, workplace agent, coding agent, and development framework solve different problems.
Current agent product types, with defensible examples
General-purpose action agents
General-purpose agents combine tools for research, website navigation, file work, and connected services. OpenAI’s ChatGPT agent help page describes a visual browser, code execution, apps, and a terminal. It also says a task can pause for clarification or confirmation and can be guided or interrupted. Those controls matter because website content can contain misleading instructions and connected services may expose sensitive information.
Work-context agents
Work-context agents operate inside a collaboration environment. Microsoft’s Cowork application card describes multi-step work across Microsoft 365, visible actions, existing permission boundaries, and explicit approval before sensitive actions. Users still need to review generated content, recipient choices, file operations, and exceptions.
Personal background agents
Some agents continue tasks or run recurring work without keeping an application open. Google’s official Gemini Spark overview describes background, multi-step tasks, optional Google app connections, and checks before major actions. For work that runs over time, users need a clear view of active tasks, connected data, action history, and a way to pause or stop it.
Coding agents
Coding agents work with repositories, branches, tests, and pull requests rather than a general desktop. GitHub’s Copilot cloud agent documentation says the agent can research a repository, create a plan, change code on a branch, and let a developer inspect the diff and iterate before creating a pull request. GitHub also documents an ephemeral development environment for running tests and linters. The reviewable unit is important: a coding agent should produce inspectable changes, not bypass the repository’s normal testing and review controls.
Agent-development frameworks
Teams building their own workflows can use a framework instead of adopting a finished product. The OpenAI Agents SDK documentation covers orchestration, state, guardrails, approval flows, tracing, and evaluation. These are implementation capabilities, not proof that an application is ready for production; the team still owns tool permissions, failure handling, testing, monitoring, and user experience.
Framework status also changes. Microsoft’s official AutoGen repository notice now says AutoGen is in maintenance mode, will not receive new features or enhancements, and is community-managed. It directs new users to Microsoft Agent Framework. Existing AutoGen projects therefore need an explicit maintenance or migration decision rather than an assumption that the original framework roadmap is continuing.
Start with workflow readiness, not a product name
An agent is easier to evaluate when the underlying work is already understandable. Before selecting a product, write down the workflow in plain language and look for these conditions:
- A narrow objective: the intended output or action is specific, with a clear stopping point.
- Known inputs: the files, systems, data sources, and instructions required for the task are identified.
- A reference process: a person can explain how the work is done today, including common exceptions.
- A named owner: someone is accountable for configuration, approvals, incident response, and periodic review.
- Bounded access: the agent can be given only the tools, data, and permissions required for the task.
- Observable work: inputs, tool calls, outputs, approvals, and errors can be inspected at an appropriate level.
- A recovery path: work can be paused, cancelled, reversed where possible, or handed to a person without losing essential context.
If the process has no stable owner, mixes many unrelated goals, or relies on undocumented judgment, adding an agent will not make those gaps disappear. A smaller task—such as preparing a draft, reconciling a defined set of records, or proposing a code change for review—usually creates a clearer first evaluation than an open-ended instruction to “handle everything.”
Match oversight to the action, not the interface
Conversational interfaces can make a complex workflow feel informal. Oversight should instead follow the data accessed and the actions available.
For a read-only research task, source traceability and factual review may be the main controls. For a task that drafts messages or changes files, add a review checkpoint before the output is shared or committed. For an agent that can send, publish, delete, purchase, change permissions, or trigger another system, use least-privilege access and explicit confirmation at the point of action. Where an action cannot be reversed, the approval should show the exact target and proposed change rather than a vague summary.
The NIST AI Risk Management Framework offers a useful lifecycle structure: govern the process, map the context, measure performance and risk, and manage identified issues. For a small agent pilot, that can be translated into four practical questions:
- Govern: Who owns the workflow, approves access, and decides whether it should continue?
- Map: Which people, data, systems, and downstream decisions can the agent affect?
- Measure: Which normal, edge, and adversarial tasks will be tested, and what counts as failure?
- Manage: How will permissions be reduced, incidents be handled, and the agent be paused or retired?
A practical agent evaluation checklist
Evaluate an agent against a representative task set rather than a polished demonstration. Include routine work, incomplete inputs, conflicting instructions, unavailable tools, and content that attempts to redirect the agent.
- Task fit: Does the agent address the defined workflow, or does it require a broader and riskier scope to be useful?
- Completion criteria: Can reviewers determine whether the task finished correctly, partially, or not at all?
- Evidence quality: Does research preserve descriptive source links and distinguish retrieved facts from generated interpretation?
- Action accuracy: Are the selected tool, target, parameters, and sequence correct before an action is approved?
- Control behavior: Does the agent stop at required checkpoints, respect a cancellation request, and avoid retrying a blocked action through another route?
- Permission discipline: Can access be limited by user, repository, folder, application, action, or session? Are unnecessary connections disabled?
- Exception handling: What happens when data is missing, a page changes, authentication expires, a tool fails, or instructions conflict?
- Auditability: Can an authorized reviewer reconstruct the important inputs, actions, approvals, outputs, and errors without exposing more sensitive data than necessary?
- Operational ownership: Who reviews changes to models, tools, prompts, integrations, product availability, and vendor documentation?
Record both successful and failed runs. Averages can hide the failure that matters most, so retain examples of incorrect actions, unsupported statements, missed approvals, and incomplete recovery. The evaluation should also compare the agent with the existing process using the same task definitions; otherwise, a change in scope can be mistaken for an improvement.
A bounded pilot method
- Select one workflow. Choose a repeatable task with a defined owner, limited systems, and reviewable output.
- Map the boundary. List required data, tools, permissions, external recipients, irreversible actions, and escalation points.
- Define the test set. Prepare ordinary cases, edge cases, intentionally ambiguous requests, tool failures, and adversarial content relevant to the workflow.
- Set gates and stop rules. Decide which actions require approval, which errors end a run, and when work must transfer to a person.
- Run in a contained environment. Start with read-only or sandbox access where possible, inspect logs and outputs, and correct the process before expanding access.
- Use supervised production. Keep a human reviewer in the loop, document failures, and expand only after the evidence supports a wider scope.
This method does not guarantee that an agent will be appropriate. It creates a disciplined way to discover whether the workflow, controls, and product fit together before permissions or reliance expand.
Use the directory as a discovery layer
The Kingy AI Agent Directory can help you explore agent categories and find products relevant to a workflow. Treat a directory listing as the start of due diligence, not the final decision. Confirm the current product status, capabilities, permissions, data handling, controls, and availability in the vendor’s official documentation before beginning a pilot.
The durable approach is simple: define the job, limit the boundary, make actions observable, test failure paths, and keep a responsible person in control. Agent products will continue to change, but those evaluation principles remain useful across personal, workplace, coding, and custom-built systems.
The Kingy Brief
Follow The Kingy Brief.
One consequential launch, one pricing, limit, or shutdown change, one hands-on test, one exact prompt or Test Pack, and one try / watch / skip verdict.
Free · Choose your subjects · Double opt-in · Unsubscribe anytime