What to look for in an agentic AI platform

An agentic AI platform gives AI agents a place to carry out multi-step work, use permitted tools and deliver a finished result from an initial brief. Unlike a chatbot that answers questions or calls a tool on request, an agent works towards an assigned outcome, handles intermediate steps and stops when it reaches a decision that needs human judgement.

The distinction can be hard to spot on a product page. A chat window connected to email, search and a spreadsheet may look agentic during a short demonstration. The better test is what happens when a task encounters conflicting information, missing permissions or an action that affects someone outside the workspace. Four properties help separate a working agentic platform from a chatbot with extra tools: persistent task execution, bounded tool access, explicit decision boundaries and a traceable record of work.

1. The agent owns a task, not just a turn

Suppose you ask an agent to prepare a briefing on three competitors. It needs to find relevant sources, compare claims, check publication dates and assemble a document. If one source turns out to be outdated, it should revisit the research rather than copy the information into its answer and move on.

That requires the system to retain the assignment's purpose across multiple steps. It also needs a stopping condition. The brief should define the expected deliverable, the scope of the work and a budget. If a necessary fact is missing, the agent should ask a useful question or state the limitation instead of filling the gap with a guess.

Test this during a demo by assigning a task with several dependent steps and leaving one piece of information unavailable. Watch whether the agent identifies the gap and asks for clarification. Then change one requirement halfway through. Can it adjust the work without dropping the original constraints? A polished first answer does not establish that the system can manage an assignment.

2. Tool access has boundaries

An agent becomes useful when it can read a mailbox, consult a project record or prepare a document. Yet the number of available integrations tells you little about how access is controlled. What matters is which information and actions are available to the agent for a particular assignment.

A support triager may need to read incoming messages and draft replies. It does not necessarily need permission to delete customer records or issue refunds. A research analyst may need selected documents but have no reason to send emails. Broad access creates avoidable risk when an instruction is misunderstood or the task changes.

Use a demo environment or sample records to test the boundary. Ask the agent to perform one permitted operation and one that falls outside its scope. It should complete the first and stop at the second, explaining what is missing. Then ask it to connect another service or widen its access. That request should go through authorisation rather than becoming an unnoticed side effect of the original brief.

3. Preparation is different from authority

An agent can prepare an action without having permission to carry it out. Drafting a refund recommendation is different from moving money. Preparing an announcement is different from publishing it. If the system treats preparation and execution as one continuous permission, a routine task can end in a commitment nobody intended to make.

Look for a checkpoint before an action affects the outside world. The reviewer needs to see the exact proposed action, its recipient or target record, the cost so far and any deadline. A card that says only "Continue?" gives the person too little information to make a sound decision.

The reviewer must be able to change or reject the proposal as well as approve it. The system should respect that decision instead of trying the same action through another route. Certain operations should always require a person, including first contact with someone outside the workspace, payments, public publishing, accepting terms, changing permissions and acting in another workspace.

Test the checkpoint with a draft email. Ask the agent to prepare it for sending, then inspect the pending action before approval. Confirm that the recipient and exact message are visible. Reject the proposal and verify that nothing is sent. Next, change the message and check that the revised action returns for review. An approval button alone proves little. The important question is whether the person controls the action that actually happens.

4. Every run has a cost limit and a record

Multi-step work can take unexpected turns. A source may be unusable, a tool call may fail or the agent may need another search. Without a defined stopping point, a small assignment can consume more credits than its owner intended.

A hard budget cap sets a financial limit before execution begins. The platform must enforce it rather than rely on the agent to decide when it has spent enough. Ask what happens at the limit. Does the run stop, wait for a decision or return an incomplete deliverable? The behaviour should be clear before the team depends on it.

A separate activity record lets a person reconstruct what happened. It should record tool calls, approvals and policy changes, including the decisions that interrupted or redirected the work. A generated explanation from the agent is not a substitute for an inspectable history of events.

During a demo, open the history of an actual run. Find the original brief, the operations performed, an approval decision and the resulting deliverable. Check whether policy changes appear in the record and whether earlier entries can be altered without evidence. Then set a small budget for a task that requires several operations and observe what happens when the cap is reached. A promised limit and an enforced limit are different things.

Test the four properties in one assignment

A demonstration designed to succeed tells you little about how a platform behaves under pressure. Choose a task your team might genuinely delegate, such as preparing a supplier briefing or drafting a support response. Use sample data if the assignment involves private information or external actions.

1. Write a brief with a specific deliverable, a defined scope and a fixed budget. Include a question the agent must investigate rather than answering it in the instructions.
2. Introduce an outdated source or conflicting claim. Check whether the agent investigates the discrepancy and records uncertainty instead of presenting an unsupported answer as fact.
3. Include an operation outside the agent's permissions. Check that it stops and explains the boundary instead of attempting an unauthorised workaround.
4. Ask the agent to prepare an external action, such as sending a message. Inspect the proposed action, then edit or reject it. Verify that the system respects your decision.
5. Review the activity history, budget and deliverable. Establish what was completed, what remains unfinished and which decisions still need a person.

Judge the system by what you observe, not by what the presenter promises. If a permission boundary depends on someone noticing a problem in time, or a rejection does not reliably prevent an action, treat that as a gap to resolve before expanding the trial.

Choose a first delegation you can inspect

Start with work that has a clear output and a low cost of being wrong. Research preparation, inbox triage and meeting briefs are reasonable candidates because a person can inspect the result before it becomes an external commitment. Keep payments, public publishing and changes to important records out of the first trial.

At Delagents, we are building a workspace around this pattern. A person writes the brief, an agent carries out the work, checkpoints wait for sign-off and the result arrives as a deliverable. The approvals inbox presents external actions as cards that show the exact action, cost so far and deadline. A person can approve, change or reject each proposal. Every delegation also has a hard budget cap and an append-only activity log. Our product overview explains the workspace and its approach to delegated work.

Before your next vendor demo, write one assignment your team can safely test with sample data. Specify the deliverable, permitted actions, the decision that must return to a person and the maximum spend. Include one failure case, then ask the vendor to run the assignment without skipping it. Record what the platform does at each checkpoint. That evidence gives you a practical basis for deciding whether the system is ready for a larger trial.