Reusable code, a fixed workflow with an LLM step or a bounded agentic workflow?

Say your team produces the same report every Monday. The figures come from the same systems, the slides follow the same structure and the checks barely change, but somebody still opens an AI tool and asks it to build the whole thing again. It will probably get there, but it has to interpret the job again, so the wording moves, the layout shifts and a person checks work that should already be settled. The problem is how the job has been designed, because the repeatable parts were never settled in the system.

I think this is one of the most useful distinctions a business can learn, because using AI effectively often means deciding where you do not need it. Code is brilliant at repeating decisions you have already made. A fixed workflow can use an LLM when one answer depends on language or context. An agent is the wider system you may need when that model must also inspect what is happening, decide what to do next and use tools to carry the job forward.

What is an LLM?

An LLM, or large language model, is the part of an AI system that works with language. It can interpret a customer message, extract meaning from a document, explain information and draft a response. It is useful because language is messy, but that same flexibility means it should not replace fixed calculations, permissions or checks.

An LLM and an agent are related, but they are not two equivalent technologies. The LLM is the model that interprets or generates. An agent is a system built around a model, with instructions, tools and a loop that lets it choose and carry out permitted next steps. A single LLM call inside a fixed workflow is therefore not automatically an agent.

What does deterministic mean?

A deterministic process follows fixed rules, so the same valid input and the same starting state produce the same result. Add the same invoice lines and the total should not change. Feed the same approved data into a report template and the structure should not move. That predictability makes the process easier to test, reproduce and trust.

Code is a way of writing those instructions down, but code is not automatically deterministic. A program can deliberately use randomness, current time, live external data or competing processes, so the useful question is about the behaviour you need rather than the language used to build it. If the business needs one reproducible answer, the system should be designed to produce one.

What does non-deterministic mean in AI?

An LLM generates a plausible response from patterns and context, so asking the same question twice can produce different wording, reasoning or choices. That variation is useful when the input is messy and there is no single rule that covers every case. It is a poor fit when the business needs an exact total, a fixed permission check or the same transformation every time.

That variation is useful for interpretation, provided the model is surrounded by fixed instructions, structured inputs, tested tools and clear limits. The system gets weaker when the model is asked to improvise parts of the job that were already known in advance.

When should a business use reusable code?

Use reusable code when the steps can be specified, the input can be validated and the expected result can be tested. Once those decisions have been made, the script can run them quickly and consistently without asking a model to reconstruct the process. AI may help write the script, but it does not need to remain involved when the script runs.

• Calculate invoice totals, tax, commissions or other customer-relied figures.
• Validate, clean, remove duplicate records or reformat structured data.
• Move approved information through tested connections between the systems.
• Apply a fixed template to a report, document or slide deck.
• Check required fields, file dimensions, permissions or business rules.
• Trigger a predefined notification after a known event.

When should a fixed workflow include an LLM?

Add an LLM when one defined step depends on understanding language, intent or unstructured information. The workflow around that step can still be fixed. Code gathers the input, the model performs the interpretation, and code validates and routes the result. You get useful judgment without handing the whole process over to a fresh model response.

• Classify the subject and urgency of an incoming customer message.
• Summarise a long document into a fixed set of fields.
• Draft commentary explaining movements in already calculated figures.
• Extract dates, organisations or actions from inconsistent prose.
• Turn an approved argument into copy that fits a known content structure.

A reusable skill, which is a saved set of instructions and examples, can give the model a more consistent method and output format. It still does not make the result deterministic, because the model interprets those instructions each time. If a step can be expressed completely as a fixed calculation, check or template, move it into code instead of adding more instructions for the model.

When does the job genuinely need an agent?

Use an agent when the next step cannot be selected in advance because it depends on what the system discovers. The agent interprets the situation, chooses from permitted tools, checks whether the goal has been reached and either continues, stops or asks a person for help. A single prompt that drafts text is using an LLM, but it is not an agent.

The phrase agentic does not mean uncontrolled. A good agent works inside a narrow job with explicit instructions, tested tools, restricted permissions, retry limits and a clear route back to a human. The reasoning can be flexible whilst the actions underneath remain predictable and auditable.

What does the spectrum look like?

The easiest way to place a job is to ask one question. Can fixed rules choose every step, or does the job need interpretation as it runs? If fixed rules can choose the route, put them into code. If one defined step needs interpretation, put an LLM inside a fixed workflow. If the next action cannot be selected in advance because it depends on what the system finds, use a bounded agent with controlled tools.

1. 1.Fixed rules: a script turns approved figures into a standard weekly report.
2. 2.Some interpretation: an LLM drafts the written commentary after code calculates the figures.
3. 3.Several possible next steps: a bounded support agent interprets the request and selects an approved process.

How would this work for a weekly slide deck?

A weekly report deck looks like one task, but it contains several different kinds of work. The data retrieval, calculations, slide dimensions, brand template, page numbering, footers, exports and validation can all be coded. They should run the same way every time because nobody gains anything when the model reconsiders the font size or total on a Monday morning.

The LLM can fill the gap that actually needs interpretation. It can explain why a movement matters, turn the findings into plain English and propose the narrative that connects one slide to the next. The output goes into fixed fields, code renders it through the approved templates, and automated checks catch missing sections, overflowing copy and the wrong file dimensions before a person reviews the finished deck.

You only need an agent if the job has to make decisions across several steps. It might notice that one data source is missing, fetch an alternative, decide which exception needs explaining, request an approval and then rerun the export. If the workflow always follows the same straight line, adding an agent gives you more moving parts without buying you better judgment.

How does this apply to support, booking and sales?

Customer support

An LLM can understand what the customer is asking and draft a useful answer. Fixed, tested tools should retrieve the account, calculate any amount, check the policy and record the outcome. An agent can choose which approved support path to follow, but refunds, account changes and uncertain cases should hit fixed limits or move to a person.

Calendar booking

An LLM can understand a request such as next Thursday after the school run but before three. Code should query real availability, handle time zones, prevent double booking and create the event. An agent is useful when it has to negotiate between several options, ask a follow-up question and carry the conversation through to confirmation.

Sales development

Code can remove duplicate CRM records, enforce targeting rules and record every action. An LLM can read a prospect's public information and identify a relevant business problem. An agent can decide what research is still missing and prepare a tailored message, but sending that message should remain a human decision until the business has deliberately authorised a narrower policy.

Which parts should stay outside the model?

Keep customer-relied numbers, permission checks, validation, duplicate removal, audit records and irreversible actions outside the model. The LLM can explain a figure, but tested code should calculate it. The agent can recommend an action, but fixed policy or a person should decide whether it may send, spend, price, refund, publish or change a customer record.

How do you choose the smallest useful system?

Start by writing down the steps a competent person follows today. Mark every decision that can be captured as a fixed, testable rule, because those are candidates for code. Mark the points where language or incomplete information needs interpretation, because those may need an LLM. Only call it an agent when the system must choose and perform different next steps based on what it finds.

• Is there one correct result that must be reproducible?
• Can the rules be written down and tested?
• Does any input need interpretation rather than validation?
• Must the system choose between different actions while it runs?
• What is the consequence if that choice is wrong?

That is the discipline. Put the rules that can be written down and tested into code, use an LLM for the parts that need interpretation, and only add an agent when the next step genuinely depends on what it finds. That usually removes repeated model work, but the bigger win is a system whose fixed parts can be tested and reproduced when the business needs to trust the result.