LendingTree 如何在 Amazon Bedrock 上构建多 Agent 抵押贷款助手

购房是大多数人一生中最重大的财务决策之一，LendingTree 在 Amazon Bedrock 上构建了一款多 Agent 抵押贷款助手，让这一过程更加直接明了。该助手能够教育借款人、理解其个人情况，并通过自然对话提供量身定制的选择。借款人需要在购房或再融资、传统贷款或政府支持贷款、15 年期或 30 年期、固定利率或浮动利率之间权衡。此外，还有“折扣点”“贷款发起费用”和“债务收入比”等术语。难怪许多人在真正开始之前就已经感到无所适从。

25 年多来，LendingTree 一直帮助消费者梳理这些选择，连接数百万用户与贷款机构，寻找具有竞争力的抵押贷款报价。该公司建立在这样一种信念之上：每个人都应拥有做出自信财务决策所需的工具和知识。这款 AI 驱动的抵押贷款助手正是这一理念的下一步。

该解决方案必须达到 LendingTree 自成立以来始终坚持的标准：准确的信息、透明的指引，以及对用户数据的严格保护。在抵押贷款行业的监管要求下，内容过滤、个人身份信息（PII）保护和合规监督不是可选功能，而是不可妥协的要求。这使 Amazon Bedrock 及其内置护栏成为合适的基础。

“我们的目标是成为用户购房过程中的可信伙伴：既能教育消费者、理解他们的情况，也能为他们匹配合适的报价。Amazon Bedrock 中的基础模型和内置护栏，让我们从一开始就能在安全与合规的前提下实现这一目标。”

— LendingTree 技术高级副总裁 Srinivas Madabushi

行业中许多公司已经添加了用于回答基础问题的聊天机器人。LendingTree 希望更进一步，既回答复杂问题，也为借款人匹配有竞争力的报价。为此，仅靠一个 Agent 并不够。

解决方案概览

为应对这些挑战，LendingTree 部署了三个独立的 AI Agent：一个 Supervisor 和两个专业 Worker（教育与匹配）。这些 Agent 通过 LangGraph、Model Context Protocol（MCP）以及由 Amazon Bedrock 提供支持的基础模型进行协同。所有 Agent 都以容器化服务形式运行在 Amazon Elastic Container Service（Amazon ECS） 和 AWS Fargate 上。

LendingTree 选择 Amazon Bedrock，是因为其具备多模型灵活性以及可继承的 AWS 治理控制能力，而后者是其合规团队的要求。该解决方案部署在 Amazon ECS 上，而不是 Amazon Bedrock AgentCore，原因是 AgentCore 正式全面可用时，该方案已经投入生产。AgentCore 是一个可使用任意框架或模型，大规模构建、连接和优化 Agent 的平台。

下图展示了高层架构。

LendingTree 用于抵押贷款咨询的多 Agent 架构

(1) 面向消费者的聊天界面是一个 React 应用，以容器化服务形式运行在 Amazon ECS with Fargate 上，并通过公共端点面向 Web 和移动浏览器中的消费者提供服务。

(2) 用户输入和模型输出都会经过 Amazon Bedrock Guardrails 处理，以进行内容过滤（如仇恨言论和粗俗语言检测）及 PII 脱敏。传入消息还会接受提示词威胁筛查。

在 Guardrails 之外，另有一个基于大语言模型（LLM）的安全分类器负责执行 LendingTree 的对话策略。这两项安全检查并行运行，因此额外的保障不会增加延迟。

业务逻辑层负责处理 LendingTree 的运营规则，包括将复杂问题路由至人工支持，以及将偏离主题的对话重定向。

(3) Supervisor Agent 是编排器，基于 LangGraph 构建为一个遵循“规划并执行”模式的状态机。它的工作方式类似一支组织有序的团队：Supervisor 负责理解整体情况并决定下一步需要做什么，而各个 Worker 则处理自己最擅长的任务。

Supervisor 是由节点和边组成的图。节点执行工作（意图分析、执行规划、回复编排），边则根据结果决定下一步操作（路由至 Education、路由至 Matching 或直接回答）。这使流程显式化：系统中的每一条路径都是已定义、可审计且可追溯的。

Supervisor 使用 Amazon Nova Pro 分析用户意图并生成执行计划。随后，它通过 MCP 将请求路由到合适的 Worker，并使用连接池来实现低延迟调用。有关不同区域的模型可用性，请参阅 Amazon Bedrock 中按 AWS 区域列出的受支持模型。

并非每个任务都需要最强大的模型。Supervisor 实现了多模型架构，会根据任务需求自动在 Amazon Nova Pro（用于复杂推理和关键分类）与 Amazon Nova Lite（用于对话回复和轻量级分类）之间进行选择。这在可靠性与成本之间实现了平衡。

规划与执行在设计上相互分离。当一次对话出现问题时，团队可以准确追踪是哪个节点做出了哪项决策。

(4) Education Worker 是一位耐心的教育者。它帮助用户理解抵押贷款概念、解释产品差异，并通过交互式对话提供指导。它运行自身的 LangGraph 工作流，并维护针对其领域定制的专用 Amazon Bedrock Knowledge Bases。Knowledge Bases 是一项完全托管的检索增强生成（RAG）功能，由 Amazon OpenSearch Service 作为向量存储提供支持。每个回复都基于真实文档，而非仅依赖模型知识。

(5) Matching Worker 是连接者。它收集用户偏好，并调用 LendingTree 内部的报价、资格和利率 API。随后，它基于用户的实际情况提供个性化贷款选项，并解释资格标准，帮助用户并排比较不同方案。

(6) 共享服务通过运行在 Amazon Relational Database Service（Amazon RDS） 上的 LangGraph PostgreSQL checkpointer 处理对话记忆和会话状态。这使对话能够跨轮次、跨 Agent 交接以及跨服务重启持续保存。用户可以暂停，稍后回来，或提出后续问题，而不会丢失上下文。

(7) Amazon Bedrock 提供广泛的基础模型，适用于多种用例。这些模型覆盖从复杂推理和关键分类（Amazon Nova Pro），到高成本效益的对话回复和轻量级分类（Amazon Nova Lite），并且都可通过单一 API 访问。内置 Guardrails 提供可配置的安全控制，而 Amazon Bedrock Knowledge Bases 则通过 Amazon OpenSearch Service 等向量存储，利用混合检索将 Agent 连接到权威内容。

(8) LendingTree 内部服务和 API 提供贷款机构搜索、利率和产品数据、资格与预资格审查、报价比较以及用户资料信息。

(9) 所有服务都运行在 Amazon ECS with AWS Fargate 上，每个 Agent 可根据自身的需求信号独立扩缩容。基础设施通过 Terraform 管理，并通过 GitLab 持续集成和持续交付（CI/CD）流水线部署，其中包含自动化测试和健康检查。

端到端跟踪一次对话

假设一名用户问：“FHA 和传统贷款有什么区别，哪一种更适合我？”

该消息首先通过 Amazon Bedrock Guardrails (2) 接受安全筛查。接着，Supervisor Agent (3) 从对话记忆 (6) 中加载历史记录并分析意图，识别出两项需求：解释说明和个性化比较。它通过 MCP 将教育类问题路由给 Education Worker (4)，并将匹配类问题路由给 Matching Worker (5)。每个 Worker 独立运行并返回结果。Supervisor 将二者汇总为一条连贯回复，再次通过 Guardrails 审查输出后交付给用户。完整的交互会被检查点保存至 PostgreSQL (6)，因此下一轮对话可以在完整上下文基础上继续。

对用户而言，这是一段连续的对话。而在幕后，这是一套协同工作流，其中的每个决策点都可追溯。

部署与运营

由于 Agent 通过 MCP 通信，因此每个 Agent 都可以独立更新、扩缩容和回滚。Education Worker 可以发布新的知识库，而无需改动 Supervisor 或 Matching Worker。在运营层面，多 Agent 系统特有的挑战是追踪一段跨越多个服务的单次对话。Amazon CloudWatch 日志和 AWS X-Ray 分布式追踪使团队能够跟踪单次对话穿越全部三个 Agent 的过程，并获得按 Agent 划分的指标和详细耗时数据。

成果

自 2025 年末以来，该助手一直在生产环境中处理真实的抵押贷款对话。本节指标基于 LendingTree 工程团队报告的内部生产分析数据，统计范围为上线至 2026 年第一季度。在此期间，该助手服务了约 1,960 场对话和 12,100 条消息，平均每次交互为 6.2 条消息。这些并非一次性的查询：深度参与用户会持续进行平均超过 10 条消息、时长 9 分钟的多轮会话，提出后续问题、细化自身情况，并通过对话探索各种选择。

从教育到行动。 对话数据揭示了消费者实际如何使用 AI 抵押贷款助手。在推广初期，75% 的对话属于教育类。用户会问：“什么是 FHA 贷款？”“HELOC 如何运作？”或“申请传统贷款需要什么信用评分？”随着系统日趋成熟并逐渐传播开来，交易意图不断增长：如今，超过 50% 的近期对话涉及利率比较、贷款机构匹配或预资格审查，这些行动都与转化直接相关。

对话深度表明信任。 平均 6.2 条消息的会话长度说明了一种情况；而深度参与用户平均超过 10 条消息、持续 9 分钟，则说明了另一种情况。用户不会与自己认为没有价值的系统保持如此程度的互动。Education Worker 帮助用户建立理解，而当用户准备采取行动时，会自然转向 Matching Worker。没有强制交接，也没有“重新开始”的时刻。

问题揭示了真实复杂性。 最常见的话题包括贷款类型比较（FHA、传统贷款和 VA 贷款）、特定信用状况下的资格标准、利率谈判策略、成交时间表以及首付取舍。这些正是静态 FAQ 页面难以有效回答的、依赖具体情境的问题。它们需要上下文：用户在三轮对话前说了什么、他们符合什么资格条件、他们正在优化什么目标。这正是对话记忆和 Supervisor 意图分析体现其复杂性价值的地方；系统能够保持对话主线，使每一个答案都建立在前一个答案之上。

自助闭环率。 超过 97% 的对话从头到尾都无需升级至人工处理，只有约 3% 的用户明确要求真人客服。对于问题本身确实复杂、答错会带来实际后果的受监管金融产品而言，这一自助闭环率意义重大。它证明该系统能够作为一个自包含的咨询服务运行，而不只是呼叫中心前的分流层。

数据所证实的内容。 互动深度是最重要的信号。信息更充分的用户能够做出更好的决策。对话界面能够揭示静态表单无法组合捕捉的偏好和约束。例如，“我是退伍军人，信用评分为 650，计划在未来 30 天内于科罗拉多斯普林斯购房”这样的细节，能让后续的贷款机构匹配更具相关性。这最终才是真正服务消费者的方式。

LendingTree 的经验，以及下一步计划

将多 Agent 系统投入生产，让团队在架构层面的收获不亚于任何单一功能带来的收获。

在推出抵押贷款助手后，LendingTree 意识到，构建一个 Agent 相对直接，但扩展到多个 Agent 则需要共享的基础能力。LendingTree 没有将每项新功能都构建成一次性项目，而是正在投资于可复用组件。其中包括用于数据访问的共享上下文层、用于工具集成的 MCP 合约，以及标准化部署流程。一个注册表让团队能够发现现有能力，而不必重复造轮子。这使团队可以构建更小、以领域为中心的能力，再将其组合为更广泛的消费者体验。安全性、可观测性、评估和复用方面的一致标准将这些能力整合在一起。

Agent 设计经验：

• Knowledge Bases 的语义分块。 与固定大小的分块相比，将文档拆分为语义连贯的片段，显著提升了检索质量，因为片段边界与自然主题分界相一致。
• Knowledge Base 冲突解决。 在使用多个 KB 时，有时会出现相互矛盾的信息。基于领域的过滤和来源优先级解决了这一问题：对于产品相关问题，LendingTree 内部内容优先；外部资源则用于通用抵押贷款教育。
• Agent 间上下文传递。 Worker Agent 最初缺乏对更广泛对话的感知

Buying a home is one of the biggest financial decisions most people face, and LendingTree built a multi-agent mortgage assistant on Amazon Bedrock to make the process more straightforward. The assistant educates borrowers, understands their situation, and provides tailored options in a natural conversation. Borrowers must weigh purchase or refinance, conventional or government-backed, 15-year or 30-year terms, and fixed or adjustable rates. On top of that, there’s jargon like “discount points,” “origination fees,” and “debt-to-income ratio.” It’s no wonder many people feel lost before they even start.

LendingTree has been helping consumers sort through these choices for over 25 years, connecting millions of people with lenders to find competitive mortgage offers. The company was built on a belief that everyone deserves the tools and knowledge to make confident financial decisions. The AI-powered mortgage assistant is that next step.

The solution had to meet the same standards that have guided LendingTree from day one: accurate information, transparent guidance, and rigorous protection of user data. Operating within the regulatory requirements of the mortgage industry means content filtering, personally identifiable information (PII) protection, and compliance oversight aren’t optional features. They’re non-negotiable. That made Amazon Bedrock and its built-in guardrails the right foundation.

“Our goal was to be a trusted partner in the home-buying journey, a guide that educates consumers, understands their situation, and matches them with the right offer. The foundation models and built-in guardrails in Amazon Bedrock let us deliver that with security and compliance from the start.”

— Srinivas Madabushi, SVP Technology, LendingTree

Many companies in the industry have added chatbots for basic questions. LendingTree wanted to go further, answering the hard questions and matching borrowers with competitive offers. That took more than one agent.

Solution overview

To address these challenges, LendingTree deployed three independent AI agents: a supervisor and two specialized workers (education and matching), coordinated using LangGraph, the Model Context Protocol (MCP), and foundation models powered by Amazon Bedrock. All agents run containerized services on Amazon Elastic Container Service (Amazon ECS) with AWS Fargate.

LendingTree chose Amazon Bedrock for its multi-model flexibility and inherited AWS governance controls, which their compliance team required. The solution was deployed on Amazon ECS instead of Amazon Bedrock AgentCore because it was already in production when AgentCore reached general availability. AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model.

The following figure shows the high-level architecture.

LendingTree multi-agent architecture for mortgage guidance

(1) The consumer-facing chat interface is a React application running as a containerized service on Amazon ECS with Fargate, serving consumers on web and mobile browsers through a public endpoint.

(2) User inputs and model outputs pass through Amazon Bedrock Guardrails for content filtering (such as hate and profanity detection) and PII redaction. Incoming messages are also screened for prompt threats.

In parallel with Guardrails, a safety classifier based on a large language model (LLM) enforces LendingTree’s conversational policy. The two safety checks run concurrently, so this added assurance doesn’t add latency.

A business-logic layer handles LendingTree’s operational rules: routing complex issues to human support and redirecting off-topic conversations.

(3) The Supervisor agent is the orchestrator, built on LangGraph as a state machine that follows a plan-and-execute pattern. It works like a well-organized team: the Supervisor understands the big picture and decides what needs to happen, while the workers handle what they’re each best at.

The Supervisor is a graph of nodes and edges. Nodes do the work (intent analysis, execution planning, response composition), and edges decide what happens next based on the result (route to Education, route to Matching, or answer directly). This makes the flow explicit: every path through the system is defined, auditable, and traceable.

The Supervisor analyzes user intent with Amazon Nova Pro and produces an execution plan. It then routes to the appropriate worker over MCP using connection pooling for low-latency calls. For model availability by Region, see Supported models by AWS Region in Amazon Bedrock.

Not every task needs the most powerful model. The Supervisor implements multi-model architecture, automatically selecting between Amazon Nova Pro (for complex reasoning and critical classification) and Amazon Nova Lite (for conversational responses and lightweight classification) depending on what the task demands. This balances reliability with cost.

Planning and execution are separated by design. When a conversation goes wrong, the team can trace exactly which node made which decision.

(4) The Education worker is the patient educator. It helps users understand mortgage concepts, explains product differences, and provides guidance through interactive conversation. It runs its own LangGraph workflow and maintains specialized Amazon Bedrock Knowledge Bases, the fully managed retrieval augmented generation (RAG) capability, tailored to its domain, backed by Amazon OpenSearch Service as the vector store. Every response is grounded in real documents rather than relying on model knowledge alone.

(5) The Matching worker is the connector. It gathers user preferences and calls LendingTree’s internal offer, eligibility, and rate APIs. From there, it delivers personalized lending options based on the user’s actual situation. It interprets qualification criteria and helps users compare options side by side.

(6) Shared services handle conversation memory and session state through the LangGraph PostgreSQL checkpointer on Amazon Relational Database Service (Amazon RDS). This lets conversations persist across turns, agent handoffs, and service restarts. Users can pause, come back later, or ask follow-ups without losing context.

(7) Amazon Bedrock provides a broad set of foundation models suited to a wide range of use cases. These range from complex reasoning and critical classification (Amazon Nova Pro) to cost-efficient conversational responses and lightweight classification (Amazon Nova Lite), all accessible through a single API. Built-in Guardrails deliver configurable safety controls, while Amazon Bedrock Knowledge Bases connect agents to authoritative content through vector stores such as Amazon OpenSearch Service for hybrid retrieval.

(8) Internal LendingTree services and APIs provide lender search, rate and product data, eligibility and prequalification checks, offer comparison, and user profile information.

(9) All services run on Amazon ECS with AWS Fargate, where each agent scales independently on its own demand signals. Infrastructure is managed through Terraform and deployed through GitLab continuous integration and continuous delivery (CI/CD) pipelines with automated testing and health checks.

Following a conversation end to end

Suppose a user asks, “What’s the difference between FHA and conventional, and which one fits me?”

The message flows through Amazon Bedrock Guardrails (2) for safety screening. The Supervisor agent (3) then loads conversation history from conversation memory (6) and analyzes intent, recognizing two needs: an explanation and a personalized comparison. It routes the educational question to the Education worker (4) over MCP, and the matching question to the Matching worker (5). Each worker operates independently and returns its result. The Supervisor aggregates both into one coherent reply, running the output back through Guardrails before delivering it. The full exchange is checkpointed to PostgreSQL (6), so the next turn picks up with complete context.

To the user, it’s one continuous conversation. Behind the scenes, it’s a coordinated workflow where every decision point is traceable.

Deployment and operations

Because the agents communicate through MCP, each can be updated, scaled, and rolled back independently. The Education worker can ship a new knowledge base without touching the Supervisor or the Matching worker. Operationally, the challenge unique to multi-agent systems is tracing a single conversation that spans multiple services. Amazon CloudWatch logs and AWS X-Ray distributed tracing allow the team to follow a single conversation’s journey across all three agents, with per-agent metrics and detailed timing.

Results

The assistant has been handling real mortgage conversations in production since late 2025. The metrics in this section are based on LendingTree’s internal production analytics from launch through Q1 2026, as reported by the LendingTree engineering team. Across that period, it served roughly 1,960 conversations and 12,100 messages, averaging 6.2 messages per exchange. These aren’t one-shot lookups: engaged users sustain multi-turn sessions averaging 10+ messages over 9 minutes, asking follow-up questions, refining their situation, and exploring options conversationally.

From education to action. The conversation data reveals how consumers actually use an AI mortgage assistant. Early in the rollout, 75% of conversations were educational. Users asked questions like “What is an FHA loan?”, “How does a HELOC work?”, or “What credit score do I need for a conventional loan?” As the system matured and word spread, transactional intent grew: over 50% of recent conversations now involve rate comparisons, lender matching, or prequalification, actions tied directly to conversion.

Conversation depth signals trust. The average session length of 6.2 messages tells one story. The engaged-user average of 10+ messages over 9 minutes tells a different one. Users don’t sustain that kind of engagement with a system they don’t find useful. The Education worker builds understanding, and users naturally progress to the Matching worker when they’re ready to act. No forced handoff, no “start over” moment.

The questions reveal real complexity. The most common topics include loan type comparisons (FHA, conventional, and VA), qualification criteria for specific credit profiles, rate negotiation strategies, closing timelines, and down payment trade-offs. These are exactly the situation-dependent questions that static FAQ pages can’t answer well. They require context: what the user said three turns ago, what they qualify for, what they’re optimizing for. This is where conversation memory and the Supervisor’s intent analysis earn their complexity, and the system maintains the thread so each answer builds on the last.

Containment. Over 97% of conversations were handled end-to-end without human escalation, and only about 3% of users explicitly requested a live agent. For a regulated financial product where the questions are genuinely hard and getting it wrong has real consequences, that containment rate is significant. It demonstrates the system’s ability to operate as a self-contained advisory service rather than a triage layer in front of a call center.

What the data confirms. The engagement depth is the signal that matters most. Better-informed users make better decisions. A conversational interface surfaces preferences and constraints that a static form never captures in combination. Details like “I’m a veteran with a 650 credit score looking to buy in Colorado Springs in the next 30 days” make downstream lender matches more relevant. That’s ultimately what serves the consumer.

What LendingTree learned, and what’s next

Getting a multi-agent system to production taught the team as much about architecture as about any single feature.

After shipping the mortgage assistant, LendingTree realized that building one agent is straightforward, but scaling to many agents requires shared foundations. Rather than building every new feature as a one-off, LendingTree is investing in reusable pieces. These include shared context layers for data access, MCP contracts for tool integration, and standardized deployment processes. A registry lets teams discover existing capabilities instead of reinventing them. This lets teams build smaller, domain-focused capabilities that can be composed into broader consumer experiences. Consistent standards for safety, observability, evaluation, and reuse tie it all together.

Agent design learnings:

• Semantic chunking for Knowledge Bases. Breaking documents into semantically coherent chunks rather than fixed-size chunks improved retrieval quality significantly, because chunk boundaries align with natural topic breaks.
• Knowledge Base conflict resolution. With multiple KBs, contradictory information sometimes surfaced. Domain-based filtering and source prioritization solved this: internal LendingTree content takes precedence for product-specific questions, while external resources serve general mortgage education.
• Inter-agent context passing. Worker agents initially lacked awareness of the broader conversation. Passing full conversation history and intent summaries in each MCP request gave workers the context they need to provide relevant responses.
• Query rewriting. Short user responses like “not sure” or “yes” get rewritten into meaningful, searchable queries using conversation history before retrieval. This significantly improved retrieval quality.
• Guardrail tuning is ongoing work. Early configurations blocked legitimate questions because mortgage terminology tripped content filters. Tuning against realistic conversation data resolved this.
• Task-based model routing kept costs in check: Nova Pro only where reasoning demanded it, Nova Lite everywhere else.

These are agent design problems, not infrastructure problems. They remain important regardless of runtime choice, and represent the lasting knowledge from this implementation.

Infrastructure learnings:

• Conversation state management. Early versions lost context during agent handoffs. A unified PostgreSQL-backed checkpointer with explicit state serialization solved this, allowing conversations to persist across agent transitions and system restarts.
• Running safety checks in parallel preserved latency without weakening protection.
• Independent agent scaling required hand-wiring ECS containers, health checks, and deployment pipelines per agent.

The team is now evaluating re-architecting onto AgentCore to offload undifferentiated infrastructure work. That would avoid hand-wiring PostgreSQL checkpointers, ECS containers, and agent scaling, letting engineering effort shift from “keep the runtime alive” to “keep optimizing the agent logic and domain knowledge.”

Conclusion

LendingTree’s production multi-agent system demonstrates that AI agents can serve consumers in heavily regulated industries, not only as prototypes, but as production systems running 24/7. Amazon Bedrock (Nova Pro and Nova Lite, Knowledge Bases, and Guardrails) provided the model and safety foundation. LangGraph handled agent orchestration, and MCP handled agent-to-agent communication. Together, they deliver personalized mortgage guidance at scale while maintaining strict compliance standards.

For organizations building multi-agent systems: separate planning from execution so the system is debuggable. Make safety a structural pillar rather than a skippable step. Design from day one for the reusable capabilities that will let you scale the pattern across your organization.

To get started with multi-agent systems on AWS, explore the Amazon Bedrock documentation and Amazon Bedrock AgentCore for managed runtime capabilities.

---

About the authors

Eric Hanson

Eric is an AI Architect at LendingTree, where he leads the AI engineering team responsible for the multi-agent mortgage guidance system.

Ramesh Eega

Ramesh is a Global Accounts Solutions Architect at Amazon based out of Atlanta, GA. He is passionate about helping customers throughout their cloud journey. Outside of work, Ramesh enjoys traveling and hiking.

Bhanusree Vadlamudi

Bhanusree is a Technical Account Manager (TAM) at Amazon who is passionate about building trust-based relationships with customers, understanding their technical needs, and ensuring they realize the full value of AWS. Bhanu partners closely with FSI customers to provide technical guidance, architectural recommendations, and best practices that enable them to achieve their goals through AWS services. Bhanu enjoys spending time with family, going on hikes, and traveling.