Agents, Tool Use, and Autonomous Workflows

From Text Generation to Action

In the previous units, the Large Language ModelLarge Language Model (LLM)A neural network trained on vast amounts of text data that can understand and generate human language. LLMs power chatbots, document analysis, code generation, and many enterprise AI applications.See glossary was a reader and writer: it generated text from prompts, retrieved information through RAG, and searched documents using embeddings. Text in, text out. It did not do anything.

AI agentsAgentsAI systems that can autonomously plan and execute multi-step tasks by calling tools, querying data sources, and making decisions without human intervention at each step -- typically within defined permissions and human approval checkpoints.See glossary change this equation. An agent is an LLM that can take actions: pull data from systems, run calculations, trigger workflows, and make decisions across multi-step processes. Instead of just drafting a credit memo, an agent could pull the borrower's financial statements, retrieve their credit score from a bureau, check your credit policy for applicable underwriting standards, and then draft the memo -- in a single automated workflow.

This is no longer experimental: agents are in production at banks now, and flagship models are marketed specifically for agentic work. It is also the area that demands the most careful governance.

How Tool Use Works

The foundation of agent capability is tool use (sometimes called function calling). When an LLM is configured with tools, it can decide -- based on the user's request -- that it needs to call an external system. The process works like this:

1. Request: "What is our current credit exposure to Acme Corporation across all business lines?"
2. Analysis: The model determines it needs live data rather than its training knowledge
3. Tool selection: It picks the right tool -- here, a credit exposure API -- and fills in the parameters
4. Execution: The system calls the API and returns the data to the model
5. Response: The model uses the real data to produce an accurate, current answer

The model never executes the call itself -- the surrounding agent framework does. But the model decides which tools to call, with what parameters, and how to use the results.

Multi-Step Reasoning and Orchestration

Real banking workflows are rarely one-step processes. An agent chains tool calls together, adapting its plan as intermediate results come in. This is called multi-step reasoning. Consider an automated regulatory inquiry response:

1. The agent receives an examiner's question about a specific transaction
2. It retrieves the transaction records and the applicable compliance policies
3. It checks monitoring alerts and prior examination findings on similar transactions
4. It drafts a response memo citing specific policies, transaction details, and monitoring results

An orchestration frameworkOrchestration FrameworkSoftware that coordinates LLMs, tools, and data sources into complex workflows. Frameworks like LangGraph, CrewAI, and vendor toolkits such as the OpenAI Agents SDK and Microsoft Agent Framework manage prompt chains, memory, and tool calling for multi-step AI tasks.See glossary manages this loop. Independent frameworks such as LangGraph and CrewAI remain popular, and the major AI vendors now ship their own toolkits: the OpenAI Agents SDK, the Claude Agent SDK, Microsoft Agent Framework (1.0 in April 2026, successor to AutoGen and Semantic Kernel), and Google's Agent Development Kit (ADK). Choosing a vendor's toolkit is partly a lock-in decision -- treat it like any core platform choice.

Open Standards: MCP and A2A

Every tool an agent uses needs a connection to a bank system, and building each one by hand for each AI product does not scale. The industry has converged on an open standard: the Model Context Protocol (MCP)Model Context Protocol (MCP)An open standard for connecting AI models and agents to tools and data sources, so a connector built once works with any compatible model. Governed by the Linux Foundation's Agentic AI Foundation since December 2025. Each MCP connector is a new access path into bank systems and needs access and third-party risk review.See glossary, often described as "USB-C for AI." A connector written once -- say, for your document management system -- works with any MCP-capable model or agent. Since December 2025, MCP has been governed by the Linux Foundation's Agentic AI Foundation, whose members include AWS, Anthropic, Bloomberg, Google, Microsoft and OpenAI, so it is not tied to one vendor.

For banks, the governance point is simple: every MCP connector is a new access path into bank systems. Each one needs an owner, an access review, and a third-party risk assessment, like any new system interface.

A companion standard, Agent2Agent (A2A)Agent2Agent (A2A)An open standard that lets AI agents from different vendors communicate and hand work to each other. It reached version 1.0 in early 2026 and joined the Linux Foundation's Agentic AI Foundation in August 2026. It complements MCP, which connects agents to tools and data.See glossary, lets agents from different vendors talk to each other. It reached version 1.0 in early 2026, has more than 150 participating organizations, and joined the same foundation in August 2026.

Agents That Use Software Like a Person

Computer-use agentsComputer-Use AgentAn AI agent that operates software the way a person does -- reading the screen, clicking, and typing. Useful for legacy systems with no modern interface, but it needs the strictest guardrails because on-screen content can carry injected instructions.See glossary operate software the way a person does -- reading the screen, clicking, and typing. That makes them useful for legacy systems with no modern interface, and also the riskiest pattern: anything on screen, including text planted by an attacker, can influence what they do. They need the strictest guardrails.

Why Guardrails Are Non-Negotiable in Banking

The same autonomy that makes agents powerful makes them dangerous in a regulated environment. Without proper constraints, an agent with access to customer data, transaction systems, and communication channels could violate regulations, expose sensitive data, or make unauthorized decisions. GuardrailsGuardrailsSafety mechanisms that constrain AI model outputs, and the actions AI agents can take, to prevent harmful, off-topic, non-compliant, or unauthorized results. Critical in banking for regulatory adherence and brand safety.See glossary are the safety mechanisms that constrain what agents can and cannot do -- and in banking they are not optional.

Types of Guardrails

Input guardrails: Filter and validate user requests before the agent processes them. Block requests for unauthorized data and enforce access controls.

Prompt injection defenses: The top agent risk is prompt injectionPrompt InjectionAn attack in which instructions hidden in user input, or in content an AI reads (an email, document, or web page), try to override its rules. Ranked the top risk in the OWASP 2026 Top 10 for LLM applications. The main defenses are least-privilege permissions and human approval for sensitive actions.See glossary -- especially indirect injection, where instructions are hidden in an email, document, or web page the agent reads. It ranks #1 in OWASP's 2026 Top 10 for LLM applications, with "excessive agency" (agents allowed to do more than they should) at #3; OWASP added a separate Top 10 for Agentic Applications in December 2025. Assume an agent will eventually read hostile content, and limit what it can do when it does.

Identity guardrails: Give each agent its own least-privilege credentials, exactly as you would provision a new employee's entitlements -- never a shared or administrator account -- so every action is traceable to the agent and its human owner.

Output guardrails: Check agent responses for sensitive data, compliance, and accuracy before they reach users or external systems.

Action guardrails: Constrain which tools an agent can call and when -- for example, read transaction data but never modify it, or route any action above a dollar threshold for human approval.

Escalation protocols: Define when an agent must hand off to a human. High-value transactions, regulatory inquiries, and customer complaints above a certain severity should always involve human judgment.

Agent Architecture Patterns for Banking

Banking institutions typically adopt one of these agent deployment patterns:

Read-only agents: The agent can query systems and retrieve data but cannot modify anything. This is the safest starting point and covers many high-value use cases (research, analysis, Q&A).

Supervised agents: The agent can propose actions but requires human approval before execution. Useful for draft generation, recommendation systems, and workflow initiation.

Autonomous agents with constraints: The agent can execute actions within predefined boundaries (e.g., process transactions below a threshold, send pre-approved communication templates). Reserved for well-tested, low-risk workflows.

The Road Ahead

Agents are already reshaping banking operations, but rushing them into production without controls is as reckless as giving a new employee full system access on day one. The key is measured, governed adoption: start with read-only, advance to supervised, and earn your way to autonomous -- one proven use case at a time.