What we mean by an agent
An AI agent is software that uses a language model to decide which steps to take, then takes them through tools: searching documents, calling APIs, updating records. The difference from a chatbot is action. The difference from traditional automation is judgment.
That judgment is as risky as it is useful, which is why the design work matters more than the model choice.
Where agents work well today
Agents are strongest when the goal is clear, the information they need is reachable through tools, and mistakes are cheap to catch. These jobs fit that description:
- Research across internal documents and systems
- Turning documents into structured records
- Drafting replies, reports and follow-ups for review
- Routing and triaging requests, with the reasoning shown
Where they still struggle
Long chains of dependent decisions, vague goals and actions that are hard to reverse remain difficult. An agent that's right 95 percent of the time on each of ten steps is right about 60 percent of the time end to end.
That arithmetic is why we keep people approving high-impact steps and design agents around short sequences that can be checked.
Choosing your first agent
Score candidate processes on volume, value per task, data availability and reversibility. The best first agent usually handles a frequent task where someone already reviews the output. It saves time without adding new risk.
Governance you'll need before the second agent
Three things: an inventory of agents and what each can access, logging that records every action, and a review process for widening permissions. None of them are hard to set up early. All of them are painful to retrofit once ten teams have their own agents.
Write the job before choosing the agent
A useful first scope describes the trigger, the information needed, the permitted actions and the definition of completion. It also names the person who can decide whether the result is acceptable. Without those boundaries, the model is asked to interpret the business as well as execute the task. That makes a demonstration difficult to evaluate and a production failure difficult to investigate.
Take a request-routing workflow. The decision is not simply whether a model can label a message. The system needs an allowed set of destinations, access to the relevant customer context and a route for uncertain or sensitive cases. The current manual workflow provides the comparison: what gets routed, who checks it and where errors are discovered. This gives the team something concrete to test before expanding the agent's job. It also exposes whether a deterministic rule would solve the same problem with less uncertainty.
Make the tool contract a business boundary
An agent's tools are the bridge between a model decision and a real effect. Each tool should have a defined operation, validated inputs, scoped credentials and an observable result. A customer lookup and a payment instruction should not share an unrestricted interface just because both are API calls. The permissions should reflect the job, including who or what may authorize a sensitive action.
The contract also needs failure behaviour. A timeout may occur after the underlying system accepted the request. Retrying without an operation identifier can repeat the action. A tool response may be incomplete or contain information the agent should not expose. These cases belong in the integration design and tests. Executives do not need to review every API field, but they should expect the delivery plan to explain how the agent is prevented from exceeding its role and how uncertain outcomes are resolved.
Evaluate the whole workflow, not a pleasing answer
An answer that sounds right is one observation. A successful workflow also needs the correct source, the correct permissions, a valid tool call and the intended final state. Build the evaluation around representative tasks and the failures that would matter to the business. Include missing information, contradictory records, denied access and an unavailable system. A test set made only of easy examples cannot justify broader permissions.
The repeated-step arithmetic in this guide is a planning illustration: multiplying step success rates assumes the relevant probabilities apply throughout the sequence. Real failures may be correlated and a model's behaviour can change with the inputs. The practical conclusion is to test end-to-end tasks instead of treating one headline model score as a production guarantee. Keep examples versioned, review failures with a knowledgeable person and rerun the checks when prompts, retrieval, models or tools change. Record which acceptance criteria passed rather than relying on a single attractive average.
Design approval as part of the product
Human review should show the proposed action, its evidence and its expected effect in a form the reviewer can understand. Asking a person to click approve without enough context moves the risk rather than controlling it. The review should make it possible to reject, correct or escalate the proposal, and the system should preserve the decision in its execution record.
Define what happens while approval is pending and what happens if it never arrives. A customer request may need a fallback path rather than remaining indefinitely in an agent's queue. The business owner should decide which actions may run automatically and which remain subject to review. Engineering then enforces those decisions in permissions and tool configuration. The model should not be able to grant itself a wider role by producing a persuasive explanation. Review effort is part of the operating cost and should be included when judging whether the workflow is useful.
Budget for operating the agent
The model bill is only one part of production cost. Retrieval, connected systems, evaluation, support and the time needed to review exceptions also matter. Establish which usage drives spend and how it is attributed to the workflow. Budgets and alerts should reach a person who can investigate or pause the system, with a safe route for the underlying business work to continue.
The same applies to quality. Someone needs to inspect failures, update the evaluation set and decide when a changed process requires a changed agent. A permission that was appropriate for an old workflow may no longer be appropriate after a new integration. The operating plan should name the business owner, technical maintainer and release authority. This is why agent selection is a product and operational decision, not just a model procurement decision. The question is whether the complete system is worth running, with ownership and evidence, after the first demonstration.
The decision to take to a scope call
Bring one candidate workflow and the current way it is handled. Identify the systems involved, the data you can provide and the actions that would require approval. If you have a pilot, bring its code or a clear account of what it does and where it stops. If you do not, bring the operating problem rather than a requirement to use a particular model.
The next decision may be discovery, a bounded validation, an integration or a custom agent build. It may also be to fix the process or knowledge source first. A useful proposal makes that route explicit and names the acceptance evidence, dependencies and ownership. Compare a fixed-scope agent package with a custom service according to whether the deliverables fit. The approved pricing guide provides planning ranges, while the written scope determines the actual commitment. That is enough to make a responsible first investment without pretending that every business should start with an autonomous agent.
