Case Study 03
Portfolio build — a complete, working system built and measured by Altus Initiatives to demonstrate this capability. Performance metrics below are measured from the build; agency-impact figures are projected for a representative brokerage.
Most AI assistants businesses encounter fall into one of two failure modes. The first is the generic chatbot — it can generate text fluently but has no connection to the business's actual data. Ask it about a listing, a client, or a transaction and it either guesses or says it doesn't know. The second is the over-engineered enterprise system — powerful but expensive, slow to deploy, and requiring a dedicated technical team to maintain.
Neither option serves the real estate agency that needs something in between: an AI assistant that can actually access and reason over real business data, integrate with the tools the team already uses, and operate reliably without constant supervision.
There is a further challenge that rarely gets addressed upfront: vendor lock-in. Businesses that build on a single AI provider are exposed to pricing changes, model deprecations, and capability gaps. A production-ready assistant needs the flexibility to adapt without rebuilding the underlying system.
A fully operational AI business assistant — connected to live business data, accessible through existing workflows, and built to answer real questions accurately — without requiring a technical team to maintain it. The system operates across two layers:
The core processing layer, handling all AI reasoning and data access:
The layer that connects the assistant to existing business workflows:
Zero vendor dependency
For a brokerage team using this assistant daily, the operational impact is a reduction in the time agents spend searching for information across disconnected systems — listings, contacts, transaction data — and an increase in the time they spend acting on it.
Automation Integration Layer
│
Incoming Query (message + session ID)
│
▼
Forward to Intelligence Backend
│
▼
┌───────────────────────────────────────────────────────┐
│ Intelligence Backend │
│ │
│ Receive Query │
│ │ │
│ ▼ │
│ Session Memory Lookup │
│ │ │
│ ▼ │
│ AI Model (provider-agnostic) │
│ │ │
│ ├── Tool: Contact & Client Lookup │
│ ├── Tool: Listing & Property Lookup │
│ ├── Tool: Commission & Fee Calculator │
│ └── Tool: Market & Catalog Data │
│ │ │
│ ▼ │
│ Response + Token Usage + Cost Estimate │
│ │ │
│ ▼ │
│ Session Memory Update │
└───────────────────────────────────────────────────────┘
│
▼
Response received by Integration Layer
│
▼
Priority Evaluation
│
┌─────────────┴─────────────┐
▼ ▼
High Priority Standard
│ │
▼ │
Team Notification │
(full context) │
│ │
└───────────┬───────────────┘
▼
Interaction Log
(response, session, provider,
tokens, cost, timestamp)
Full architecture documentation available upon engagement.
| Component | Tool |
|---|---|
| Backend framework | FastAPI (Python) |
| AI providers | OpenAI GPT-4o mini, Anthropic Claude Haiku |
| Tool execution | Custom Python tool handlers |
| Session memory | Per-session JSON store |
| Automation layer | Make.com |
| Priority routing and logging | Make.com |
| Team notifications | Slack |
| Interaction and cost logging | Google Sheets |
Multi-provider architecture from day one. The system treats AI providers as interchangeable backends rather than a fixed dependency. Provider selection is a runtime parameter, not a hardcoded configuration. If pricing changes, a model is deprecated, or a better option emerges, switching requires changing one parameter — not rebuilding the system. For a business making a long-term investment in AI infrastructure, this is not optional.
System prompt as tool authority. The data tools work reliably because the system prompt gives the model explicit, authoritative instructions on how to invoke them — the correct query format, available fields, and how to interpret results. Vague tool descriptions produce unreliable tool selection. Precise, authoritative descriptions produce consistent behavior. This is a non-negotiable design principle applied across every tool-use implementation Altus builds.
Session memory by ID, not by user. Conversations are stored by session ID rather than authenticated user identity. This keeps the backend stateless — the caller manages continuity by passing the same ID across turns. It scales horizontally without shared state and supports concurrent sessions without coordination overhead. For a team of agents using the assistant simultaneously, this matters.
Cost tracking as a first-class feature. Every API call logs token consumption and cost at the point of execution. Production AI systems that don't track costs routinely exceed budget without warning. Logging cost per call gives the operator a live view of spend and a baseline for optimization. This is built into every Altus system from day one — not added when a bill arrives that surprises someone.
Intelligence and integration as separate layers. The AI processing lives entirely in the backend. The automation layer handles orchestration — receiving requests, routing responses, sending alerts, logging data. This separation means the AI logic can be tested, versioned, and improved independently of the automation platform, and the integration layer stays simple and maintainable.
Two implementation details in this build are scoped for initial deployment and are upgraded in full production engagements:
This is the same architecture we build for clients. The first step is a 30-minute discovery call — no pitch, no commitment.
Book a discovery call