What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
In this Book Essential
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
INTRODUCTION
Most writing about AI agents starts with a promise. This report starts with a definition, and the definition is small on purpose. An AI agent, Benjamin Labaschin writes, is a tool that lets a person interact with a large language model to reach a productive or creative result with as little technical friction as possible. The model is the engine, the agent is the car, and the driver never needs to open the bonnet.
That analogy does a lot of work in forty pages, and it also marks the limit of the report. If an agent is a frontend, then the interesting questions are questions of interface design: which tasks benefit from a conversational wrapper, which benefit from a document store, which benefit from code completion inside an editor. Labaschin answers those questions with three worked archetypes, document question and answer, chatbots, and code assistants. Each one arrives as a fictional scenario, then an agent transcript, then a real implementation using Chainlit, PandasAI, HuggingFace Chat, Llama 2, Streamlit and ChatGPT.
Published by O'Reilly in November 2023, the report is a snapshot of the moment when the wrapper became a product. ChatGPT had been public for about a year. Microsoft had shipped an AI search assistant, Google had answered with Bard, and the first wave of companies was deciding whether to put a model inside its own software. That context explains both the strengths and the gaps. The three archetypes are clear and still useful. The economics, the adoption figures and the platform names have aged faster than the argument.
This Essential does three things the report cannot do for itself. It separates the part of the definition that survived the following years from the part that did not, because the word agent now usually describes a control loop with tools and memory rather than a wrapper. It puts the three archetypes to work for a reader who has to choose one this quarter, with the questions the report leaves out, which are evaluation, permissions, cost per task and what happens when the agent is wrong. And it maps the whole thing onto the U365 methods, where LIPS is the document store a question and answer agent reads, UP-Context is the prompt layer that keeps a chatbot on policy, and CI-First decides which decisions stay with the person.
Read it if you want a short, honest description of what these tools are before you buy one, build one, or authorise one. Read something newer if you need the current state of autonomous agents, because the report stops before that story starts.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
U365'S VALUE PROPOSITION
WHO THIS IS FOR
Professionals who have been asked to add an agent to a product or a process, and who need to distinguish a wrapper from an autonomous system before the budget is fixed.
Team leads evaluating a document question and answer tool for a document-heavy process, where the real questions are retrieval quality, permissions and audit, not the model name.
Fellows building a personal knowledge system who want to know what a question and answer agent can and cannot do with their own notes in LIPS.
Developers and analysts who use code assistants daily and want a defensible rule for when to accept a completion and when to verify it by hand.
Readers who want a short primer they can finish in one sitting, and who accept that anything written about this market in 2023 needs a 2026 correction.
KEY TENSIONS
A small definition against a large word: Labaschin defines the agent as a frontend around a model, and by 2026 the same word describes a system that plans, calls tools, keeps memory and retries when a step fails. Both usages are current, and they are not the same object. A reader who buys a wrapper expecting a worker will be disappointed, and a reader who dismisses the wrapper because it is not a worker will miss the tool that actually ships.
Three archetypes against a market of thousands of products: The report reduces the field to document question answering, instruction-scoped chatbots and code assistants. That is a useful cut because each archetype has a different failure mode, and it is also a simplification, because the products a company actually buys in 2026 usually combine two of the three inside one interface.
Productivity claims against verification cost: The report is honest that code assistants can produce wrong output that makes a problem snowball, and it treats human oversight as the answer. It does not price that oversight. Once verification takes longer than writing the code, the productivity gain is a measurement problem rather than a fact.
Cheap to build against expensive to run: The build examples use open components that cost nothing to start, and the report notes that maintaining an agent is costly because inference is costly. The gap between the two numbers is where most pilots die, since a demonstration is cheap and a service level is not.
Open weights against a proprietary subscription: Llama 2 running on a laptop and ChatGPT Plus at about twenty dollars a month represent two different futures for the same capability, one where the model is infrastructure you host and one where it is a service you rent. The report presents both without arguing the choice, and the choice has since become the central procurement question.
Adoption as a competitive divide against the evidence behind it: The figures on who has invested in AI come from a census survey, and the conclusion drawn from them is that small firms are falling behind large ones. The numbers are real and they describe 2020, which is a long time before the products in this report existed.
WHY IT MATTERS NOW
The wrapper stopped being a novelty and became the default surface of software. Every suite a fellow opens in 2026 has a text box that accepts a question about the open document, and almost none of those boxes are autonomous. The report describes the design logic of exactly that layer, which is why it still reads as current even where its examples do not.
The questions it raises moved from engineering to governance. Confidential data pasted into an agent, models trained on material without permission, the tone an agent is given and what that tone teaches users: these were ethical footnotes in 2023 and they are procurement clauses now. A buyer who cannot answer them cannot sign.
The capability it describes is no longer scarce. Anyone can put a chat interface in front of a model in an afternoon, which is the report's implicit point and the reason its three archetypes matter more than its tools. The scarce part is deciding which archetype a task needs, what the agent is allowed to touch, and who signs off when it is wrong. That is a management decision wearing a technical costume, and the U365 methods exist to make it in the open.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
OVERVIEW
The report runs in five movements and about forty pages. It opens with a definition and the engine analogy, then answers the question of when to use an agent with three archetypes, each supported by a scenario at a fictional employer called Very Fake Company, Inc. A new employee receives a stack of onboarding documents, an IT chatbot called BERTA checks whether he may activate a code editor, and a code assistant translates a Python function into Java. The scenarios are deliberately ordinary, and they work because the reader has lived each one.
The third movement turns the fiction into software. Chainlit and PandasAI build the document question and answer agent, HuggingFace Chat with Llama 2 and Streamlit build the chatbot, and ChatGPT Plus stands in for the code assistant, with GitHub Copilot, Amazon CodeWhisperer and StarCoder named as the familiar alternatives. The report walks through the interfaces figure by figure, which is the most useful part for a reader who has never opened one of these tools.
The fourth movement looks forward through three lenses. Search is examined as the first product category that agents might replace rather than assist, with the advertising model as the unsolved problem. Product integration is examined as a divide between companies that embed agents and companies that refuse, with adoption statistics attached. Infrastructure is examined as a cost problem being solved by local models and streaming, and LLMOps is named as the job category that follows.
The fifth movement is a short ethics and legislation section, and a conclusion that argues the technology is out of the bottle and the only open question is how it will be used. Two features of the report are worth naming before the analysis. The transcripts in the scenarios were generated with GPT-4 in August 2023 and the footnotes say so, which is unusually transparent. And several of the figures come from a 2020 census survey of firm adoption, which is the oldest evidence in the report and carries its strongest economic claim.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
KEY IDEAS
THE WRAPPER DEFINITION
The core claim is that an agent is a user interface around a model, and that its job is to focus and limit what the user can do with that model. Labaschin's example is ChatGPT, where two models of very different capability sit behind one text box and the user never chooses parameters. The definition is a design claim rather than a technical one, and it has three consequences. The value of an agent comes from what it hides, not from what it adds. The quality ceiling is set by the model. And the product work is mostly the reduction of options.
This is worth keeping because it explains a pattern readers notice and rarely name. Two products built on the same model can differ enormously in usefulness, and the difference is almost always the constraint: the input form, the document scope, the refusal behaviour, the way a follow-up question is handled. When a team says its agent underperforms, the first question should be what the interface allows the user to ask.
THE ENGINE AND THE CAR
The second idea is the division of labour between model and agent, and the report's version of it is deliberately mechanical. Engines are built for purposes, an ATV engine is not a school bus engine, and the engineers who build models build them for tasks. A code agent should be powered by a model trained on code. The user drives the car and does not service the engine.
The distinction has held up better than the specific model names. What has changed is that the engine can now be swapped by configuration in many products, which turns the choice into a procurement question about cost, latency, data residency and evaluation rather than a design commitment. The report's advice survives that change intact: match the engine to the task, and do not ask the driver to understand the engine.
THREE ARCHETYPES, THREE FAILURE MODES
Document question and answer agents answer questions from material the user supplies. Their promise is the end of manual search through a stack of files, and their failure mode is a confident answer assembled from the wrong passage. Chatbot agents answer from instructions written before the conversation begins. Their promise is a service that runs without a person, and their failure mode is an instruction set that does not cover the case in front of it. Code assistant agents complete and transform code inside an editor. Their promise is the end of context switching, and their failure mode is plausible code that does not run.
Reading the three together is more useful than reading any one of them. The archetypes differ in where the truth lives, which is the document for the first, the prompt for the second, and the compiler for the third. That single difference predicts how much verification each one needs, and it is the reason a code assistant can be trusted with a first draft while a document agent should be trusted with a citation and nothing else.
WHAT THE BUILD EXAMPLES ACTUALLY SHOW
The Chainlit and PandasAI example is a retrieval system with a natural language front end. The user uploads a file of book data, the agent reports the column names, and PandasAI converts a question into a data operation. The interesting detail is that the model is not asked to know the data, it is asked to write the manipulation, and the manipulation runs against the file. That architecture is the ancestor of every serious document agent in production today, and it is the reason the example still teaches something.
The chatbot example shows the opposite architecture. Nothing is retrieved, and everything depends on the instructions and the persona, which the report illustrates with a HuggingFace conversation in which the agent is told exactly what role to play. The demonstration proves that explicit instructions produce structured answers. It also shows the weakness of the pattern, because a chatbot with no document access can only be as good as the policy someone wrote for it.
The code assistant example is the thinnest technically and the strongest commercially. ChatGPT Plus at about twenty dollars a month reads a data file and produces a bar chart, and the report notes that the same agent is used by venture capitalists, researchers, executive assistants and students. The figure is not the chart. The figure is that one subscription covers four job functions that used to require four tools.
THE ECONOMICS OF SEARCH
The analysis of search is the most speculative section and the most instructive. If an agent can summarise an answer without a click, the pay-per-click model loses the click, and an entire revenue architecture has to be rebuilt. Labaschin does not resolve it. He names the candidates, including micro-payments to the authors of summarised material, and observes that whatever emerges will be different because the mechanism that funded the web was attention.
A reader should treat this as a template rather than a forecast. The same question now sits under every content business, including education: what happens to a publication when the answer can be extracted without the reading. The report's contribution is to name the mechanism early, which is that an agent which answers directly removes the advertising inventory that paid for the answer.
ADOPTION AND THE SUPERSTAR DIVIDE
The report's economic argument rests on one set of numbers, and it is worth stating plainly. About a quarter of companies with more than 250 employees had invested in AI of any kind, and that rate was roughly three times the rate among firms with fewer than ten employees, at 7.7 percent. The source is a census survey published in 2020. From those figures the report draws a warning, quoting Erik Brynjolfsson of Stanford, that at current rates of investment we are flying blind into what has been called the fourth industrial revolution.
The warning has aged well and the numbers have not. A 2020 survey cannot describe a market that formed in 2023, and a reader who repeats the figures in 2026 is quoting a baseline rather than a trend. What survives is the structural claim, which is that general purpose technology concentrates at the top unless something distributes it, and that the distributors are usually cheap interfaces rather than new models.
INFRASTRUCTURE AND THE COST FLOOR
The section on infrastructure is where the report is most prescient and least specific. Running an agent costs money because inference costs money, the cost falls as models get smaller and better served, and the people who understand serving become valuable. The report names LLMOps and predicts that specialists will be well employed and well remunerated. That prediction has held.
The mechanism it identifies is the one that mattered. Local execution of a capable open model, streaming tokens so that a response begins before it is finished, and hosted inference priced per token all move the same number, which is cost per completed task. A team that cannot state that number cannot tell whether its agent is a product or a demonstration.
THE ETHICAL EDGE OF THE SAME FEATURE
The report's ethical section is short and its argument is sharp. The properties that make an agent useful are the properties that make it dangerous. An agent that accepts any input will receive confidential input. An agent that speaks naturally will be trusted beyond its competence. An agent built on a model trained on the open web inherits the permissions of that training data, which in many cases were never granted.
Two examples carry the section. The first is data leakage: unsuspecting users have given agents confidential company and personal information that can compromise intellectual property. The second is persona: the default tone and voice of an agent may encode a gender, and the report asks whether that is a design choice with social consequences. Both questions are now standard items in a vendor review, and neither had a standard answer in 2023.
WHAT THE REPORT DOES NOT COVER
Four absences define the distance between this report and a 2026 deployment. There is no evaluation method, so a reader learns what an agent does and not how to measure whether it does it reliably. There is no permission model beyond a warning about leaks, so the question of what an agent may read, write or send is left open. There is no failure taxonomy, which matters because agent failures are rarely wrong answers and usually wrong actions. And there is no cost model per task, only the general statement that inference is expensive.
None of these gaps is a criticism of a forty-page primer written in 2023. They are the agenda a reader has to bring. The value of the report is that its three archetypes give that agenda a shape, since each absence maps to a different archetype and a different control.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
ULM ALIGNMENT
At University 365, the CI-First (Co-Intelligence-First) doctrine teaches you to invite AI into your reflection and work while remaining the orchestrator. Co-Intelligence means that the result is human intelligence plus the product of AI and human intelligence, so the machine multiplies a judgement that a person still owns. This Book Essential connects the report's three agent archetypes to the U365 methods that decide where each one belongs: ULM+EVA (University 365 Life Management powered by the Explore-Visualize-Action Plan cycle) fixes which life domain an agent is serving and what outcome it must move; LIPS+CARE (your digital second brain with the Collect-Action Plan-Review-Execute cycle) is the document store that a question and answer agent reads, which is why retrieval quality and folder discipline are the same problem; and SL-OS (Successful Life Operating System) integrates the methods with UP-Context-Engineering (context engineering for AI), which is the layer that makes a chatbot's instructions explicit instead of assumed.
SCHEMA PRIME: ULM Domain: Career and Finance
DOMAIN MAPPING: Primary: Career and Finance, because the report is about the tools that produce work and the labour market that forms around them. Secondary: Quality of Life, because the document and chatbot archetypes change how a person handles administrative load, and Spirit and Mind, because the verification habit the report demands is a discipline of attention rather than a technical skill.
EVA PARAGRAPH: You want to stop guessing which AI tool your work actually needs, and to choose one that survives a bad week rather than a good demonstration. The obstacle is that every product looks like every other product in a fifteen minute trial, because the differences only appear when the input is your real material and the output is checked. The plan: pick one recurring task you already do weekly, write down what a correct output contains, run the same five inputs through one candidate tool, score each output against your written list, and record the time you spent verifying. Ten minutes of scoring replaces a month of opinion. If the tool cannot beat your current method on that one task, the archetype is wrong and no amount of prompt writing will fix it.
LIPS+CARE CAPTURE CARD:
Book: What Are AI Agents? When and How to Use LLM Agents
Primary ULM Domain: Career and Finance
3 Key Takeaways:
1. An agent is a constrained interface around a model, so its usefulness comes from what it hides and its ceiling comes from the model underneath.
2. The three archetypes fail differently because the truth lives in a different place: the document for question answering, the instruction set for chatbots, the compiler for code assistants.
3. Verification is the real cost of every archetype, and a tool whose output you cannot check in less time than it takes to produce is a demonstration rather than a method.
Apply It Action: In the Career and Finance domain, take the one recurring task you most often postpone and run a five input test against a single tool in the archetype that matches it, scoring each output against a written definition of correct and logging the minutes spent verifying.
Next CARE Step: Collect, by moving every document that test touched into one LIPS folder with a naming convention, so that the next tool you evaluate reads the same corpus instead of a new one.
EXPLAINER LINK: For more on ULM, EVA, LIPS and CARE methods, see the ULM page and the LIPS page. For the CI-First doctrine, see the CI-First page. For the full SL-OS framework, see the SL-OS page.
APPLY IT (domain-tagged): In the Career and Finance domain, write the specification for one agent before you compare any product: the inputs it may read, the actions it may take, the output format you will accept, and the person who signs off when it is wrong. One page, four lines, and the buying decision becomes a test rather than a preference.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
SUMMARY
MINDMAP SKELETON
Center: What Are AI Agents?, by Benjamin Labaschin.
Branch 1: The definition. Agent as frontend, ChatGPT as the example, constraint as the design, the model as the ceiling.
Branch 2: The engine. LLMs as engines, purpose built models, the driver does not service the car, agents as the route to ubiquity.
Branch 3: Document Q&A. Information glut, ingestion and memory, the onboarding stack, Chainlit and PandasAI, retrieval as the ancestor.
Branch 4: Chatbots. Prompts before the conversation, BERTA at Very Fake Company, third party access, HuggingFace and Llama 2, explicit instructions.
Branch 5: Code assistants. Copilot, CodeWhisperer, StarCoder, context switching, the Python to Java example, verification with human oversight.
Branch 6: The horizon. Augmented search and ad revenue, integration against isolation, LLMOps and cost, leaks and legislation, the genie.
Chapter 1: The Definition
Labaschin's answer to his own title is a sentence rather than a taxonomy: agents are tools that let users talk to language models in order to finish a productive or creative task. The elaboration is the useful part. An agent is a frontend, it focuses and limits the interaction, and it exists because the model underneath is too complex to operate directly. ChatGPT with GPT-4 or GPT-3.5 behind one text box is the demonstration, and the point is that the user does not choose the engine or set the parameters.
Read in 2026, the definition is narrower than the common usage and more useful than the hype. A modern agent plans, calls tools and retries, and the report's wrapper does none of that. What survives is the design insight: the constraint is the product. Every tool a fellow opens today, from a document assistant to a coding editor to a support chat, is a decision about what the user is allowed to ask and what the system is allowed to do with the answer.
The definition also explains the market structure the report describes later. If an agent is a wrapper, then wrappers are cheap to build and the competition moves to distribution and trust, which is exactly what happened. The companies that won the following two years were not the ones with the best model. They were the ones whose wrapper sat where the work already happened.
Chapter 2: The Engine
The engine analogy is the report's best teaching device and its most portable idea. Language models are engines, engines are built for purposes, and an agent is the car that makes an engine usable by someone who will never open the bonnet. The ATV engine against the school bus engine does the work of explaining why a code agent should use a code model, and the GitHub Copilot example makes it concrete.
The analogy also carries a warning the report does not state directly. An engine is not judged by its specification sheet but by the drive, and a car with the wrong engine for the terrain is worse than a slower car with the right one. Teams that choose models by benchmark position repeat the mistake of choosing a vehicle by horsepower, and the report's alternative is the right one, which is to start from the task and work backwards.
What has changed since is the swap. In 2023 the engine was often fixed by the product. In 2026 many products expose the choice, and the same wrapper can run on a hosted frontier model, a smaller model, or an open model on your own hardware. The analogy survives the change, and it adds a question the report could not ask: which engine may this car use without moving the data somewhere the organisation has not agreed to.
Chapter 3: Document Question and Answer Agents
The first archetype addresses information glut. The agent ingests documents, holds them in memory, and answers questions about their content, which the report illustrates with an onboarding stack at Very Fake Company, Inc. and a transcript that summarises values, hours, dress code, IT contacts, parking and first tasks. The promise is real and the reader recognises it immediately, because the task the agent performs is the task that consumes the first week of a new job.
The mechanism is the part worth extracting. The model is not asked to know the documents. It is asked to consolidate and return what they contain, which means the system needs ingestion, storage, retrieval and an interface. In 2026 that stack has names, embeddings, chunking, a vector store, a reranker, and the quality of the answer is decided almost entirely before the model speaks, by what was retrieved.
The failure mode follows from the mechanism and the report does not name it. A retrieval system that misses the relevant passage produces an answer that is fluent, confident and wrong, and the user has no way to tell from the prose. The correction is structural: cite the passage, show the source, and make the interface refuse when nothing was retrieved. That is a design decision in the wrapper, which returns the report's definition to the centre of the argument.
Chapter 4: Chatbot Agents
The second archetype is the one most readers have met. A chatbot agent is given instructions before any user arrives, and it follows them for the whole conversation. The report's example is BERTA, an IT agent whose name is an acronym, whose role is to verify employment, check a database and activate a licence, and whose instructions end with the address to give a user who is not permitted. The fictional prompt is short, and every sentence in it is a decision about authority.
This is the archetype where the report is closest to current practice and furthest from current risk. The instruction set is a policy, and a policy written in prose has the same problems as a policy written by a committee: it does not cover the case in front of it, and it cannot be tested for consistency. The report's remedy is to be explicit, which is correct and incomplete, since explicitness without an evaluation set produces a chatbot that is confidently wrong in a consistent voice.
The connection to UP-Context is direct. A chatbot is a persona plus a scope plus a refusal rule, and writing those three parts down before the conversation is exactly what context engineering formalises. The report's BERTA example is a small, honest version of the exercise: the agent knows what it may check, what it may change, and to whom it must hand the case.
Chapter 5: Code Assistant Agents
The third archetype is the most commercially proven and the least mysterious. Code assistants complete functions, translate between languages, fix errors and generate templates, and the report names GitHub Copilot, Amazon CodeWhisperer and Hugging Face StarCoder. The scenario is a Python function converted to Java through autocompletion, which is a fair illustration of what the tool does and a generous illustration of how much it does.
The report's honesty is concentrated in this chapter. It says plainly that code assistants can generate wrong or misguided output that makes problems snowball, and it insists on human oversight and on tools that work for the user rather than the other way around. That sentence is the most durable line in the report, and it is the reason the chapter still reads well: it treats the tool as a tool.
What it does not do is give the reader a test. The verification rule that has emerged since is simple enough to state and hard enough to follow: accept a completion when you can read it faster than you could write it, which means small functions, familiar idioms, and a test you can run. Accept nothing you cannot read, and never accept a change to code you do not understand.
Chapter 6: The Real Tools
The build section turns the three scenarios into software and it is the part of the report a practical reader should read with a notebook open. Chainlit supplies the interface and PandasAI performs the data operations for the document agent. HuggingFace Chat with Llama 2 and Streamlit supplies the chatbot. ChatGPT Plus, at about twenty dollars a month, supplies the code assistant, and the example asks it to read a data file and draw a bar chart styled to Edward Tufte's advice.
Two details make the section more valuable than a tutorial. The first is that the document example separates language from execution, since PandasAI translates a question into an operation and the operation runs on the data. The second is that the chatbot example is built on an open model, which shows that the wrapper is independent of the engine, a claim the rest of the report asserts and this chapter demonstrates.
The section also dates the report more clearly than any other. Chainlit, PandasAI, Streamlit and Llama 2 were the accessible stack of late 2023, and the pattern they represent, a small interface over a model over a data source, is the pattern that survived. The specific libraries have moved. The architecture has not.
Chapter 7: What Moves Next
The forward section makes three arguments and one of them has already been settled. Search was the first candidate for replacement, because an agent that answers a question removes the click that pays for the answer, and the report is honest that no one had solved the economics. Two years later the answer arrived in the form of assistants embedded in existing search products rather than replacements for them, which is a partial vindication of the report's caution.
The second argument is about integration. Some companies embedded agents in their products, others refused, and the report used adoption figures from 2020 to argue that the divide would widen into a gap between small firms and superstar firms. The prediction was right in direction and the evidence was older than the products it described, which is a fair criticism of the report rather than of the prediction.
The third argument is about infrastructure and it is the one that most deserves rereading. Inference is expensive, cost falls with smaller models, local execution and streaming, and the specialists who can serve models well will be in demand. LLMOps is the name the report gave that role. It has since become a job title, a budget line and the difference between an agent that runs at a fixed price and one that runs at a variable one.
Chapter 8: Security, Legislation and the Ending
The closing chapter turns from capability to consequence, and its argument is compact: the same properties that make agents useful make them dangerous. An agent that accepts input will receive secrets. An agent that sounds human will be trusted. An agent built on models trained on the open web inherits permissions that were never granted, and it can repeat falsehoods at scale. The report adds the persona question, whether the voice given to an agent encodes a gender and what that teaches, which is the kind of detail that separates a considered report from a product brochure.
The legislative prediction has aged in an unusual way. The report expected regulation to arrive and to matter, and by 2026 the rules exist in several jurisdictions while the enforcement is uneven and the technical questions remain open. A reader should treat the chapter as a checklist of exposures rather than a forecast, because every item on it is now something a vendor review asks about.
The conclusion is a single paragraph and it is the sentence the report will be remembered for. The genie is out of the bottle, too many people have benefited for the tools to be ignored, and the question is not whether agents will be used but how. That is the correct place to stop a short report, and it is also the correct place to start the work, since the how is decided in interfaces, permissions and review, which are all things a person still chooses.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
IN PRACTICE
1. Name the archetype before you name the product.
The three archetypes are a buying filter, not a taxonomy for a slide. If the task is answering questions from documents, the product must ingest and cite. If the task is handling a repetitive conversation, the product must hold an instruction set and refuse outside it. If the task is writing code, the product must sit in the editor and run. A tool that does two of the three badly is worse than a tool that does one of them reliably.
Action: write the archetype, the input it reads and the output you accept on one line before you open a single vendor page.
2. Write the definition of correct before the demonstration.
A demonstration is designed to succeed on the demonstrator's material. Your material is the only test that matters, and you cannot score an answer without a written standard. One page with five examples of a good output, two examples of a bad one and the reason for each turns a preference into a test that two colleagues can apply and agree on.
Action: write the five good and two bad examples from your own archive, and score the next trial against them out loud.
3. Run a five input test and log the verification minutes.
Five real inputs, the same five for every candidate, and a stopwatch on the checking. The number you want is not the time saved on generation, it is the net time after verification, and it can be negative. A tool that produces an answer in four seconds that you spend nine minutes checking has saved nothing, and the report is right that the checking is the part that cannot be delegated.
Action: build the five input set today and keep the score sheet in one LIPS note so the next evaluation starts from evidence rather than memory.
4. Put a permission line under every agent you deploy.
The report warns that users hand confidential material to agents and that agents can compromise intellectual property. The correction is structural: state what the agent may read, what it may write, where the data lives after the session and who can retrieve it. In a personal setup that is a folder boundary in LIPS. In a team setup it is a data processing agreement and an access list.
Action: draft the four-line permission block for the one agent you use most, and delete the data source it should never have been given.
5. Keep the human decision where the cost of being wrong is highest.
Co-Intelligence is not a slogan about collaboration, it is an allocation rule. The agent drafts, retrieves, transforms and proposes. The person decides what is sent, published, signed or deleted. The report's own line about tools that work for you rather than the other way around is the same rule stated without the doctrine.
Action: list the three decisions in your work that an agent may never make alone, and write them into the tool's own instructions.
6. Re-test the archetype every quarter, not the product.
Products change faster than tasks. The wrapper you rejected in January may have gained citations, and the model you chose in March may have been replaced under the same name. What does not change quickly is the shape of your task, which is why the quarterly review belongs to the task and the annual review belongs to the contract.
Action: put one recurring date in the calendar where you re-run the five input test on whatever tool currently serves the task.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
QUIZ: TEST YOUR UNDERSTANDING
Question 1: Labaschin defines an agent as a frontend around a language model, and most people in 2026 use the word for a system that plans and calls tools. Which definition should you use when you brief a supplier, and what does the choice change?
Answer: Use the narrow one in the brief, and name the capabilities separately. Say whether the system may plan, call tools, keep memory or act without confirmation, and treat each of those as a line item rather than an implication of the word agent.
Explanation: The report's definition describes the interface layer, which is what most products actually sell. The wider definition describes an architecture. Mixing them lets a supplier sell a wrapper against an expectation of autonomy, and the mismatch only appears after the contract is signed.
Question 2: A fellow uploads a two hundred page report and asks an agent to summarise the section on liability. The answer is fluent, confident and wrong. Using the report's own architecture, where did the failure most likely occur?
Answer: In retrieval, before the model spoke. The system did not return the liability section to the model, so the model answered from whatever it did receive and filled the gap with plausible prose.
Explanation: The document archetype ingests, stores and retrieves, and the report is explicit that the agent consolidates and returns what it was given. That means the quality of the answer is decided by what was selected. The correction is to require a citation for every claim and to make the interface refuse when nothing was retrieved.
Question 3: An IT team writes a long instruction set for a support chatbot. It answers correctly in testing and gives a customer the wrong refund policy in week two. Is this an instruction problem or a model problem?
Answer: It is an instruction problem with a testing gap. The instruction set did not cover the case, and no evaluation set existed to find the gap before a customer did.
Explanation: Chatbot agents follow prompts written before the conversation, which makes the prompt a policy. A policy without an evaluation set is a hope. The report's advice to be explicit is necessary and not sufficient, because explicitness without test cases produces a consistent voice and inconsistent answers.
Question 4: A developer accepts every completion from a code assistant because the tests pass. What does the report's warning require you to add, and why do passing tests not close the question?
Answer: Add a reading rule. Accept a completion only if you can read it faster than you could write it, and only if you understand every line. Tests cover the cases you thought of, and a completion can pass them while changing behaviour nobody wrote a test for.
Explanation: The report says code assistants can produce wrong output that makes problems snowball, and it puts human oversight in the repair position. Oversight only works on code the reader understands, so the acceptance rule has to be about comprehension rather than about the colour of the test run.
Question 5: The report argues that search advertising has no obvious funding model once an agent answers without a click. Which part of that argument survives to 2026, and which part does not?
Answer: The mechanism survives, which is that answering directly removes the inventory that paid for the answer. The forecast that agents would replace search does not, because the assistants arrived inside the existing search products rather than in place of them.
Explanation: The report was careful enough to say that whatever funding mechanism emerges will be different, and it did not claim to know it. What it got right was the direction of the pressure, and that pressure is now visible in every publisher's traffic numbers.
How many did you get right? Which ones surprised you?
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
CAN THIS BOOK ESSENTIAL REPLACE THE ORIGINAL?
No. This Essential is an analysis of a short report, and the report's value is in its compactness. Labaschin walks a reader through three interfaces figure by figure in about thirty minutes of reading, and that walkthrough is the part this analysis can describe and cannot replace. Read the original for the demonstrations. Read this Essential when you have to decide which archetype your own work needs, and what the report leaves out before you can deploy one.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
QUOTES
"AI agents are tools designed to allow users to interact with LLMs to achieve a more productive or creative workflow as seamlessly as possible."
"you might think of AI agents as UI “wrappers” around the models that power them."
"you can think of AI agents as cars, while the models that fuel them can be thought of as their engines."
"users of AI agents do not need to understand how the car’s engine works to drive it."
"Document Q&A agents are AI-enabled tools designed for the problem of information glut."
"chatbot agents are far more dynamic in their capabilities."
"Chatbot agents are also a great choice when companies anticipate being contacted more frequently and in greater numbers than they might otherwise be able to handle."
"code assistant agents reduce the need for such costly context switching, allowing for large improvements in productivity."
"Like all AI agents, code assistant agents are tools, and as with any tool, you must know when and how to wield them."
"Code assistant tools can easily generate wrong or misguided output that can cause problems to snowball."
"AI agents are actual tools that are really being used every single day by millions of people."
"Search engines are a prime example of products that will be augmented by AI agents or even replaced altogether."
"Maintaining AI agents can be a costly affair."
"for the very same reason that AI agents can be useful, they can also be dangerous."
"The question moving forward with AI agents isn’t whether they will be used but how they will be used."
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
AUTHOR'S EXPERTISE
Benjamin Labaschin is a machine learning engineer, and the report's authority comes from practice rather than from research. At the time of writing he was principal machine learning engineer at Workhelix, where he worked on generative AI and large language models applied to economic problems. His earlier roles include machine learning work at Hopper, XPO Logistics and Blackstone, which is a record of applied modelling in companies whose business is operations, logistics and capital rather than software products.
That background explains the shape of the report. It is written by someone who has shipped models into organisations and has watched non-technical colleagues try to use them, which is why the three archetypes are organised around the person at the interface rather than around the architecture. The fictional employer, the transcripts and the step-by-step interface walkthroughs are the work of a practitioner who knows that adoption is decided by the first five minutes of use.
The report is also candid about its own production in a way that matters for a reader assessing it. Several of the demonstration transcripts were generated with GPT-4 in August 2023 and the footnotes say so, including the onboarding summary and the Java conversion. That disclosure is unusual and it should raise the reader's confidence in the rest of the sourcing rather than lower it, because the author distinguishes what he observed from what a model produced for illustration.
What the report does not claim is research authority. There is no original study here, and the economic argument leans on a census survey and a quoted economist rather than on the author's own measurement. A reader who wants a practitioner's map of the tool landscape in late 2023 is well served. A reader who wants evidence about productivity effects should go to the evaluation literature, which is where the numbers now live.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
RESOURCES
The report: What Are AI Agents? by Benjamin Labaschin (O'Reilly Media, November 2023, 26 pages). An audiobook edition was released in April 2025, and the author's current work is at Workhelix.
The three tools the report builds with: Chainlit for the conversational front end, PandasAI for the data operations behind it, and Hugging Face Chat for the open model chatbot example. The report also points to Hands-On Large Language Models by Jay Alammar and Maarten Grootendorst for the implementation detail it does not cover.
For the architecture the report predates: Anthropic's guide to building effective agents sets out the workflow against agent distinction that the 2026 vocabulary assumes, OpenAI's function calling documentation covers the mechanism that turns a wrapper into a tool-using system, and the AutoGen and LangChain repositories are the two reference implementations most teams read first.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
NEXT STEPS
Choose the archetype this week: Write the task, the input and the accepted output on one line, then match it to document question answering, chatbot or code assistant. Most wasted budgets come from buying the wrong archetype and blaming the model.
Build the five input test: Five real inputs, a written definition of correct, and a stopwatch on verification. This is the only evaluation method this Essential asks you to adopt, and it costs an hour.
Write the permission block: What the agent may read, what it may write, where the data goes and who can retrieve it. In LIPS this is a folder boundary. In a company it is a processing agreement.
Keep one human decision per workflow: Drafting, retrieval and transformation belong to the agent. Sending, publishing, signing and deleting stay with the person who is accountable for the result.
Re-test the task, not the product: Products change under the same name. Put one recurring date in the calendar where the same five inputs run against whatever tool currently serves the task.
Read the newer material before you scale: The report stops before tool calling, memory and planning became standard. Before a deployment that acts rather than answers, read the architecture guides in the resources above, because the failure modes of an acting agent are different from the failure modes of a wrapper.
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
U365'S RECOMMENDATIONS TO LEARN MORE
This list collects the first-party pages, the videos and the reference material that teach something this Essential does not. Every link was checked at the time of writing. Information verified as of 2026-11-08.
Official learning resources
Video tutorials and channels
A clear walk from a bare language model through a workflow to an agent that decides, with real examples at each level, by Jeff Su, Apr 08, 2025, 10:09
Written tutorials and deep-dive articles
Community and social
Resources on X
Dedicated X channels:
What Are AI Agents? When and How to Use LLM Agents (Benjamin Labaschin)
IMPORTANT NOTICE
This Book Essential is an original summary and critical analysis of What Are AI Agents? When and How to Use LLM Agents by Benjamin Labaschin (O'Reilly Media, 2023). Short quotations from the report are attributed and cited for purposes of criticism, review and education. All rights in the original work belong to its author and publisher; this Essential is not a substitute for the report, and a reader who wants the demonstrations should read the original at the publisher's page.
This publication is part of University 365's learning library. Explore INSIDE, our publications and our programs. The best summary is not a substitute for the book. Read the original. Discuss this report with a U.Coach.
Note: verify current editions before relying on this comparison. Information verified as of 2026-11-08.
Comments