In today's generative AI products, an AI agent is usually software in which a model chooses steps toward a goal, calls permitted tools, reads their results, and decides what to do next. It might search files, compare sources, draft a document, or ask a person to resolve an uncertainty. “Agent” has broader uses in AI research; this guide focuses on tool-using systems in professional work. The label does not promise that the system is independent, accurate, or authorized to act without review. For legal work, the useful question is what the agent can access and do before a lawyer checks it.
What makes software an AI agent?
The term has no single industry-wide threshold. A practical definition is that a model has some discretion over the next step: it can select a tool, inspect the result, and continue or stop within limits set by the system and the user. An agent can start because a person asks it to act, and it can pause for approval. It need not run unattended. Anthropic distinguishes agents from predefined workflows by whether the model dynamically directs the process and tool use. Its later account describes an agent as a model using tools in a loop.
The model does not itself possess a browser, inbox, or case-management system. The application supplies those capabilities through tools and permissions. A search tool may retrieve a file; a drafting tool may create a proposed document; an action tool might send a message or change a record. Each connection expands what the system can do and what must be secured. OpenAI's agent-building guide separates data tools from action tools for this reason.
A useful mental model has four parts. The model proposes the next step from the material it has been given. The tools carry out permitted operations and return results. The application keeps the task state, supplies instructions and retrieved material, and decides which tools are available. The human defines the assignment and approves consequential work. These are distinct responsibilities. An eloquent model response cannot grant access to a repository the application has not connected, and a tool's successful call does not establish that the model interpreted its result correctly.
The agent architecture guide examines these components and their handoffs in more detail.
An agent's apparent initiative is therefore bounded by its environment. A system with only search access can propose an email but cannot send one through that search tool. A system connected to an email action tool might be capable of sending it unless permissions or an approval gate prevent that step. Ask for the exact operations, accounts, and records a particular deployment can reach; the word “agent” alone answers none of those questions.
How is an agent different from an assistant or a fixed workflow?
The labels overlap. An AI assistant describes the experience of helping a user; an agent describes a way the software may plan and use tools. A conversational assistant can contain an agent, and an agent can work behind an interface that looks nothing like chat. The distinction is not whether the system waits for a prompt. It is how much discretion it has over the steps after the task begins.
A fixed workflow follows steps chosen in advance: search a named database, summarize the results, then place a draft in a review queue. An agent might decide which sources to search, whether another search is needed, and which draft sections require evidence. Either design may be useful. A fixed path is often easier to test when the task is predictable; model-directed steps may help when the path varies. Adding autonomy also adds possible mistakes, time, and cost. Anthropic recommends starting with the simplest design that meets the task.
For example, if every intake packet has the same five fields, a fixed extraction workflow may be easier to check than a model choosing its own route. If the documents vary and the next relevant source depends on what the first source says, model-directed searching may help. The question is not which design sounds more advanced. It is whether the extra discretion produces a measurable benefit on the specific assignment after errors, review time, and cost are counted.
How does an agent complete a task?
Consider a fictional research assignment: identify the current state-law standard for a narrowly defined contract issue and prepare a memo for lawyer review. A constrained agent could search an approved legal research service, open likely authorities, extract propositions with citations, compare dates and jurisdictions, and draft a memo. Its trace should show which sources it opened, what it quoted, what it could not verify, and why it stopped. The lawyer then checks the authorities, quotations, negative treatment, currentness, application to the facts, and final advice. This is an illustration of a possible workflow, not a tested performance claim.
The initial instruction matters. “Research enforceability” leaves the jurisdiction, contract type, date, facts, and desired output open. A bounded request would identify those facts, name the approved research source, require citations to the specific propositions they support, and direct the system to flag missing material rather than fill a gap with a guess. The agent might first find a governing statute, then examine cases interpreting a disputed phrase. If it encounters a case from another state or cannot access a cited opinion, that result should be labeled as a limitation rather than quietly incorporated as controlling law.
At the end, distinguish an answer from the record supporting it. A reviewable result identifies the opened source, its jurisdiction and date, the relevant passage, the proposition drawn from it, and any unresolved question. A tool trace can show which operations occurred, but it does not prove that every relevant authority was found or that the legal conclusion follows. It is also different from exposing a model's private reasoning. The lawyer needs enough source evidence to check the work directly.
Permissions determine whether the same system can only read, can save a draft, or can take an external action. A good boundary is specific: which matter, which repository, which operations, which recipients, and for how long. Those limits should be enforced by the connected software, not left to a written instruction alone. A request to “work on this matter” should not silently become permission to contact a client, alter a docket, or file a document. OpenAI's guidance on guardrails and human review calls for separate checks and human approval for higher-risk actions.
Current products demonstrate different parts of this pattern. For example, Anthropic describes Claude Code navigating a codebase with tools and retrieving files as needed; our agentic-lawyer prototype article shows a bounded legal demonstration and identifies what the video does not prove. Neither example establishes that an agent can independently practice law or that a given legal task will be completed correctly.
The boundary should also include a stopping condition. An agent should be able to return “the signed version is missing,” “the jurisdiction is unclear,” or “these authorities conflict” and hand the problem to a person. Allowing unlimited retries or more searches is not a substitute for resolving a factual ambiguity. Anthropic's agent design guide describes checkpoints and limits on iterations as ordinary parts of an agent design.
Does an agent learn from its conversations?
Three mechanisms are often called “memory,” but they are different. Conversation context is the information supplied to the model for a particular response: instructions, recent messages, retrieved documents, and tool results. It is finite, can be shortened or omitted, and does not by itself change the model's trained parameters. Stored memory is information an application saves and later retrieves—such as a preference, a matter note, or a file reference. It can influence a later response if the application includes it in context; it is not the same as retraining the model. Training or fine-tuning changes model parameters through a separate process. A claim that an agent “learns from every conversation” should say which mechanism is meant and what the product actually saves.
Anthropic's context-engineering explanation describes how agents select messages, instructions, and retrieved material for a limited context window. OpenAI's model-optimization guide distinguishes supplying context at inference time from fine-tuning. Long records create a further problem: relevant material may be missed even when it technically fits in the window. A saved note may also be stale or wrong. A lawyer should therefore check the underlying source, not assume that a remembered answer is an updated fact.
Imagine that a lawyer corrects an agent's clause summary. Within the current run, the correction can be included in the next model call. If the application saves it as a matter note, a later run may retrieve that note. If no note is saved or retrieved, the later run may never see the correction. None of these events alone updates the underlying model. A separate training process could use approved examples to change future model behavior, but that requires its own data selection, governance, and testing. Whether a provider may use submitted material for broader model improvement is a separate question governed by that product's settings and terms, not by whether the chat appears to remember.
Stored memory has its own scope and failure modes. A preference such as “use this team's citation format” is unlike a factual statement that “this contract was signed on May 3.” The latter must be tied to a source and version, and it may become false after an amendment. OpenAI's conversation-state documentation describes how applications preserve messages across calls while still working within a finite context window. A persistent conversation is not a complete or current matter file.
What are the limitations and failure modes?
Agents can produce a plausible but unsupported statement, misread a tool result, miss an adverse authority, choose the wrong jurisdiction, or carry an early mistake into later steps. A longer chain of reasoning and tool calls does not automatically make the final answer more accurate. Evidence and citations need direct verification. Different runs may take different paths, so an impressive demonstration is not a reliability measurement. OpenAI's evaluation guide recommends inspecting traces and testing repeatable datasets rather than judging only the final answer.
Tool access creates risks beyond ordinary text errors. A document or website can contain malicious instructions that try to redirect an agent; NIST calls this agent hijacking through indirect prompt injection. An agent may also expose confidential information through an inappropriate connector, act in the wrong account, or exceed an intended scope. Permissions, source boundaries, logs, and approval checks reduce risk, but none makes a system infallible.
Time and cost matter too. Several searches, model calls, retries, and human checks may take longer or cost more than a simpler workflow. Test against the actual work: source accuracy, missed issues, unauthorized actions, review time, and total cost. A system that saves drafting time but increases correction or security work may not help the practice.
Failure can be subtle. If a search returns three relevant opinions and the agent cites only two, the memo may look well supported while omitting the controlling exception. If it quotes the right case but applies it to a contract governed by a different state's law, the citation is real and the conclusion is still wrong. If it repeatedly consults an outdated summary rather than the underlying order, more tool calls can amplify the initial error. These are reasons to test source selection, completeness, and application to facts separately from writing quality.
The failure modes and response guide looks at how to detect, contain, and learn from these events in a running workflow.
What should a lawyer require before using an agent?
Start with a narrow task and a fictional or properly approved test matter. Identify the exact data the agent may read, the operations it may perform, and the action that requires a person. Preserve a record of sources, tool calls, and approvals. Test difficult and adversarial examples, including missing documents, conflicting authorities, and instructions embedded in untrusted material. Review the output against primary authority and the actual client facts before it becomes advice or a filing.
ABA Formal Opinion 512 discusses lawyers' duties of competence, confidentiality, supervision, candor, and reasonable fees when using generative AI. It calls for understanding a tool's benefits and risks and for reviewing legal analysis and citations before court submission. The opinion concerns the ABA Model Rules; applicable state rules, court orders, client terms, and the facts of a matter also govern. Our responsible AI guide provides a broader starting point.
Before choosing a product, a team can ask five plain questions: What task is authorized? Which exact sources and tools can the agent use? What event makes it stop or ask for help? What source record will a reviewer receive? Who approves the final communication, document change, or filing? A satisfactory answer should describe enforceable product behavior and an observable review process, not just a promise that the agent is careful. The evaluation guide turns these questions into a repeatable test.
The next question is: “For this defined task, what evidence shows that the system performs acceptably, what can it touch, and where is the human decision?” Explore the Agents section, then examine a legal workflow example and the permission and oversight controls.
Sources and update date
This guide was reviewed September 27, 2026. Definitions and product capabilities can change. The main technical references are Anthropic's agent design guide, context-engineering article, OpenAI's agent-building guide, conversation-state documentation, guardrails guidance, agent evaluation guidance, and NIST's agent-hijacking analysis. The legal-ethics reference is ABA Formal Opinion 512.
