Building a multi-phase property assistant AI: unified agent approach vs distributed agent system?

Other Questions langsmith
1

Hi everyone!

I’m working on a conversational property assistant that guides users through the entire home buying process. The system needs to handle three main phases:

  1. Requirements gathering - understand budget constraints and preferences
  2. Property exploration - show listings and collect user feedback
  3. Purchase assistance - calculate financing options and schedule visits

I’m considering different architecture approaches:

  • Single comprehensive agent - One main system with multiple capabilities
  • Coordinator with specialized modules - Master controller directing focused sub-systems
  • Layered communication system - Separate components for planning, communication, and execution

Looking for community input on:

  • Effective prompt strategies for maintaining context in unified agents
  • Methods for sharing information between modules efficiently
  • Tools and platforms that simplify the technical complexity
  • Production experiences with different architectural patterns

Current technology stack includes:

  • Vercel AI SDK
  • Google development tools
  • Considering LangGraph migration

Any insights or cautionary tales would be appreciated. The goal is building something that scales well as features and user base grow.

class PropertyAgent:
    def __init__(self):
        self.current_phase = 'discovery'
        self.user_profile = {}
        self.available_tools = ['search_listings', 'calculate_mortgage', 'book_viewing']
    
    def process_user_input(self, message):
        if self.current_phase == 'discovery':
            return self.gather_requirements(message)
        elif self.current_phase == 'search':
            return self.find_properties(message)
        else:
            return self.assist_decision(message)
2

The layered approach is probably overkill here. I’ve watched teams burn months over-engineering this when a basic coordinator plus 3 specialized agents does the job. Your code already has solid phase separation - just build on that instead of starting over. We made the classic mistake of optimizing too early before we actually understood how users behave.

3

Been through this exact challenge building similar systems at work. The coordinator approach usually wins for complex workflows like yours.

Here’s what I’ve learned - cramming everything into one agent creates maintenance nightmares. Your context gets messy, prompts turn into giant walls of text, and debugging becomes impossible.

I’d go with specialized agents talking through a central workflow engine. Each phase gets its own focused agent with clear responsibilities. The coordinator handles state management and routes between phases.

The real game changer? Automating the whole orchestration layer. Set up workflows that automatically trigger the right agent based on user state, handle context passing between phases, and manage fallbacks when things break.

For your property assistant, picture dedicated workflows for each phase that automatically fire based on user progress. Requirements agent collects data and passes clean structured info to the search agent. Search agent maintains conversation history while feeding results to the purchase agent.

I’ve built similar multi-phase systems this way and they scale beautifully. Clean separation of concerns, easy testing of individual components, and simple deployment of updates to specific phases.

The workflow automation handles all the complex routing logic, so your agents stay focused on their core tasks. Plus you get built-in error handling and retry logic without coding it yourself.

Check out Latenode for the orchestration layer - it handles all the workflow automation and agent coordination without the complexity of building it from scratch: https://latenode.com

4

Started with one agent for our real estate chatbot last year. Hit major scaling problems by month four. The single agent got flaky as we added features - contexts mixed between phases and it confused user requirements from old conversations.

We refactored to a distributed system where each phase runs separately with its own context management. Game changer was treating user data as immutable objects passed between agents instead of shared state. Requirements agent spits out structured JSON that feeds directly into search parameters. Search results become input for financing calculations.

For your stack, LangGraph migration makes sense if you need complex routing logic. But I’d try keeping your current setup and implementing clean interfaces between phases first. Sometimes we overcomplicate things trying to solve problems we don’t actually have.

One practical tip - get comprehensive logging for user session flows early. When things break across multiple agents, you need to see exactly where the handoff failed. We spent weeks debugging stuff that good logging would’ve caught immediately.

Distributed approach scales way better but needs more upfront planning for data contracts between components.