What AI agents for business actually are
AI agents for business are systems that take a job with no fixed path, decide which steps to take, act on your systems through their APIs, and keep going until the job is done or a limit stops them. That is different from a chatbot, where a person reads the answer and does the work, and different from workflow automation, where the sequence of steps is written in advance.
The distinction matters because all three are sold under one word. A chatbot that searches your documents is a retrieval system with a conversational front end, and it is often exactly what is needed. A fixed pipeline with a model reading one document in the middle is still a pipeline. An agent is the third thing, and it is the one that is harder to test, price and defend at a security review.
The useful test is simple: if the sequence of steps could have been drawn in advance, you wanted a pipeline. Agents earn their cost where the path varies with the case.
The four properties that make an agent safe to run
Four words decide whether something is an agent and whether it can go near production: stateful, tool-calling, bounded, recoverable. The first two determine whether it is an agent at all; the second two determine whether it belongs anywhere near live operations.
Stateful
The job remembers where it got to. A half-finished case sits in a durable record that survives a restart, the browser tab and the server that was running when step four began. Chat history is a transcript, not state.
Tool-calling
It acts on your systems rather than describing what someone should do. Tools are declared with typed schemas so the model cannot invent a field, and the agent reads what came back before deciding the next step. This is the property that separates work from advice.
Bounded
It stops at limits set in code, not in the prompt: a step ceiling, a spend cap, credentials scoped to the few operations it needs, and an approval threshold above which a person decides before anything commits.
Recoverable
When step five of eight fails, it resumes from five. Steps are idempotent so a retry cannot raise a second credit note, unfinished jobs land in a queue where they are visible, and every tool call is logged with its arguments, its result and the reason the next step was chosen.
Operations tasks worth giving an agent
The tasks that pay off share a shape: multi-step, unstructured input, a checkable result, and a path that varies case by case. Exception queues are the clearest example. Orders that fell out of an automated flow need investigating across several systems, enriching, and either resolving or escalating with a written reason, and no two look alike.
The other test is volume. High-volume, individually low-value work is where the cost of building bounds, logging and recovery around a machine falls below the cost of a person doing it. A handful of cases a week will be handled better by two people and a shared inbox, and the honest advice is to say so.
- Triaging exceptions that fell out of a deterministic flow
- Researching and summarising against internal policy, with sources attached
- Reconciling records across systems where references do not line up
- Drafting work a person approves: purchase orders, invoices, collection messages
- Jobs that span days and wait on other people, where something has to hold the state in between
Tasks that should stay a script
Most of what businesses want automated has a fixed path, and a fixed path wants a pipeline. Month-end journal postings that follow an unchanging rule need a script, because a script is testable in a way an agent is not. Where the path is fixed and the input is clean, deterministic automation is still the better answer, and most production deployments run both, with the agent picking up whatever falls out of the deterministic flow.
The second bullet is the one that gets skipped. An agent can draft the payment run; it should not release it. The irreversible step belongs behind an approval gate with the reasoning attached to the request.
- The sequence is the same every time
- A wrong action cannot be undone: releasing payments, destroying stock, emailing a whole customer list
- Nobody has written down what a correct outcome looks like
- The only route into a system is driving its screen, which is RPA, not an agent
How SoloOne uses agents: Close, Collect and Replenish
SoloOne ships three agents that run on the suite's ledger. Close runs the month-end sequence, reconciling bank feeds against open invoices, accruing unbilled project time, posting depreciation and prepayments, and stopping where a person must decide, including before the period locks. Collect chases receivables in your tone and books the cash when it arrives. Replenish watches stock cover per item and location and drafts purchase orders before you run out.
Each agent is bounded the way the section above describes. They run with the same permissions as the person who asked, every action is a posted, reversible ledger entry, and the irreversible steps, locking a period or approving a purchase order, wait for a person. In the demo transcript on the product page, Close matches the bank lines it can, flags the three it cannot to a named person, and asks before locking September.
That design is deliberate rather than cautious. An agent whose every action is a ledger entry can be audited by job, by customer and by date, and reversed if it was wrong, which is the property most often missing from agent demonstrations.
How Supremacy builds agents for clients
For custom engagements, Supremacy builds agents as directed graphs with typed state, checkpoints and per-node timeouts, so a long-running task can be paused, resumed and audited step by step. Tools are exposed through Model Context Protocol servers as typed, permissioned interfaces, so one integration serves every agent rather than being rewritten per framework. LangGraph is the usual orchestration layer where state and durability matter; the choice is made per workload and documented.
Reliability is instrumented rather than assumed. Every run is traced end to end, per-run ceilings on steps, tokens, wall-clock and spend stop a stuck agent early, and retries, fallbacks and escalation to a person are part of the graph. Agents are scored on whether the task completed correctly from end to end, and the measures tracked per release are task completion rate, cost and latency per run, and the share of runs needing human intervention.
The starting posture is deliberately low: approve everything for the first weeks, watch what the agent would have done, and raise the threshold once its decisions have become boring.