AI assistants, automation and business data explained

A business AI system is a stack of separate parts

Read a working assistant as a stack, because each layer has its own owner, its own failure and its own test.

• Business data and permissions: which sources the system may read, on whose behalf, and what it must never see.
• Instructions and context: the standing instructions, plus whatever is placed in front of the model for this particular request.
• Model or rules: either a language model producing text, or explicit conditions producing a predictable outcome.
• Retrieval: fetching material from a permitted source so an answer can rest on something specific.
• Tools: requests that ask another system to do something, which is where real consequences begin.
• Validation and human approval: the checks before an output is shown or an action is taken.
• Monitoring and evidence: what is recorded, so a wrong answer can be found, explained and corrected.

Separating the layers matters because they fail differently. A wrong answer caused by an out-of-date document is a retrieval problem. A wrong answer the model invented is a grounding and review problem. A message that should never have been sent is an authorisation problem. One label for all three, usually that the AI got it wrong, hides which part actually needs fixing.

How a chatbot, workflow automation and an agent differ

IBM describes a chatbot as "a software application that communicates with people through text or voice", and is clear that the labels overlap: rule-based chatbots "follow predefined rules, decision trees and scripted conversation flows", AI chatbots use language models to interpret intent, and the term virtual agent is used both interchangeably with chatbot and for more advanced systems that reach business applications and complete tasks. Take the labels as approximate and look at the behaviour instead.

Anthropic's engineering write-up draws the distinction that matters for planning. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths", while agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks". Its advice is to start simple: begin with a prompt, evaluate it properly, and "add multi-step agentic systems only when simpler solutions fall short", because the autonomy of agents "means higher costs, and the potential for compounding errors". That is a dated practitioner description rather than a standard.

A three-question test is usually enough to classify a candidate task. Is the input predictable in shape, or does it arrive as free-form language? Is the output information for a person to read, or an action that changes something outside the system? Can a person realistically review the result before it takes effect? Most real tasks mix all three: deterministic routing, a retrieved and drafted answer, and a human approval before anything leaves the building.

What a language model needs from context and business data

IBM describes large language models as deep-learning models that work as "giant statistical prediction machines that repeatedly predict the next word in a sequence", generating one token at a time by calculating probabilities for the possible next tokens. Everything follows from that. The model is producing plausible continuations of the text it was handed, which is why it can state a refund policy that has never existed in exactly the tone it uses for one that has. IBM lists the behaviour plainly among the limitations: models "generate information that is false or misleading while sounding plausible", and they reflect and amplify biases in their training data.

Context is what the model is given for this request: standing instructions, the conversation so far, and whatever business material has been placed in front of it. Modern models hold large context windows, which IBM notes now run to hundreds of thousands of tokens in newer models, but a window is working space, not knowledge. Material that is neither in the window nor in the training data is simply absent, and material that is in the window is being read this time, not learned or stored. Deciding what may be placed there, and on whose behalf, is a permissions decision before a technical one.

Retrieval and tool use are different controls

Retrieval means fetching material from a permitted source and putting it in front of the model, so an answer rests on something specific. IBM describes retrieval-augmented generation as "an architecture for optimizing the performance of an artificial intelligence (AI) model by connecting it with external knowledge bases", where responses can carry citations back to those sources so a reader can check them. The same page states the limit directly: "While RAG can reduce the risk of hallucinations, it cannot make a model error-proof." It also notes that knowledge bases "must be continually updated", or the answers quietly drift out of date.

A tool request is a different act. Retrieval reads; a tool changes something, or asks another system to. Refunding a payment, sending a message, updating a record and confirming a booking are not answers, they are consequences, and they need their own controls: whether this user is authorised for this action, whether the parameters are valid, whether the action actually succeeded, and what is recorded about it afterwards. Keep the read path and the write path separate in the design, so that widening what an assistant may read never quietly widens what it may do.

When plain rules are the better answer

Where the input is predictable and the decision is explicit, rules are usually easier to inspect, test and operate than generated text, and they fail in ways somebody can trace. Odoo's automation documentation shows the normal anatomy: a rule has a trigger that "defines what kind of event needs to occur for the automation rule to run", optional conditions narrowing which records it applies to, and actions that run when both are satisfied, with triggers including field changes, email events, timing conditions and external events.

Two details from that same documentation are worth carrying into any rules design. Timing-based rules run from a scheduled check, and the guidance is to run a new rule manually once after setting it up to "prevent the rule from running retroactively on historical records", which is exactly the failure that sends a thousand reminders on a Monday morning. And the available actions include sending a webhook notification to another system, which is the moment a rule stops being internal and starts having effects elsewhere. Those behaviours are specific to that product, and the caution generalises: write every rule as trigger, conditions, action, exception path and evidence to collect. A rule without a defined exception path still has one; it is just undocumented.

How outputs and actions can be checked

Evaluation is evidence collection, and it covers more than whether an answer reads well. IBM's account of assessing language models asks for "multiple dimensions rather than a single benchmark", naming accuracy, efficiency, safety, fairness and robustness. The NIST AI Risk Management Framework, released on 26 January 2023 and "intended for voluntary use", organises the same ground into four functions, Govern, Map, Measure and Manage, aimed at incorporating trustworthiness into the design, development, use and evaluation of AI systems. NIST notes that AI RMF 1.0 is being revised. It is guidance, not a certification, and following it is neither legal advice nor a compliance conclusion.

For one bounded workflow, the evidence that matters is short and specific: which sources the answer used, whether they support it, what the system did when it was unsure, which tool it chose, whether that action was authorised, what happened when a tool failed, and where a person reviewed it. Those are observations to collect and read, not claims to make in advance.

A worked example: a fictional question and an approved action

The workflow below is invented for teaching. An unnamed business receives a customer question, answers it from permitted material, and then needs one external action taken. Every actor, policy and system response is an assumption, and the final column lists tests and observations to collect, never results already achieved.

The shape of the table is the point. Deterministic routing handles the part that is predictable. Retrieval and generation handle the part that is language. A person holds the part that has consequences. Each stage hands to the next with something recorded, so a bad outcome can be traced to the layer that produced it rather than blamed on the system as a whole.

Limits, handoffs and what this page does not decide

Several limits are structural rather than temporary, and they belong in the design rather than in a disclaimer. A model can be confidently wrong. Retrieved knowledge goes stale unless somebody maintains it. What a system may read and what it may do are two separate permissions. Inputs arrive malformed. Tools fail, and a failed tool call must never be reported as a completed action. A workflow that quietly claims success when the outcome is unknown is worse than one that stops and says so.

A human handoff is a designed state, not a safety claim. It works when the person receives the customer's question, the relevant context, what the system was uncertain about and what it was asked to do, so they can continue the task rather than restart it. IBM's chatbot guidance makes the same point from the customer's side: a well-designed system recognises its limits and provides a clear path to a human representative. Deciding when to escalate, how data access and retention are scoped, and how retries and recovery behave are each their own piece of work.

What to do next

1. 1Name one task. Write down its input, the data it is permitted to use, the output a person would accept, and the side effect it could cause.
2. 2Split it three ways: the part predictable enough for plain rules, the part that genuinely needs language, and the part that must wait for a person.
3. 3Decide the uncertainty behaviour before anything is built. What does the system do when it cannot support an answer, and what does the customer see while that happens?
4. 4Write down the evidence you will collect each week and name the person who reads it. An assistant nobody reviews is being trusted on faith.