Agentic AI is software that uses artificial intelligence (AI) to choose steps and use tools to complete a task. At its center is an AI model: software trained to interpret information and generate responses. You give the agent a goal, such as “investigate this customer’s delivery problem.” The system can look up an order, check its status, and prepare a response within the permissions you give it.

That ability can reduce repetitive work, but it also creates new responsibilities. A system that can update records or send messages needs clear limits, testing, and a way to involve a person.

This guide uses a customer-support example to explain how agents work. It also covers when to use them, how to measure their value, and what to check before a pilot reaches real users.

An example: handling a delivery question

Imagine a customer writes, “My order has not arrived. Can you help?” A support agent might read the message, find the order, check the delivery service, and decide what to do next.

An AI agent can assist with those steps if you connect it to the required systems. Those connections are its tools: functions that let it look up information or perform an action.

A limited support agent could follow this process:

1. Read the customer’s question.
2. Look up the order through an authorized account connection.
3. Check the delivery status.
4. Read the company’s policy for that situation.
5. Draft an answer using the information it found.
6. Send the draft to a person for review if the policy requires approval or the case is unclear.

The agent might choose a different next step for a missing order number or a failed delivery. That flexibility is useful, but the system must enforce the limits. For example, permission to read an order should not automatically include permission to issue a refund.

How is an agent different from a chatbot or an automated workflow?

These categories overlap. A chatbot can be the interface to an agent, and a fixed workflow can use AI for individual steps. The useful question is who or what chooses the next action.

A fixed workflow can handle natural-language input by including an AI step. It can also handle many exceptions if developers define the rules. An agent becomes useful when the next step depends on information discovered during the task. Anthropic’s guide to building effective agents describes this distinction between predefined workflows and model-directed actions.

If a simple rule solves the problem reliably, start there. Extra flexibility also creates more behavior to test and monitor.

What happens inside an agent system?

The AI model is one part of the system. The surrounding software supplies information, controls access, executes permitted actions, and records the result.

A typical agent repeats a short cycle:

1. Read the request and the information available so far.
2. Choose an allowed next action.
3. Ask the surrounding software to run the tool.
4. Read the tool’s result.
5. Continue, finish, or ask for human help.

The software should limit how many steps the agent can take and how much it can spend. It should also stop actions that exceed the agent’s permissions.

Checks do not make the agent infallible. The model may misunderstand a request, select the wrong tool, or invent a detail. A convincing answer or a high self-reported confidence level is not proof that the task succeeded. Check the result against source records and explicit rules wherever possible.

Connecting those checks to the business’s actual systems is a major part of AI integration work.

Where could an agent help your business?

Look for repeated tasks where people gather information from several places and choose the next step. You also need a clear way to judge the result and handle mistakes.

These are possible starting points, each with a limited initial role:

Start with drafts or suggestions when an incorrect action would be difficult to reverse. Expand permissions only after you have evidence that the system handles the task reliably.

Measure the value before expanding

Record how the task works today. For the delivery-support example, useful measures include time to prepare a reply, correctness, and how often another person must intervene.

Then compare the pilot with that starting point. Include the time employees spend reviewing and correcting the agent’s work.

For example, suppose a reply previously took 10 minutes to prepare. If an agent creates a draft in 1 minute but review and correction take 8 minutes, the saving is small. If the draft takes 1 minute and review takes 2 minutes, the potential saving is larger. These are illustrative numbers; measure your own workflow before making a business case.

Track cost per successfully completed task, not just cost per AI request. One task may require several model calls, tool requests, and a human review.

Build, buy, or work with a development partner?

Choose based on the workflow, required system connections, data needs, and the people available to maintain the result:

Test each option with representative examples from your workflow. A polished demonstration is useful, but it does not show how the product handles your exceptions, access rules, or workload.

What to include in the budget

Model usage is only one cost. A complete budget should include:

• System connections: Reading and updating the required business records.
• Testing: Preparing examples and checking results after changes.
• Hosting and tools: Running the surrounding software and connected services.
• Monitoring: Tracking failures, response times, and spending.
• Human review: Checking outputs and resolving exceptions.
• Maintenance: Updating the system when policies, tools, or models change.

There is no fixed percentage that model usage contributes to every project. The share depends on task volume, model choice, number of steps, and review needs. Ask for estimates tied to those assumptions and a plan for measuring actual costs during the pilot.

Set clear limits before launch

For the support example, write down which customer records the agent may read, whether it can send replies, and which actions need approval.

Before involving real users, establish these controls:

1. Restricted access: Give the agent only the data and tools needed for the task.
2. Approval rules: Require a person to approve actions such as refunds or account changes when appropriate.
3. Clear handoffs: Route missing information, conflicting records, and failed tools to a person.
4. Action records: Record what tools ran and what changed, while limiting sensitive information in logs.
5. Usage limits: Cap steps, retries, and spending so a failed task cannot run indefinitely.
6. A way to stop: Let operators disable the agent and return work to the existing process.

Test these controls deliberately. A rule written in the model’s instructions should not be the only barrier preventing an unauthorized action.

A sample 90-day adoption plan

Use this as a sequence for planning, not a guaranteed delivery schedule. Data access, security review, and system complexity may change the timing.

Days 1–14: Define one task

Choose a repeated task and measure its current time, cost, and error rate. Collect representative examples, including difficult cases. Agree on what success means and what the agent is allowed to do.

For a support pilot, the goal might be to reduce drafting time while maintaining the team’s agreed accuracy standard. Decide how reviewers will measure both.

Days 15–45: Test a limited pilot

Connect only the tools needed for the task. Start with human review before actions affect customers. Record results, review time, failures, and cost per completed task.

Test more than the expected path. Include missing records, conflicting information, failed connections, and requests outside the agent’s role. Use the results to improve the system and decide whether it is ready for a limited release.

Days 46–90: Expand if the evidence supports it

If the pilot meets the agreed quality and cost targets, increase usage gradually. Assign an owner for ongoing monitoring and run the quality checks again when the model, instructions, or connected systems change.

If the pilot misses its targets, revise the approach or stop. A useful pilot gives you evidence for that decision, even when the decision is not to expand.

Questions to ask an AI development partner

Ask a potential partner to explain the following in terms your team can verify:

• Which similar tasks have their systems handled for real users?
• How will they measure success and test difficult cases?
• How do they enforce tool permissions and approval rules?
• What happens when a tool fails or answer quality drops?
• How will you see costs and errors for each workflow?
• Who will maintain the system and help your team operate it?

Ask to see test results and operating instructions alongside the demonstration. These make it easier to judge whether your team can rely on the system after launch.

Frequently asked questions