Every “how does AI work” explainer online starts the same way. Neurons. Tokens. Embeddings. Transformers. The math of prediction. And then, somewhere around the third paragraph, it tells you about something called the attention mechanism and you realise the explanation is written for an engineer, not someone trying to decide whether to bring AI into their business.
Here is what every textbook explainer misses: none of that math tells you what AI does on a Monday morning when your inbox has two hundred emails and you have to figure out which one matters.
The useful answer to how does AI work is not about the inside of the model. It is about the shape of work around it.
Start with two layers.
The first layer is the model itself. A large language model like Claude or GPT takes an input, some text, some context, a question, and predicts what should come next. That prediction is good enough that it reads like reasoning. It understands language. It connects ideas. It can write, analyse, plan, and explain. If you want to know how it actually does that, the textbook answer is right: it predicts the next token based on the weights learned during training. For a business owner trying to decide whether to use it, that is enough. The model can reason.
But here is what stops every how-does-AI-work conversation from being useful: knowing the model can reason does not tell you how to use it.
The second layer is the shape. The operating shape. The loop.
When AI does a real job, actually does it, end to end, and something lands on a customer desk or a bank account moves, it follows the same pattern every single time. The loop is simple enough that a small business owner can describe it. Detailed enough that it tells you what can go wrong.
- Read. The employee pulls context from somewhere real. An email arrives. A support ticket lands in a queue. A contract sits on a desk waiting for review. A spreadsheet has new numbers. The loop starts with context. The first place production breaks is here. A demo has perfect context. A real inbox is noisy. Incomplete. Contradictory. The employee has to know how to work with imperfect information.
- Plan. The employee thinks about what needs to happen next. What is this email actually about? What decision follows? Should this escalate or should I draft a reply? What systems do I need to call? What is the sequence of actions? This is where the model reasoning matters. A good plan saves mistakes downstream. A bad plan sends the employee down the wrong path and wastes time.
- Act. The employee does something real. Calls an API. Logs into a CRM. Drafts an email. Books a meeting. Moves money. Sends a message. The action layer is where the employee connects to the actual systems where work happens. This is also where scope matters. The more systems the employee has to touch, the longer the loop takes, and the more ways it can break.
- Check. The employee asks: did that work. Did the email send. Did the API accept the payload. Did the CRM record save. Observation is not automatic. Most AI agents skip it. This is why most agents break in production. A working employee checks every step.
- Retry or escalate. If the action succeeded, the loop closes. The employee moves to the next queue item. If the action failed, the employee either tries again or admits it is stuck and sends the work to a human with context. Most agents do not know when to give up. They retry forever or escalate nothing. A working employee knows the difference.
This loop is where the marketing ends.
A vendor demo runs this loop once, on clean data, with happy-path tools, with fresh API credentials, with a model that has been tuned until the one thing it does works perfectly. The email is clear. The system is responsive. The human review is optional.
Production is not a demo. The queue is long. The context is incomplete. The tools have rate limits. OAuth tokens expire on schedule. The model gets confused on cases it has never seen before. The APIs return errors the employee was never trained on. And the 1% of cases where the employee gets it wrong is usually the 1% the customer sees.
This is why a working AI employee needs four things that vendors do not talk about in the keynote.
First: state. Memory. A vault the employee owns, the customer owns, that persists across model changes and learns from every loop. What the team approved last Tuesday. What the customer always rejects. What tone the founder uses. What the competitor does that matters. The vault compounds. The employee gets faster because it does not start from scratch every time.
Second: an approval gate. Anything that touches a customer, a contract, or a commitment pauses for a human to review before it ships. Not because the employee is unreliable. Because the 1% it gets wrong has blast radius. The customer sees it. The relationship breaks. The review takes ten seconds most days. Once a week the human catches something that would have cost money.
Third: real integration into the customer stack. Not a REST call to an API the vendor controls. The employee needs to log into the CRM. Read the inbox. Touch the tools where work actually happens. This is the hard part. It is also the part that keeps the vendor from owning the customer workflow.
Fourth: observability. When did the employee last work. What is queued. What failed. What escalated. A timeline, not a dashboard. When a customer says something got missed three days ago, you have a log to read.
The employees that break in production skip one of these four.
An overnight inbox triage is a good place to see the loop fire.
Overnight, one hundred emails land. The employee reads the subject, the sender, the history. Plans which need immediate replies, which need a file lookup, which are routine and which are escalatory. Acts: drafts a reply to the urgent customer issue, pulls the contract history on the vendor pitch, routes the internal spam. Checks: did the reply draft correctly, does it have the right tone, is it ready to send. Waits. A human on the team reviews the drafts. Approves most of them. Flags one that missed the specific voice the firm uses. Updates the vault. Sends the approvals. The employee learns.
Next night, same queue, smaller bottleneck. By week three, the overnight emails that used to land on the team desk at 9am are already sorted, drafted, and waiting for approval when the team logs in. The work got faster because the loop ran a hundred times and the vault remembers what landed.
The wedge between AI works and AI works inside your business is exactly this: the loop, the vault, the approval gate, the observability.
A founder or an operator does not care whether the model understands transformers. They care whether Monday morning is calmer. Whether the customer gets a reply before they churn. Whether the 2am failure gets caught at 2am instead of when the customer calls at 10am with a problem. The useful question is not how does AI think. The useful question is: does the loop close safely on real work.
The model gets smarter every quarter. Claude or GPT or Gemini ships a new version with better reasoning and fewer hallucinations. That is worth paying attention to. But here is what the category mostly misses: the model is the engine. The loop is what compounds. The business that wins is not the one with the smartest engine. It is the one with the loop that learns. That remembers. That acts. That gets faster because it knows the customer.
So the honest answer to how does AI work in a business is this. AI works by reading, reasoning, planning, acting, and checking. The interesting question is not whether the model thinks well. The interesting question is whether the loop closes safely on real work. Whether the vault holds the lessons. Whether a human catches the 1% before it breaks something. Whether the team gets smarter every week because the employee remembers.
Start with a job. The model will do the heavy lifting. The loop will do the rest.
Related See the loop in production →