Start with one real workflow, not a feature list. Write down the task and name who owns the result. Then check each AI agent platform against two lists: can operations build and watch the work, and can IT control sign-in and tool permissions. Finish with a short pilot on real work.
This guide is for operations leads and the IT people who approve tools. It does not assume any vendor, and it also covers when an agent platform is the wrong choice.
What should you decide before you look at any platform?
Decide on one workflow, one owner and one description of a good result. A demo shows what a platform can do in general, so judge it on your own workflow instead.
Pick a task that someone on your team does every week and can explain in a few sentences. Write down the systems it touches. If you cannot name an owner, stop there.
Australia’s National AI Centre publishes implementation guidance for AI adoption with six essential practices. The first is to decide who is accountable. The list also includes testing and monitoring, and keeping human control.
Also decide which actions need a person to approve them before they happen. A draft email to yourself is low risk. A message to a customer or a change to a record is higher risk. Settle that before you talk to vendors, then ask each one how it works.
What should operations check?
Operations should check whether a non-developer can build the agent, see what it does and keep it running. If only an engineer can change it, process changes wait for engineering time.
Put these questions to each platform:
- Can someone describe a task in plain language and see the plan before anything runs?
- Are there templates for common jobs, so the first agent is not built from nothing?
- Can the agent run on a schedule or start from an event, such as a new email or a webhook?
- Can you watch each step while it runs, and stop it?
- Who updates the agent when the process changes, and how long does that take?
Try these in a live session. Ask the vendor to build something small from your workflow while you watch, and note whether they need to open code.
What should IT check?
IT should check four things: who can sign in, what each agent can touch, how it connects and what record it leaves.
The OWASP GenAI Security Project describes a risk it calls excessive agency. It says the cause is typically one or more of three things: too much functionality, too many permissions or too much autonomy. It advises limiting the tools an agent can call to the minimum necessary. It also advises requiring a person to approve high-impact actions before they happen.
Turn that into questions for the vendor:
- How do users sign in, and what roles exist?
- Can you give an agent only the tools and permissions its job needs?
- How can a person approve a high-impact action before it goes ahead? Ask the vendor to show you.
- How does the platform connect to your internal systems?
- Which models can you use, and where do they run?
- What record does each run leave, and who can read it?
- What does the vendor store about your data, for how long, and is that in writing?
- How do you export your agents and data if you leave?
On connections, ask about MCP. The Model Context Protocol is a standard for connecting AI applications to external systems. If a platform supports it, you can often connect a system that already has an MCP server, without waiting for the vendor to build a connector. Ask which kinds of MCP server it supports. Our guide to MCP explains it.
For the controls that matter once an agent is in production, see our post on enterprise AI agent governance. The Australian Signals Directorate also publishes cyber security questions on engaging with artificial intelligence, to help organisations think through the cyber security side of using AI systems.
For a wider framework, NIST offers its AI Risk Management Framework. NIST says it is intended for voluntary use. It dates from January 2023, and version 1.0 is being revised.
Which questions should you ask every vendor?
Ask every vendor the same questions and get the answers in writing. The table gives the reason for each question and what a good answer looks like.
| Question to ask | Why it matters | A good answer looks like |
|---|---|---|
| Which actions can an agent take without a person approving them? | OWASP names excessive autonomy as a root cause of excessive agency. | You choose which actions wait for approval, and the vendor demonstrates it. |
| How are tool permissions set? | An agent with access to every tool can do more damage when it makes a mistake. | Permissions are set per agent, can be narrow, and your admin can change them. |
| How does it connect to our systems? | Your workflow lives across several systems. | Connectors for the tools you use most, plus a documented way to reach the rest. |
| Which models can we use, and where do they run? | Model choice affects cost, quality and where your data goes. | A clear list of supported models and a written answer on where they run. |
| What record is kept of each run? | You need to explain what happened when a result is questioned. | A readable log of each step, tool call and result that your team can open. |
| What do you store about our data? | The answer must match the contract and your policies. | A written answer on what is kept and for how long, consistent with the terms. |
| How do we leave? | Exit terms are easier to agree before you depend on the platform. | You can export agents, knowledge and records, and the vendor states what happens to your data. |
For a view of how named vendors compare, see our comparison of enterprise AI agent platforms. This post stays vendor-neutral.
How do you run a pilot?
Run a short pilot on the real workflow you chose, with a fixed end date and a named owner. Real work shows where the agent needs more instructions.
- Write the success test first. Describe what a good result looks like, using last month’s output as the reference.
- Give the agent only the access the task needs. Add more later if the pilot shows a gap.
- Decide which actions need a person to approve them, and set that up before the first run.
- Run the agent alongside the current process, and compare its output with the human version each time.
- Read the run records. Check that each step was sensible, as well as the final answer.
- Review at the end date. Decide whether to expand, change the setup or stop, and write down why.
The National AI Centre guidance lists testing and monitoring as a practice. A pilot is a practical place to start on both.
When is an AI agent platform the wrong choice?
An AI agent platform is the wrong choice when the steps never change or when one person only needs help drafting. Simpler tools do those jobs with less to maintain.
If the process has fixed steps and fixed inputs, a workflow tool or a scheduled script is easier to predict. An agent adds value when the sources or the wording vary and someone has to make small decisions.
If one person wants help writing, summarising or researching, an assistant is enough. It answers when asked and does not act on its own. Our post on agents versus assistants explains the difference. An agent platform takes more effort to govern, so pick one only when the task needs it.
Where does Xagent fit?
Xagent is an enterprise agent platform by Xinference. You describe a task in plain language. It writes a plan, shown as an execution graph with a card for each step, then runs it with tools. Every tool call and result is visible while the task runs, with the token count, and you can pause a running task.
You can save a task as an agent and run it again or schedule it. Native connectors cover Google, Microsoft, Meta and LinkedIn, and other systems connect through MCP servers. It works with open models and any OpenAI-compatible endpoint, or models self-hosted through Xinference. It has run logs and traces, and sign-in is with Google (OIDC). Plans and prices are on the pricing page. To test it against the workflow you chose, book a demo.
Questions
What is an AI agent platform?
It is software where you give an agent a goal, and the agent plans the steps and uses tools to carry them out. A platform adds the parts around that, such as building, scheduling, connecting to your systems and keeping records.
Should we pick a no-code platform or a developer framework?
It depends on who will maintain the agent. If operations staff will change it as the process changes, choose a platform they can use without code. If an engineering team needs custom logic, a framework gives more control but needs more upkeep.
How do I decide which AI agent to use?
Start from the workflow, not the tool. Write down the task, its owner and what a good result looks like. Then test two or three options on that same task in a pilot.
What is the best AI agent platform for a small business?
There is no single best platform, because it depends on the task. Pick the platform that does your chosen task well in a pilot, at a price you can confirm before you commit.
What questions should we ask an AI agent vendor?
Ask about approval of high-impact actions, tool permissions, connections, models, run records, data handling and exit. The table in this guide gives a good answer for each, and you should request the answers in writing.
Try Xagent. See all use cases, or book a demo on your own workflow.
