AI Agents for Business: What They Do and Where to Keep Control

01What is an AI agent?

An AI agent is software in which a language model chooses the next action. You give it a goal and a set of tools, such as searching your help articles, reading an order record or drafting an email. The model calls a tool, reads what comes back and decides whether to call another tool, ask a question or stop. That repeat-until-done cycle is the loop.

Anthropic separates workflows, which run models and tools through predefined code paths, from agents, which direct their own process and tool use. OpenAI's Agents SDK describes agents as models equipped with instructions and tools, with a built-in loop that continues until the task is complete. Both companies sell agent tooling, so read their advice as vendor guidance. The definition still helps with planning.

• Model: reads the goal and the tool results, then proposes the next step.
• Tools: specific functions the agent may call, each with its own inputs and limits.
• Loop: the cycle of acting, checking the result and deciding again, with a maximum number of turns.
• Permissions: the accounts, scopes and approval rules that decide which tool calls run.

02AI agent vs automation: which one fits the task?

Much of the small-business work that people call agent work is better handled by fixed automation with one AI step inside it. If you can write the steps down in advance (when a form arrives, extract the fields, check them, put them in a review queue), a fixed workflow is easier to test, cheaper to run and easier to explain when something goes wrong. Anthropic's own guidance is to find the simplest solution first and add agent behavior only when it measurably improves results, because agents usually cost more and respond more slowly.

Use an agent when the path depends on what it finds: which records to look up, which follow-up question to ask, which of several systems holds the answer.

03AI agents for small business: when the loop is worth it

A good first agent task has four traits. The steps vary enough that a fixed flowchart keeps missing cases. Each step produces something the agent can check, such as a found record or a returned error. The output is a draft or a proposal, so a mistake mostly costs review time. Someone on your team already knows what a correct result looks like and has time to check it.

If a task fails any of these, start smaller. A single model call with your own reference material often handles a request well enough, and a person can take the next step by hand. The guide on when not to use AI covers how to rule a workflow out before you build anything.

• Write down the goal, the tools the agent may use and the result you expect for ten real cases before you build.
• Count how often the steps differ. If eight of ten cases follow the same path, build that path as a fixed workflow.
• Decide who reviews agent output and how many minutes a day they can give it.

04AI agent examples with approval points

The examples below are illustrative designs for a small business, not deployments GLCO has run. Each one gives the agent read access and draft-writing tools, and stops at a named approval point before anything leaves the building or changes a system of record. For example, a 12-person distributor might start with the quote-request row and leave pricing approval with the sales manager.

05Give the agent the least privilege it needs

An agent does damage mainly through the tools and accounts you give it. The OWASP Top 10 for LLM applications calls this risk excessive agency and traces it to three causes: tools the job doesn't need, permissions broader than the job needs, and actions that run without independent approval. Its example is an email assistant meant to summarize messages that also had permission to send them.

Treat the agent like a new contractor with a narrow job. It gets its own identity, the smallest set of tools, and read-only access wherever reading is enough. Enforce limits in the connected system itself, through user roles and API scopes, rather than relying on instructions in the prompt.

• Create a separate service account or user for the agent so its actions show up under its own name.
• Offer specific tools such as look up order by number instead of open-ended ones such as run any database query or fetch any URL.
• Use read-only scopes by default and grant write access per tool, per system, when a tested need exists.
• Remove tools left over from testing before the agent goes live.

06Require human approval for actions you can't undo

Decide which tool calls pause for a person before you connect anything. Sending a message, paying or refunding, deleting a record, changing access or sharing settings, and publishing anything public all belong on that list. OpenAI's help page on ChatGPT app permissions lists the same kinds of actions as ones that may need extra review, and offers settings ranging from always ask to allow all actions, which it labels as carrying elevated risk.

If you build your own agent, the framework should support a real pause. In OpenAI's Agents SDK, a tool marked as needing approval stops the run and surfaces the proposed call and its arguments until someone approves or rejects it. Its documentation also warns that restoring a paused run does not authenticate the person approving it, so approval state belongs in storage your application controls.

• Show the approver the proposed action, the exact values and the source records the agent used.
• Let the approver edit, reject with a reason or approve once. Avoid blanket always-approve settings for write actions.
• Record who approved, when, and what was sent, next to the agent's run log.

07Plan for prompt injection and bad inputs

An agent reads emails, web pages, attachments and tickets written by people outside your business. Any of that text can contain instructions. NIST's Generative AI Profile describes indirect prompt injection, where an attacker plants instructions in data the system is likely to retrieve, and notes that researchers have shown it can be used to steal data or run code. A customer email that says to forward the last ten invoices to a new address can be an attack on the agent, even if it reads like a polite request.

Instructions in content must never expand what the agent may do. Keep the permission rules in code and in the connected systems, where a sentence in an email cannot change them.

• Treat all retrieved content as data to analyze, never as a source of new instructions or permissions.
• Limit outbound actions, such as emails sent per hour, so a manipulated run can't do much before someone notices.
• Test the agent with planted instructions in sample emails and documents before it touches live data.

08Log every tool call and keep a stop switch

When an agent gets something wrong, you need to see what it read, what it decided and which tool calls ran. Keep a run log for each task with the goal, each tool call and its arguments, each result, approvals, and the final output. Store the log under your business's account, with access limited to the people who need it, and set a retention period that matches the data inside.

You also need a way to stop the agent. The NIST AI Risk Management Framework includes having mechanisms and assigned responsibilities to disengage or deactivate AI systems whose results don't match their intended use. For a small business, that means a named person, a documented off switch, and a manual process the team can fall back on.

• Cap the number of loop turns and the run time per task so a confused agent stops instead of retrying forever.
• Alert a named person on repeated tool errors, rejected approvals or unusual volume.
• Write down how to pause the agent, revoke its credentials and finish queued work by hand, then rehearse it once.

09How to pilot an AI agent safely

Run the first version in shadow mode: the agent works on real cases, but its output goes to a review queue and nothing is sent or written. Compare its drafts with what your team actually did. Track how often reviewers accept the output unchanged, edit it or reject it, and how long review takes. Then decide whether the agent removes enough work to justify its running cost and the review time.

Expand one permission at a time. A draft-only agent that saves your team real time is a good result. Letting it send routine replies without review is a separate decision, made with the evidence from the pilot and an owner who accepts the risk.

• Agree on pass and stop criteria with the process owner before the pilot starts.
• Keep a sample of rejected outputs and the reason, so you can tell a prompt problem from a missing tool or bad source data.
• Recheck the pilot results after any model, tool or connected-system change.