What are AI agents?

A chatbot and an agent may use the same underlying language model. They may even share the same chat interface. The important difference is not how they look. It is what the system can do after receiving a request.

A useful working distinction is that a chatbot is usually given a prompt and a defined body of context. It produces a response from that material. An agent can take actions to obtain material it does not yet have. It can search a repository, open a document, run text extraction, inspect an exhibit, compare clauses, store an intermediate conclusion and decide what to do next. That sequence is the agent’s loop.

This distinction matters in credit work because the relevant answer rarely sits in one clean passage. A restricted payments analysis may require the original agreement, several amendments, definitions incorporated by reference and evidence about which baskets were used. Reaching the right material is part of the task, not merely preparation for it.

What does a chatbot actually do?

At its simplest, a chatbot maps supplied context to a response. The context may include a user question, prior messages, system instructions and attached files. The model interprets those inputs and generates the next piece of text.

That can be valuable. If a lawyer supplies the relevant covenant, defined terms and transaction facts, a chatbot can summarise the provision, identify conditions or help organise an issue list. Those boundaries may be only partly visible: the user can inspect the conversation but may not see hidden instructions, tool definitions, retrieved material, preprocessing or silent truncation.

The limitation is equally clear. If the relevant amendment was not supplied, the chatbot cannot reliably account for it. If an exhibit is referenced but missing, the model does not gain access merely because the exhibit would be useful. It may state the limitation, infer around it or, in a poorly controlled system, answer as though the record were complete.

A chat interface does not itself make a system a chatbot or an agent. An agent can operate behind a chat window, while a chatbot can be embedded in a document-management product. The distinction lies in execution.

What makes a system an agent?

An agent combines a model with four operational capabilities:

The model remains important. It interprets the request, selects actions and synthesises results. But the model is only one component of the working system.

Consider a request to identify debt-incurrence capacity under a credit agreement. A document agent might first locate the operative agreement, search for the indebtedness covenant, retrieve definitions used in that covenant, inspect amendments affecting those definitions, extract basket conditions and assemble a sourced analysis. If a cross-reference points to another section, the agent can follow it. If the search result looks incomplete, it can try a different query.

A chatbot would normally need the relevant material handed to it. An agent is expected to go and get it.

How does the agent loop work?

The loop can be expressed as a repeated set of decisions:

1. Interpret the objective.
2. Determine what information is needed.
3. Select and call a tool.
4. inspect the result.
5. Update working state.
6. Decide whether to act again, answer or report a blocker.

For a simple question, the loop may be short. For a document-intensive question, it may branch. Finding a covenant can expose defined terms; those definitions can contain further cross-references; an amendment can replace one clause while leaving another intact.

The agent therefore needs more than a general instruction to “analyse the documents.” It needs rules for document selection, source precedence, cross-reference resolution and evidence retention. It also needs a way to distinguish three materially different states:

• The language is absent from the governing documents.
• The language has not yet been found.
• The system could not access enough material to determine whether it exists.

Collapsing those states produces confident but unsound conclusions. “No applicable limitation” is not equivalent to “the search returned no passage,” especially where the corpus may be incomplete.

What do tools add?

Tools turn generated text into a process that can interact with an environment. A tool might search filenames, retrieve a filing, run optical character recognition, extract pages from a PDF, query a clause index or calculate amounts from structured inputs.

A model does not directly perform those operations merely by describing them. The surrounding software exposes a defined tool, supplies parameters and returns a result. The agent then reasons over that result.

Tool use creates reach. A professional does not have to identify and paste every potentially relevant provision before asking a question. The system can move through a document set and collect the evidence required for an answer.

But access is not the same as successful retrieval. A search tool may index only part of a document. A PDF parser may omit a schedule. An optical-character-recognition step may distort defined terms. A repository query may return an outdated draft alongside the executed instrument. The agent may receive a technically valid response that is substantively inadequate.

The system must therefore preserve provenance: which tool was called, which document was returned, which version was used and which passage supports each conclusion.

Why does state matter?

Multi-step work requires memory more structured than a transcript. The agent needs to retain what it has established and what remains unresolved.

Useful state for a credit-document task might include:

• the identified governing instrument and its date;
• amendments located and their apparent effect;
• defined terms already resolved;
• sections searched without a conclusive result;
• extracted conditions and exceptions;
• citations or page references attached to each finding;
• assumptions requiring human confirmation.

Without that state, the loop can repeat searches, contradict earlier findings or lose the connection between a conclusion and its source. A long conversation history is not necessarily sufficient. Important evidence can be displaced as more material enters the model’s context, and raw transcripts do not enforce a consistent structure.

State also supports review. A senior analyst should be able to see not just the final prose but the path that produced it: documents considered, exclusions made and questions left open.

Why is the harness usually the first place to look when an agent underperforms?

The harness is the operating system around the model. It defines available tools, document access, prompt instructions, state representation, iteration limits, validation rules, error handling and stopping conditions.

Reliability depends jointly on model capability, tools, instructions, data, task design and the harness. When an agent underperforms, however, the harness is usually the first place worth inspecting and often the cheapest component to change.

That architecture determines what the model is able to observe and do. If the harness passes only the first portion of a search result, the model cannot reason over omitted passages. If document identifiers are ambiguous, it may analyse the wrong instrument. If state does not record amendment priority, a later step may revert to superseded language.

Common failures occur at different layers:

Calling all of these “model errors” obscures the engineering problem. A stronger model may sometimes compensate for weak inputs or vague instructions, but it cannot inspect text the tool never returned. Nor can it reliably obey source precedence that the harness failed to represent.

How do agents fail differently from chatbots?

A chatbot’s central risk is often visible context insufficiency: the required material was not provided. An agent can conceal that insufficiency because it appears capable of finding the material itself.

This creates additional failure modes. The tool may not reach a password-protected data room. A result may be truncated before the operative exception. The agent may treat a keyword search as exhaustive. It may accumulate inconsistent notes across steps. It may stop after finding a plausible clause without testing whether an amendment changed it.

The output can still read coherently. Fluency does not disclose whether the retrieval path was complete.

Good agent design therefore makes uncertainty operational. Failed access should generate a recorded blocker. Truncation should trigger another retrieval method. Negative findings should require defined search coverage. Material conclusions should remain tied to source passages. Completion should depend on task-specific checks, not on the model’s general sense that the answer looks finished.

When is an agent preferable?

An agent is useful when the work requires navigation rather than a single response. Examples include tracing cross-references across a long agreement, comparing provisions across a document set, identifying the operative language after amendments or building a covenant analysis with supporting sources.

A chatbot may be preferable when the user has already isolated the relevant text and wants a focused explanation, rewrite or challenge to an interpretation. The narrower setup can be easier to inspect and control.

The choice is not between an old and a new interface. It is between two execution models. An agent accepts responsibility for gathering and organising part of the record. That can remove substantial manual work, but only if its harness makes document access, state, evidence and stopping behaviour dependable.

For professional credit analysis, the decisive question is not whether a product calls itself an agent. Ask what it can retrieve, what state it preserves, how it handles incomplete access and what must be true before it declares the work complete.