An assistant answers you. An agent does something. That difference sounds small in a demonstration and turns out to be the entire question once it is running in a real company.
Quick answer
An assistant produces words for a person to use. An agent takes an action on the business's behalf, and that is a different kind of decision.
Once software acts, three things matter: what it is allowed to do, what it is working from, and what record it leaves.
Authority should be granted one task at a time, not handed over as a category.
Start where a mistake is cheap and visible, never where it is expensive and quiet.
The word agent is doing a lot of work in the market at the moment, and most of the confusion comes from using it for two quite different things.
Software that drafts a reply for you to read and send is an assistant. Nothing has happened in the world until a person decides it should. Software that sends the reply, books the appointment or updates the record has done something, and it did it while you were looking somewhere else. Everything difficult about this subject lives in that second sentence.
The Line Is Action, Not Intelligence
It is tempting to treat this as a question of how capable the technology is. It is not.
A very simple piece of software that books an appointment has crossed the line. A very sophisticated one that writes a beautiful draft has not. The distinction that matters to a business is whether something happened without a person present, because that is what changes who is responsible when it goes wrong.
Get that clear before evaluating anything, because most of the marketing in this space blurs the two deliberately.
Three Questions Before Anything Acts
Once you accept that framing, the evaluation becomes much simpler. There are three questions, and they are all business questions rather than technical ones.
What is it allowed to do. Not what it is capable of. What it is permitted to do, written as a short list of specific actions rather than a category. "Can reply to a booking enquiry with available times" is a permission. "Handles customer service" is not.
What is it working from. An agent that acts using generic knowledge will act generically. If it is quoting, it needs your approved offers. If it is answering, it needs your source of truth. If it has neither, it is guessing confidently on your behalf.
What record does it leave. You should be able to see what it did, when, and on what basis, without asking anybody. If you cannot reconstruct an action afterwards, you cannot correct the cause, and you will end up correcting the same thing forever.
A tool that cannot answer all three is not ready to act in your business, however impressive it looks.
If you would rather work this out against your actual operations than against a feature list: https://strategicmarketer.com/#contact
Grant Authority One Task at a Time
The mistake is not giving software authority. It is giving it authority as a category.
"Handle the inbox" is a category. It contains sending a price to the wrong person, promising a date you cannot meet, and replying to a complaint in a tone you would never use. Nobody intended any of those. They were simply inside the boundary that got drawn too wide on day one.
Grant one action, watch it for a fortnight, then grant the next. That sounds slow and is considerably faster than the alternative, because nothing has to be unwound.
Kind of work | Sensible starting authority |
|---|---|
Internal summaries and drafts | Can run unsupervised |
Routine scheduling and reminders | Can act, with a record you can read |
Customer replies | Drafts only, a person sends |
Anything about price, contract or a complaint | Drafts only, and only from approved wording |
What It Works From Decides How It Sounds
This is where most disappointment actually originates, and it is rarely blamed correctly.
An agent drafting a proposal from your own approved offers produces something you recognise. The same agent with nothing to work from produces something that reads like a template, because that is effectively what it is. People then conclude the technology is not good enough, when what was missing was the input.
So the unglamorous work comes first: the offers written down, the prices confirmed, the answers you are happy to stand behind recorded somewhere it can reach. This is the same foundation described in what has to be true before it works, and there is no way round it.
Start Where a Mistake Is Cheap and Visible
Every first project should be chosen on this basis rather than on impact.
Cheap means an error costs a correction rather than a customer. Visible means you will notice within a day rather than discovering it in a quarterly review. Those two together are worth more than any efficiency estimate, because they are what let you learn quickly without paying for the lesson.
Scheduling a follow up, drafting from approved material, organising an enquiry so the right person sees it: all cheap, all visible. Quoting, contracting and anything a regulator cares about: neither.
Decide the Boundaries Before You Decide the Tool
The useful conversation is not which agent to buy. It is which actions your business is prepared to have taken on its behalf, what those actions need to work from, and what record you want left behind. The AI Business Assessment starts with how your business actually runs and recommends what to install and in what order.
A Person Stays in the Loop Where It Counts
Keeping a human approval step is sometimes described as a limitation. It is better understood as a design decision you get to make.
There is no rule that says a system must be fully automatic to be worth having. A process where the work is prepared automatically and approved in ten seconds by a person is dramatically better than one where it was never prepared at all, and it carries almost none of the risk. Many businesses would be well served stopping exactly there and never going further.
The approach matters more than the level of automation, and moving that approval line should be a deliberate decision made after something has earned it, not a default that drifted.
It Is an Operational Change, Not a Technology Adventure
None of this is specific to agents, which is rather the point.
Anything that changes how work gets done needs the work described, the boundaries set, an owner named and a measure agreed. Software that acts simply makes each of those more urgent, because the consequences arrive faster. The management side of this is where the useful reading is: MIT Sloan Management Review looks at what changes culturally inside companies that adopt it, which tends to be a better predictor of success than the technology chosen.
Treating this as an ordinary operational project is what makes it survive contact with a busy week.
Agencies Carry One Extra Condition
If you are putting agents into client businesses rather than your own, everything above applies, with one addition that is easy to get wrong.
The client has to agree the boundaries, not just the agency. An action taken on a client's behalf by software you installed is still an action taken on their behalf, and the time to establish who approved what is before anything runs. Agencies working this way can see how Strategic Marketer works with partners.
Work Out What Should Act, and What Should Only Draft
Most businesses do not need more automation. They need a clear line between what software may do on its own and what a person still signs off, and the knowledge behind it written down so that whatever does run sounds like the business. The assessment starts with how your business actually operates and ends with a recommendation you can act on. What gets approved stays your decision throughout.
Frequently Asked Questions
What is the actual difference between an assistant and an agent?
An assistant produces something for a person to review and use. An agent takes an action in the world: it sends, books, updates or notifies. The distinction is not sophistication, it is whether anything happened without a person present.
Should an agent ever reply to a customer without approval?
Eventually, for narrow and well understood cases, once it has been right consistently for a while. Not at the start. The defensible default is that anything customer facing is drafted automatically and sent by a person, and that line moves deliberately rather than by drift.
How do we stop it doing something we did not expect?
Grant permissions as specific actions rather than as categories, and insist on a record you can read afterwards. Most surprises are not the software misbehaving, they are an authority boundary that was drawn more widely than anyone realised on the day it was set up.
What does it need from us before it can act usefully?
The offers, the prices and the approved wording, written down somewhere it can reach. Without that it will act on general knowledge, which is exactly what makes output feel like it came from a template rather than from your business.
How many should we run at once?
One, until it has been running for a month without anybody thinking about it. The failure mode is rarely a bad first project. It is six started at the same time, none of which has an owner.
Is this only worth it for larger companies?
No, though the reasoning differs. A larger company gains from consistency across many people. A smaller one gains from work happening at all during the weeks when the owner is busy. If you are weighing up where to begin, choosing the first job is the practical starting point, and turning a chat tool into an actual system covers the groundwork that has to exist first.