Agentic AI: what it means

The distinction between a chatbot and an agent is not a matter of marketing terminology. It reflects a genuine difference in how the system operates. A chatbot responds to a single prompt and produces a single output; the interaction is complete when the response is delivered. An agent, by contrast, pursues a goal across multiple steps, taking actions and making decisions based on what each step produces before proceeding to the next.

For example, when a practitioner asks a standard chatbot to draft a reference follow-up email, the chatbot produces the email from the prompt alone. An agent given the same goal might work through several steps. It might retrieve the patron's original question from a connected system and examine the practitioner's previous correspondence to match the established tone. It might then verify that the resource it plans to recommend is still available, draft the email, and present it for review before sending. That process involves multiple steps, tool use, and intermediate judgment, none of which characterizes a standard chatbot interaction.

The characteristics that define agentic AI are worth understanding in concrete terms. Multistep execution means the system breaks a goal into component tasks and completes them in sequence rather than in a single response. Tool use means the system can take actions beyond generating text, including searching the web, reading and writing files, calling external APIs, and sending communications. Memory means the system can retain information across steps within a task, using earlier results to inform later ones. Judgment means the system makes decisions about what to do next based on what it has found, rather than following a fixed script.

Most AI systems library professionals encounter today sit somewhere on a spectrum between simple chatbot and fully autonomous agent. Claude Projects and ChatGPT Projects occupy the lighter end. They are not truly autonomous, but they persist context across conversations and support more complex assistance than a single-turn chatbot. Fully autonomous agents that can execute multistep library tasks without human oversight are emerging but not yet common in library practice. The more agentic end of the spectrum is no longer hypothetical, however. General assistants now include agent modes that operate a web browser on the user's behalf, ChatGPT's agent mode and Claude in Chrome among them. Connectors built on the Model Context Protocol let an assistant read from and act in other systems, such as calendars, file stores, and ticketing tools. These capabilities are already available to individual librarians, often on consumer plans. The current moment is therefore well suited to building familiarity with the lighter agentic tools. It is also the time to settle the governance questions covered later in this module, before the more autonomous tools arrive in library systems.

Claude Projects is not the most capable agentic tool available in October 2026; the browser agents and connectors described above go considerably further. It is, however, the lowest-risk place for library work to begin. It takes no autonomous actions without practitioner input, yet it works as a persistent, context-aware workspace that carries institutional knowledge across every conversation in the project. Starting here builds the habits of scoping, instructing, and reviewing that the more autonomous tools demand, without yet handing them the ability to act. To see why this matters in practice, compare it directly with a standard AI conversation.

A standard AI conversation begins with no knowledge of previous sessions, the institution, the patron population, or the practitioner's preferences. The practitioner must re-establish context in every session before the work can begin. A Claude Project eliminates this overhead entirely. Custom instructions set for a project persist across every conversation in it, and uploaded files remain available for reference throughout. The project works as a standing briefing that never needs repeating.

For example, a reference desk project might be configured with custom instructions like these. This assistant supports a reference librarian at a community college library serving primarily first-generation college students and working adults. Always recommend specific databases from the attached list rather than generic suggestions. Maintain a warm, clear, jargon-free tone in all patron-facing drafts. With those instructions in place and the library's database list and FAQ document uploaded, every later conversation in the project has full institutional context. Drafting a patron response then requires only pasting the patron's question, with no need to explain the library's context first.

A second project can be configured independently for a different library function. For example, an instruction design project might carry custom instructions describing the institution's course levels, typical session length, and ACRL Framework alignment, with existing lesson plans uploaded as templates. The practitioner can then request a lesson plan draft for a specific course section without re-explaining institutional parameters each time. Projects can also serve collection development support, assessment drafting, or any other recurring library function where persistent context would cut setup time at the start of each working session.

There is a meaningful gap between what vendors claim agentic AI can do and what is practical in library settings today. An honest assessment of current capability is more useful than an optimistic one, because overestimating reliability leads to implementations that fail in consequential ways.

Several applications are practical today and have been demonstrated in library contexts. Multistep research assistance is one of the most reliable. An agent can search a topic across multiple sources, read and synthesize the results, identify gaps, generate follow-up search terms, and produce a structured report for the practitioner's review. For example, a practitioner preparing for a research consultation can submit the patron's topic and assignment description. Back comes a pre-consultation briefing with relevant databases, preliminary search terms, and suggested clarifying questions, in the time it once took to open a single database. This workflow does not replace the practitioner's judgment in the consultation itself. It reduces the time needed to arrive at that consultation well prepared.

Document processing pipelines are another practical application. For example, an agent can ingest a set of assessment survey responses, extract recurring themes, count references to specific library services, and compile the results into a structured summary for the practitioner to review and interpret. These pipelines are most reliable when the documents follow a consistent structure and the extraction task is well-defined. Conversational FAQ interfaces are also practical today. They let patrons ask questions about library services and receive responses drawn from a knowledge base the library provides. They do, however, require careful configuration and ongoing review of the responses they generate.

Several capabilities that receive significant vendor attention are not yet reliable enough for library use without substantial caution. These include fully autonomous catalog record creation without human review, and autonomous management of patron communications. They also include multisystem workflows that take action in an ILS, send email, and update spreadsheets without a human approval step at each stage. All are emerging, but none is yet reliable enough for production library use. Any agentic system that takes action in a patron-facing context needs particularly careful evaluation. Agentic AI executes steps so quickly that errors spread before a human has a chance to intervene.

The most practically useful agentic capability available to library professionals today is not autonomous task execution but persistent memory and context. A well-configured set of custom instructions is, in effect, a standing briefing that turns every AI interaction from a cold start into a contextualized one. The thirty to forty-five minutes it takes to write good custom instructions once is one of the highest-return investments available in AI-assisted library work.

Effective custom instructions for library use cover several categories of institutional and professional context. The institution type and size establish the operating environment. For example, "community college library serving approximately eight thousand students" tells the AI system something materially different from "research university library." Patron population characteristics matter equally. First-generation college students need a different communication register, and different assumptions about prior research experience, than graduate students in a specialized research program. State these differences explicitly rather than leaving the AI to infer them.

Role and primary responsibilities give the system what it needs to judge the relevance of its suggestions. Specifying the preferred tone for different output types (patron-facing versus internal, formal report versus quick email) keeps the system from defaulting to a generic register that does not match the library's voice. Name particular databases or resources to reference, and state explicitly what the system should not do. Examples include recommending Wikipedia as a primary source or suggesting resources the library does not subscribe to. These instructions prevent outputs that need correction before use.

Where a tool offers memory features, they extend the value of custom instructions beyond what can be stated in advance. For example, Claude's memory feature and ChatGPT's memory let the system retain information the practitioner specifies across conversations over time. This can include preferences, ongoing project context, and institutional details that would otherwise need restating. Treat these features as a convenience, not a guarantee. Before relying on stored context for consequential work, verify that it is actually present. Memory features in current AI tools are not fully reliable and can fail to retrieve stored information under some conditions.

The use cases described here are practical in current library settings, not aspirational scenarios dependent on capabilities that do not yet exist. Each requires practitioner review of the output; none operates without human judgment at the point of use.

Research consultation preparation is one of the highest-value applications. For example, before a scheduled consultation, the practitioner submits the patron's topic and assignment description to a configured Claude Project. The system identifies the most relevant databases from the library's subscribed list and generates preliminary search terms organized by concept. It notes any relevant subject guides and drafts three clarifying questions to ask at the start of the session. This workflow compresses fifteen minutes of preparation into approximately three. It also produces a more systematic starting point than preparation done under time pressure without AI assistance.

Collection development scanning is a second practical application. To review a vendor's new title list against the library's collection criteria, the practitioner uploads the list to a configured project with the collection development policy and, if available, a current holdings list. The system flags titles that meet specified criteria, notes any that appear to duplicate existing holdings, and produces a prioritized recommendation list for the practitioner's review. This does not replace the practitioner's selection judgment. It does the initial filtering that would otherwise mean checking each title manually against multiple criteria.

Assessment work is a third practical application with a significant time return. For example, a practitioner with raw data from a patron satisfaction survey can submit the responses to an agent. They can request a summary of the three most significant trends, a two-paragraph narrative for the annual report, and a list of areas that warrant follow-up. The summary does not replace the practitioner's interpretation of what the findings mean for the library's services. It compresses the initial synthesis from hours to minutes, freeing the practitioner's time for interpretive work that requires professional judgment. Instruction session follow-up drafts, collection use reports, and grant narrative sections describing library programs are similar. In each case, agentic AI can produce a competent draft from structured input, which the practitioner reviews, corrects, and approves before use.

Everything in this module so far concerns what agentic AI can do. The governance question is different and more urgent: what an agent is permitted to do, on which systems, with which data, and without whose approval. The Association of Research Libraries and the Coalition for Networked Information addressed this directly in their March 2026 workshop report, Strategic Implications of AI Futures for Research Libraries. The report names agentic AI arriving in library systems without the authorization frameworks to govern it as one of the clearest unfinished tasks in current practice. It adds a strategy specifically for it. Libraries should develop governance frameworks for agentic AI that define authorization, auditability, and containment before agents begin taking actions across library systems.

What makes this urgent is the distinction this module opened with. A chatbot produces text that a practitioner reads before deciding what to do with it, so the human sits between the output and any consequence. An agent acts. When an agent updates a record, sends a message, or writes to a system, the consequence arrives before the review rather than after it. Because agentic systems execute steps quickly, an error spreads through several later steps before a person notices. For example, suppose an agent with access to an integrated library system is correcting a batch of malformed records. It will not pause at the first record it misreads; it will apply the same misreading to every record matching that pattern. This failure is not a hallucination in the sense described in Module 01. It is correct execution of an incorrect instruction, at scale, which makes it a governance problem rather than a technical one.

Authorization is the first of the three requirements and the most concrete. To authorize an agent, the library must state explicitly which systems the agent may reach, which of those it may only read, and which it may write to. It must also state which actions require human approval regardless of the agent's apparent confidence. For example, an agent supporting acquisitions may read the catalog and the vendor's title list and may write to a draft recommendation document. It may not place an order, modify a bibliographic record, or send correspondence to a vendor. Writing such a statement takes an afternoon, and it forecloses a class of incident that takes months to remediate. The authorization should also name the data categories the agent may not receive at all. For library work, these are the prohibited patron data categories established in Module 04.

Auditability is the second requirement and the one most often omitted. An agent that takes actions must leave a record of what it did, in what order, and based on what input. That record must be legible to a practitioner who was not present when the actions occurred. To be useful, the log must be reviewed on a schedule, not only after something has gone wrong. The library should also be able to answer a plain question about any agentic output it has published or acted on: which steps did the system take, and which did a person take? A library that cannot answer that about its own workflows cannot make honest representations to its patrons, its administration, or its accreditors about how the work was produced.

Containment is the third requirement, and it is the practical expression of the first two. Containment means the agent operates inside a boundary its errors cannot escape. Those errors cannot reach production systems, patron records, or public-facing services without crossing a human approval point. For example, an agent working on metadata remediation should write its proposed changes to a staging file rather than directly to the catalog, and a practitioner approves the batch before it is loaded. This arrangement costs one review step and preserves the ability to reverse a bad run. An agent writing directly into production offers no such option.

The profession has begun this work, so a practitioner does not have to start from a blank page. Leo S. Lo's PASTAS checklist, published in portal: Libraries and the Academy in 2026, sets out six components for designing and governing an AI agent: Purpose and Audience, Authority, Structure and Style, Tools and Access, Accountability and Safeguards, and Signals and Review. Two of the six are the governance components proper, and they map onto the requirements just described. Tools and Access determines what systems and data the agent may reach, which is authorization in the checklist's own vocabulary. Accountability and Safeguards establishes ethical guidelines, oversight, and fail-safes, which covers auditability and containment together. Lo's explanation of why a checklist is needed at all is the sharpest statement of the problem available. Prompting assumes you are in the conversation, while an agent acts on conditions you set once and then keeps acting. The work therefore moves from writing a good prompt to engineering good context. For example, a library configuring an agent to triage interlibrary loan requests works through Purpose and Audience before writing a single instruction. That answer determines what Tools and Access the agent should get, and both answers determine what its Signals and Review schedule must catch. The checklist does not decide the hard questions, and it does not replace the local judgment described above. It does ensure the questions are asked in an order that surfaces the constraints before configuration rather than after.

None of this requires the library to be running sophisticated agentic systems today. The ARL and CNI field scan found little of this governance work in practice. It observed that frameworks are arriving after the tools rather than before them, the reverse of the order that would serve libraries well. A practitioner who writes down what an agent may access, what it must log, and where its output must stop before reaching production has done the substantive part of this work. They have done it before an incident forces the question. The judgment about where the human approval point belongs cannot be delegated to the system whose actions it is meant to constrain.