Casos de uso: Inteligência Artificial, agentes de IA
Setores: Serviços financeiros
Produtos MongoDB: MongoDB Atlas, MongoDB pesquisa vetorial, Change Streams, coleção de séries temporais do MongoDB, pipeline de agregação do MongoDB
Parceiros: Amazon Cama de Rock, LangChain
Visão Geral da Solução
Os sistemas de empréstimo tradicionais dependem de aplicativos legados desconectados que não foram criados para dados em tempo real, automação ou experiências do cliente digital-first. Os clientes agora esperam decisões instantâneas e total transparência, enquanto os credores gerenciam riscos crescentes, pressão regulatória e a crescente complexidade dos dados.
Esta solução mostra como criar um sistema de empréstimo digital moderno. Ele substitui um processo linear e com muita papelada por um fluxo de trabalho orientado a dados e em tempo real que conecta originação, subscrição, aprovação, financiamento e serviços em um único pipeline.
Por que usar o MongoDB?
Os fluxos de trabalho agentivos geram vários tipos distintos de estado: registros operacionais, embedding, métricas de atividade e a própria memória dos agentes. Sistemas separados para cada tipo adicionam infraestrutura e criam problemas de consistência entre eles. O MongoDB Atlas armazena tudo isso em uma plataforma de dados moderna com uma linguagem de query, o que reduz o trabalho de integração.
Flexibilidade de esquema e o document model
Uma solicitação de empréstimo acumula detalhes ao longo de seu ciclo de vida de mutuários, documentos, dados de crédito, métricas de risco e decisões. Ele permanece um documento que cresce, em vez de uma entidade espalhada por uma dúzia de tabelas que precisam ser unidas a cada leitura.
O detalhe polimórfico se encaixa naturalmente neste modelo. A renda de emprego e a renda de autônomo contêm campos diferentes dentro do mesmo array, sem colunas anuláveis e sem tabelas de subtipo.
Campos gerados pelo agente aparecem sem migração. Quando o agente de subscrição adiciona uma nova métrica, ele grava o campo diretamente sem alteração de esquema coordenada e sem ordem de implantação.
Atlas Vector Search para compreensão semântica
Os embeddings vivem nos documentos que eles descrevem. Uma query retorna uma correspondência semântica juntamente com seus dados de negócios, o que remover a necessidade de manter um banco de dados e um índice vetorial separado sincronização.
O pré-filtro limita uma pesquisa a um único aplicativo. Isso evita que os documentos de um mutuário apareçam nos resultados de outro, transformando um requisito de controle de acesso em um parâmetro de pesquisa em vez de lógica de aplicativo.
Pipeline de agregação para pontuação explicável
A pontuação de risco é executada onde os dados estão. Um pipeline une registros de crédito e renda, deriva as proporções e retorna uma pontuação limitada, sem transferência de dados para o código do aplicativo.
Como o cálculo é declarativo, a solução expõe cada estágio à interface. A explicabilidade torna-se parte da implementação, e não um esforço de relatório separado.
Change Streams para interfaces em tempo real
A fila do oficial, o rastreador de status do mutuário e o log de atividades leem eventos de alteração do banco de dados. Nenhum agente de mensagens separado fica entre uma gravação confirmada e a interface que a exibe.
Os fluxos são retomados de uma posição armazenada após uma falha de conexão, de modo que uma falha de rede transitória não cria uma lacuna no feed de auditoria.
LangGraph Checkpointer do MongoDB para memória do agente
- O estado do workflow persiste no Atlas a cada etapa. Um aplicativo pausado para revisar humana sobrevive a reinícios e reimplementações e é retomado com o contexto completo.
Juntas, essas funcionalidades permitem que uma única plataforma execute um fluxo de trabalho de empréstimo baseado em agente de ponta a ponta, desde a entrada de documentos, passando pela análise de crédito, revisar humana e monitoramento de portfólio, sem a superfície de integração que uma arquitetura de vários bancos de dados exige.
Arquiteturas de referência
A solução consiste no seguinte:
Frontend: A camada de experiência: Borrower Portal, Loan Officer Dashboard, Demo Flow e Renewal Dashboard.
Backend: Um serviço FastAPI que hospeda o pipeline do agente LangGraph e o expõe via REST, SSE e WebSocket.
MongoDB Atlas: A plataforma de dados inteligente para registros operacionais, vetores, métricas de série temporal, eventos de alteração em tempo real e memória do agente.
IA e observabilidade: Amazon Bedrock (Claude Haiku 4, uso de ferramentas para saída estruturada) e Voyage AI (embedding multimodal).
Figura 1. Arquitetura de alto nível: Empréstimos Agentic com MongoDB.
Agentes
O pipeline de agente LangGraph é composto pelo seguinte:
Figura 2. Fluxo Agêntico.
Supervisor: Inspeciona o estado do fluxo de trabalho após cada etapa e decide o que acontece a seguir: distribuir para coletar dados, prosseguir para a análise de risco, escalar para um humano ou concluir. Ele gerencia a política de repetição e a condição de pausa quando um aplicativo é bloqueado na entrada do mutuário.
Verificador de documentos: verifica a integridade em relação aos tipos de documentos necessários, sinaliza extrações com falha, detecta uploads duplicados por meio de hash do texto extraído e faz a verificação cruzada dos nomes dos candidatos em todos os documentos.
Extrator de crédito: Recupera registros do bureau para cada mutuário no aplicativo e anexa as pontuações ao estado do fluxo de trabalho.
Agente de aplicativo de empréstimo: Sintetiza os documentos coletados e os dados de crédito em uma narrativa de aplicativo coerente e avança o status do aplicativo.
Subscritor: Executa a agregação de riscos, calcula os rácios de acessibilidade e o teste de estresse, recupera a política reguladora por meio de pesquisa vetorial e produz uma recomendação estruturada: aprovar, recusar ou escalar.
Agente assistente de aplicativo: Opera fora do pipeline e responde às perguntas do mutuário usando o contexto do seu próprio arquivo e do corpus de políticas.
O supervisor despacha o verificador de documentos e o analista de crédito simultaneamente. A extração de documentos e a recuperação de crédito não têm dependência um do outro, portanto, sobrepô-los remove a maior espera sequencial no pipeline.
Figura 3. Pipeline de agente LangGraph.
Autonomia e supervisão humana (HITL)
O supervisor executa em um dos quatro modos de autonomia: observar, sugerir, limitado ou automático. O padrão, limitado, permite que o pipeline atue de forma autônoma dentro dos limites da política e escala para um funcionário quando um limite é ultrapassado — por exemplo, um preço de compra acima de $500K ou proporções GDS/TDS além dos limites da política. Cada decisão do oficial (aprovar, recusar ou modificar e continuar) contém o ID do oficial e grava em uma coleção de auditar imutável. O pipeline é retomado através do checkpointer do LangGraph, para que revisar humana não perca o estado do fluxo de trabalho.
Abordagem do modelo de dados
O fluxo de trabalho produz os seguintes tipos de dados, e o MongoDB Atlas armazena todos eles:
Registros operacionais estruturados: Cada registro evolui ao longo do ciclo de vida do empréstimo como um único documento em crescimento, em vez de uma linha fixa unida em várias tabelas.
Coleções: aplicativos, devedores, relatórios de crédito, histórico de bate-papo, oficiais, substituições.
{ _id: ObjectId('67500c01000000000000a002'), id: ObjectId('67500c01000000000000a002'), loansId: 'APP-2026-00011', borrowerIds: [ ObjectId('67500b01000000000000f002') ], borrowerNames: [ 'Grace Hopper' ], loanAmount: NumberInt('595000'), purchasePrice: NumberInt('850000'), downPayment: NumberInt('255000'), product: '7yr Fixed (30yr Amort)', property: { address: '226 W 108th St, New York City, NY 10025', type: 'Detached', purchasePrice: NumberInt('850000'), annualTax: NumberInt('11200') }, incomeSummary: { combinedGross: NumberInt('110400'), primary: NumberInt('110400'), coApplicant: null }, existingMonthlyDebt: NumberInt('0'), status: 'approved', statusHistory: [ { status: 'submitted', timestamp: ISODate('2026-03-05T14:32:11.000Z'), detail: 'Application received' }, { status: 'underReview', timestamp: ISODate('2026-03-07T10:00:00.000Z'), detail: 'Bureau pull complete; in underwriting' }, { status: 'conditionallyApproved', timestamp: ISODate('2026-03-12T15:30:00.000Z'), detail: 'Conditional approval pending appraisal' }, { status: 'approved', timestamp: ISODate('2026-03-20T11:15:00.000Z'), detail: 'Final approval issued' } ], createdAt: ISODate('2026-03-05T14:32:11.000Z'), updatedAt: ISODate('2026-03-20T11:15:00.000Z'), seedComplete: true }
Conteúdo não estruturado com vetores: O texto PDF extraído e seu embedding de 1024dimensões (voyage-multimodal-3.5) residem no mesmo documento, portanto, uma query retorna a correspondência semântica e seus dados de negócios juntos.
Coleção: documentos, políticas.
{ _id: ObjectId('69deb9600e702ecf5ed0b9c5'), application_id: 'APP-2026-00002', doc_type: 'government_id', filename: '01_government_id.pdf', extracted_text: 'This is a British Columbia Government Identification Card document package issued by ServiceBC Registry Services on March 1, 2024 (Document Reference: SA-2024-BC-00847). The package contains identification cards for two individuals: Jane Marie Doe (applicant), born March 14...', structured_data: { persons: [ { full_name: 'Jane Marie Doe', date_of_birth: '1992-03-14', gender: 'F', height: '5\'7"', address: null, id_number: 'BC-7241-5583-JMD', expiry_date: '2029-03-14' }, { full_name: 'John Robert Doe', date_of_birth: '1990-08-22', gender: 'M', height: '5\'10"', address: null, id_number: 'BC-8392-6147-JRD', expiry_date: '2029-08-22' } ], text_summary: 'This is a British Columbia Government Identification Card document package issued by ServiceBC Registry Services on March 1, 2024 (Document Reference: SA-2024-BC-00847). The package contains identification cards for two individuals: Jane Marie Doe (applicant), born March 14, 1992, female...', issuing_authority: 'ServiceBC -- Registry Services', issuing_address: 'Service BC, 4946 Canada Way, Burnaby, BC V5G 4J6', issue_date: '2024-03-01', document_reference: 'SA-2024-BC-00847', document_type: 'Government Identification Card', jurisdiction: 'British Columbia, Canada', note: 'SYNTHETIC DOCUMENT -- FOR DEMONSTRATION PURPOSES ONLY' }, embedding: [ Double('0.0546875'), Double('-0.00074005126953125'), Double('-0.03955078125'), Double('0.018798828125'), ...... ], embedding_type: 'multimodal', embedding_pages: NumberInt('1'), status: 'parsed', created_at: ISODate('2026-04-14T22:02:08.271Z') }
Memória do agente: estado do LangGraph por thread, para que um fluxo de trabalho pausado seja retomado exatamente de onde parou.
Collections: checkpoints, escritas de checkpoint e metadados de checkpoint .
{ _id: ObjectId('69deb00d938a6c352b22f83c'), thread_id: 'APP-2026-00002', idx: NumberInt('0'), checkpoint_id: '1f138480-5fd5-6ee2-bfff-20577a825d23', checkpoint_ns: '', task_path: '~__pregel_pull, __start__', task_id: 'd8f52fef-26db-0a3b-e30d-67652af78130', channel: 'messages', type: 'msgpack', value: BinData(0, 'kA==') }
Registros de coordenação e do auditar: Condições de bloqueio, decisões de oficiais e bloqueios distribuídos armazenados como documentos, com a mesma linguagem de query que o restante dos dados — nenhum sistema de auditar separado para manter.
Coleções: Intervenções, auditar de impacto, bloqueios de pipeline.
HITL_audit
{ _id: ObjectId('6a85cf398ec04b841ebc2a71'), application_id: 'APP-BA96654D', officer_id: 'officer-001', action: 'decline', notes: 'Declined after manual review', conditions: [], overrides: {}, timestamp: ISODate('2026-08-19T15:43:53.719Z') }
Intervenções: Armazena itens de ação digitados e gerados por agentes com contexto de risco interno e orientação segura para o mutuário. Itens de bloqueio pausam fluxos de trabalho até serem resolvidos e trigger a reavaliação.
{ _id: ObjectId('6a8c34e671e78aca4e8ca9ae'), application_id: 'APP-4E8CA981', type: 'stress_test_failure', status: 'pending', internal_context: { source_node: 'underwriter', risk_flag: 'osfi_b20_failure', severity: 'blocking', stress_gds: Double('0.6876'), stress_tds: Double('0.9604'), stress_rate: Double('0.0689'), gds_limit: Double('0.39'), tds_limit: Double('0.44'), is_insured: false }, borrower_context: { summary: 'Your application did not pass the OSFI B-20 mortgage stress test at the qualifying rate of 6.89%.', action_required: 'The stress test ensures you can afford payments if rates rise. You may improve your result by increasing your down payment, reducing existing debts, or choosing a less expensive property.', document_types_accepted: [] }, resolution: null, created_at: ISODate('2026-08-24T12:11:18.585Z'), resolved_at: null }
Mantê-los juntos é o que torna a solução gerenciável. Uma pilha convencional coloca os registros operacionais em um banco de dados relacional, os vetores em um armazenar de vetor dedicado, as métricas em um banco de dados de série temporal e o estado do agente em um cache — e então gasta a maior parte de seu esforço de engenharia mantendo quatro sistemas consistentes.
Construir a solução
Esta seção mostra como implementar a solução de crédito agente. Para obter o guia de implementação completo, clone o repositório e siga as instruções de configuração no GitHub README.
Para construir esta solução, siga estas etapas:
Provisione a plataforma de dados.
Crie um cluster Atlas e as coleções listadas em S3.
Criar um índice de pesquisa vetorial sobre os embedding de políticas e documentos, e adicione índices TTL para a coleção de bloqueio do pipeline.
Configure as coleções de pagamentos e atividades do agente como séries temporais.
Criar o pipeline do agente no LangGraph.
Implementar o supervisor e sua lógica de roteamento, os nós paralelos de verificação de documentos e de extração de crédito, a agregação de risco em sete etapas do subscritor e o gate de interrupção/retomada HITL com suporte de checkpoints do MongoDBSaver.
Checkpoint também funcionam como um registro forense. Você pode reconstruir o que os agentes sabiam no momento de uma decisão, um artefato diferente de um log do que eles disseram.
Como um aplicativo de hipoteca é um processo de longa duração, de vários dias, com etapas com intervenção humana (revisar do subscritor, reenvio de documentos, aprovação condicional). O MongoDBSaver persiste todo o estado do grafo após cada execução. Isso significa que um aplicativo pode ficar pausado por 3 dias esperando o contracheque de um mutuário e, quando ele for retomado, o grafo continua exatamente de onde parou com o estado completo intacto.
Uma configurar de exemplo:
from langgraph.checkpoint.mongodb import MongoDBSaver from langgraph.graph import StateGraph from pymongo import MongoClient client = MongoClient(ATLAS_URI) checkpointer = MongoDBSaver(client, db_name="lendflow") graph = StateGraph(MortgageState) # ... add_node(intake), add_node(document_verification), # add_node(underwriting), add_node(human_review) ... app = graph.compile(checkpointer=checkpointer) Se o grafo atingir uma interrupção() no nó de revisar humana, a invocação retorna com o estado pausado. O FastAPI pode retornar 202 ao cliente imediatamente. Quando o subscritor aprova por meio de um ponto de extremidade separado dias depois, basta invocar novamente com a mesma configuração e nova entrada, e o LangGraph retoma do último checkpoint, não do zero.
Observação
Esta implementação de demonstração inclui uma configuração de hipoteca canadense, incluindo um teste de estresse no estilo OSFI B-20 e taxas de acessibilidade GDS/TDS. As regras residem em uma função e uma coleção, assim, você reconfigura a solução para um mercado diferente alterando o documento MongoDB subjacente de configuração como dados em vez de reescrever o código.
Principais Aprendizados
Unifique o estado do agente com uma única plataforma, MongoDB Atlas: Os fluxos de trabalho de agente produzem registros operacionais, embedding e memória com checkpoint. Armazenar todos os quatro no Atlas remove o trabalho de integração e consistência de uma pilha de quatro bancos de dados.
Modele o empréstimo como um documento em evolução com o Flexible Document Model: O document model permite que os dados do mutuário, de crédito e de risco se acumulem em um único registro ao longo de todo o ciclo de vida, para que novos campos escritos pelo agente e tipos de renda polimórficos não precisem de migração de esquema.
Query vetores ao lado dos dados que eles descrevem com o Atlas Vector Search: O MongoDB armazena cada embedding como um campo no documento que ele descreve, e o Atlas Vector Search faz query lá. Uma query retorna a correspondência semântica e seus dados de negócio juntos, e limitar a pesquisa a um único aplicativo mantém os documentos de um mutuário fora dos resultados de outro.
Tornar a pontuação de risco explicável e configurável por design com o Framework de Agregação: Executar o cálculo de risco como um pipeline de agregação declarativa expõe cada etapa da pontuação, portanto, a explicabilidade vem da implementação em vez de uma camada de relatório separada.
Persistir a memória do agente para revisão humana confiável com o LangGraph MongoDB Checkpointer: O checkpointer permite que um fluxo de trabalho pausado para revisão do oficial sobreviva a reinicializações e seja retomado com contexto completo, e funciona como um registro de auditoria do que os agentes sabiam quando tomaram uma decisão.
Autores
Peyman Parsi
Mehar Crewal
Andrea Alaman Calderon
Saiba mais
Saiba mais sobre como MongoDB e a IA agentiva impulsionam uma jornada de empréstimo digital de ponta a ponta que simplifica os fluxos de trabalho, reduz o risco e eleva as experiências do mutuário.