AI / Property operations
Building a fault-tolerant multi-agent AI backend for property management.
A production architecture that gives residents, board members and property managers context-aware answers, document summaries, conversation titles and structured meeting minutes—while keeping data access scoped, failures contained and large workloads manageable.
Illustrative product experience
What the operational experience can look like.
These branded interface concepts demonstrate the workflows without exposing the client’s application, branding or data.
When can renovation work be carried out?
Renovation hours are determined from the building’s approved rules. The response cites the relevant document section and stays within the resident’s property scope.
Sources checked · Building rules · Resident guidePrivacy note: no client screenshots, identifiable properties, addresses or production records are displayed publicly.
The challenge
One all-purpose agent did not scale.
Property-management dashboards serve users with very different responsibilities, permissions and questions. Putting resident answers, board analysis, manager operations, meeting transcription and document summarization into one agent would create a fragile system.
Blast radius
A failure in one feature could interrupt every AI workflow.
Prompt contamination
Instructions for one role could reduce the accuracy of another.
Debugging cost
A single pipeline makes failures harder to trace and reproduce.
Access control
Permissions need to be structural—not merely written into prompts.
The solution
Specialize the intelligence. Share the operating system.
Each request is routed to a purpose-built agent. A common layer handles planning, scoped data retrieval, workload sizing, model calls, synthesis, response normalization and activity logging.
Intake and claim
Dashboard requests enter a shared database queue. A scheduler atomically claims each item so concurrent workers cannot process it twice.
Typed routing
A configuration table maps the request code to the correct handler. New agents can be added without changing the rest of the system.
Source planning
A lightweight planner chooses only from pre-approved sources and returns structured filters and operator guidance.
Scoped retrieval
The data layer reads preprocessed content from PostgreSQL, applies tenant boundaries and builds size-capped packages.
Worker execution
The orchestrator estimates context volume and selects one worker or several document-preserving shards.
Synthesis and delivery
Outputs are reconciled against a complete manifest, normalized, logged, stored and returned to the dashboard.
Specialized agents
Each agent has one clear operational responsibility.
The architecture improves prompt quality, makes access rules explicit and lets individual capabilities evolve independently.
Data Source Planner
Interprets intent, chooses permitted sources, applies filters and identifies conditional operational guidance. When only one source is possible, the system skips the planning model entirely.
Manager Agent
Handles operational and management questions with access to manager-authorized sources.
Board Agent
Works with board-authorized material such as resolutions, financial information and privileged discussions.
Resident Agent
Answers resident questions using only resident-scoped data and applicable property context.
Meeting Minutes Agent
Selects the correct province and meeting-type template, combines transcript and metadata, and produces structured minutes.
Summary Agent
Summarizes database records or uploaded documents in specified formats and lengths, including embedded images as visual inputs.
Title Agent
Turns the first message into a concise conversation title without retrieval or orchestration overhead.
Workflow Audit Agents
A reviewer flags potential issues, then an authoritative verifier checks ground truth and records Pass, Partial, Fail or Error.
Supervisor Agent
Evaluates scoped activity across requests and team discussions, with worker splitting for higher-volume analysis.
Large-context resilience
The worker pattern prevents oversized calls from becoming system failures.
The system estimates workload before any expensive model call and changes its execution strategy based on the available context budget.
- Estimate first. Combine the user question, history, prompt instructions and fetched data to approximate token volume.
- Preserve document order. Split large workloads into contiguous page ranges instead of mixing unrelated fragments.
- Give every worker a manifest. Each shard knows the complete assignment, which prevents false claims that unassigned content is missing.
- Synthesize successful outputs. Partial worker failures do not discard valid work.
- Retry safely. If every worker fails, the system retries the complete request as a single tool-enabled call.
Safety and control
Permissions are enforced by architecture.
Role separation, tenant scoping and source allocation are built into the data path. The model never receives information the active agent is not permitted to access.
Scoped at every data point
Queries filter by building, unit, ownership or tenure before content reaches a model call.
Sources allocated by agent
Board and manager agents can receive authorized restricted sources; resident agents remain resident-scoped.
Preprocessed and capped
S3 files are enriched and indexed into PostgreSQL, then retrieved as summarized, size-limited slices.
Two-pass verification
A lightweight reviewer identifies potential problems before a more thorough verifier checks the underlying data.
Operational memory
Change agent behaviour without redeploying code.
A database-backed policy layer lets administrators update terminology, reporting rules, emergency handling and communication style from the dashboard.
Five execution modes
Universal rules such as terminology and communication style are always included. Conditional rules—such as reporting or emergency guidance—are selected by the planner only when relevant.
The catalog is cached for 60 seconds so admin changes propagate quickly. If the database or cache fails, the agent logs a warning and continues with baseline instructions.
Production outcomes
A system designed to grow one agent at a time.
The key result is not simply more AI features. It is an operating model that makes each feature easier to secure, observe, improve and scale.
Production errors remain contained to the affected agent type rather than interrupting the full system.
Prompts, templates and role behaviour can change without destabilizing unrelated workflows.
Workload estimation and document-preserving partitioning reduce oversized-call failures.
Every retrieval path applies tenant boundaries before content reaches the model.
Administrators can change live guidance without a code deployment or system restart.
Activity logs, complete manifests and two-pass verification make results easier to review.
The engineering principle
Specialization compounds.
An agent that does one thing well is easier to debug, secure and update. A shared orchestration layer turns those focused agents into a cohesive production system—without accumulating the fragility and operational risk of a single all-purpose model.
Explore DigiLynx AI & Automation →