How LendingTree built a multi-agent mortgage assistant on Amazon Bedrock

來源原標題

How LendingTree built a multi-agent mortgage assistant on Amazon Bedrock

作者

Eric Hanson

原始標籤

Amazon Bedrock · Customer Solutions · Intermediate (200)

原始連結

https://aws.amazon.com/blogs/machine-learning/how-lendingtree-built-a-multi-agent-mortgage-assistant-on-amazon-bedrock/

摘要原文

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. 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. 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.