← All case studies

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.

Production implementationAnthropic APIPostgreSQL + S3Multi-tenantNo vector databaseNo RAG pipeline
Public visual policyInterface visuals on this page are anonymized concepts created for this case study. They do not reproduce the client’s private application design.
UsersResidents, boards and property managers
ArchitectureSpecialized agents with shared orchestration
DataPreprocessed PostgreSQL content backed by S3
ControlTenant scoping, audits and runtime guidance

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.

Operations workspaceIllustrative concept
Demo Property 01

Request operations

All systems operational
Waiting12
In progress04
Completed today38
Resident assistantIllustrative
Property contextDemo Building • Resident scope

When can renovation work be carried out?

Resident Agent

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 guide
Ask a property question ↑
Workflow auditIllustrative
Final verdictPASSGrounded answer · correct scope
01Source allocationOnly permitted resident sources used✓
02Tenant boundaryProperty and user scope verified✓
03Answer supportClaims matched against retrieved data✓

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

01

Blast radius

A failure in one feature could interrupt every AI workflow.

02

Prompt contamination

Instructions for one role could reduce the accuracy of another.

03

Debugging cost

A single pipeline makes failures harder to trace and reproduce.

04

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.

01

Intake and claim

Dashboard requests enter a shared database queue. A scheduler atomically claims each item so concurrent workers cannot process it twice.

02

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.

03

Source planning

A lightweight planner chooses only from pre-approved sources and returns structured filters and operator guidance.

04

Scoped retrieval

The data layer reads preprocessed content from PostgreSQL, applies tenant boundaries and builds size-capped packages.

05

Worker execution

The orchestrator estimates context volume and selects one worker or several document-preserving shards.

06

Synthesis and delivery

Outputs are reconciled against a complete manifest, normalized, logged, stored and returned to the dashboard.

Unified production architectureHigh-level system flow
01 · IngestionConnected dashboardsResidents · Board · Managers
02 · DispatchRequest queueAtomic claim · concurrent workers
03 · RoutingAgent routerType-based matching
Resident AgentBoard AgentManager AgentMinutes AgentSummary AgentTitle Agent
PlanSource planner + operational memory
RetrievePostgreSQL + S3, tenant scoped
ExecuteSingle or multi-worker orchestration
ResolveSynthesis, delivery + audit
Complete production flow extracted from the case-study architecture—from intake and routing through scoped retrieval, worker execution and two-pass quality assurance.

Specialized agents

Each agent has one clear operational responsibility.

The architecture improves prompt quality, makes access rules explicit and lets individual capabilities evolve independently.

Role-based answers

Manager Agent

Handles operational and management questions with access to manager-authorized sources.

Governance

Board Agent

Works with board-authorized material such as resolutions, financial information and privileged discussions.

Resident support

Resident Agent

Answers resident questions using only resident-scoped data and applicable property context.

Structured output

Meeting Minutes Agent

Selects the correct province and meeting-type template, combines transcript and metadata, and produces structured minutes.

Multimodal

Summary Agent

Summarizes database records or uploaded documents in specified formats and lengths, including embedded images as visual inputs.

Conversation UX

Title Agent

Turns the first message into a concise conversation title without retrieval or orchestration overhead.

Quality control

Workflow Audit Agents

A reviewer flags potential issues, then an authoritative verifier checks ground truth and records Pass, Partial, Fail or Error.

Staff performance

Supervisor Agent

Evaluates scoped activity across requests and team discussions, with worker splitting for higher-volume analysis.

Configuration-driven agent routingRequest type → dedicated responsibility
Queue workerRead request typeValidate registered handler
DecisionAgent RouterMatch type code
ResidentBoardManagerMinutesSummaryTitleAuditUnsupported → Hold
Configuration-driven routing maps each request to one focused agent. Unsupported types remain on hold with a clear warning instead of entering the wrong workflow.

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.

  1. Estimate first. Combine the user question, history, prompt instructions and fetched data to approximate token volume.
  2. Preserve document order. Split large workloads into contiguous page ranges instead of mixing unrelated fragments.
  3. Give every worker a manifest. Each shard knows the complete assignment, which prevents false claims that unassigned content is missing.
  4. Synthesize successful outputs. Partial worker failures do not discard valid work.
  5. Retry safely. If every worker fails, the system retries the complete request as a single tool-enabled call.
Context-safe worker orchestrationWorkload estimation before model execution
OrchestratorEstimate token volumeData + prompt + instructions
Within safe worker budget?
YESSingle-worker pathAssign all dataInject guidanceExecute model callNormalize response
NOMulti-worker pathPreserve document orderCreate manifestRun sequential shardsSynthesize findings
The orchestrator selects a single worker for safe workloads or document-preserving worker shards when the context is too large.

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.

Tenant boundary

Scoped at every data point

Queries filter by building, unit, ownership or tenure before content reaches a model call.

Role boundary

Sources allocated by agent

Board and manager agents can receive authorized restricted sources; resident agents remain resident-scoped.

Data boundary

Preprocessed and capped

S3 files are enriched and indexed into PostgreSQL, then retrieved as summarized, size-limited slices.

Quality boundary

Two-pass verification

A lightweight reviewer identifies potential problems before a more thorough verifier checks the underlying data.

Deliberate design choice: the implementation uses PostgreSQL and S3 rather than a vector database or RAG pipeline. The runtime retrieves structured, preprocessed content directly under explicit source and tenant controls.
Two-pass workflow auditIndependent review against ground truth
01Load execution bundlePrompt · steps · tools · raw data · answer
→
02Reviewer passFlag suspected discrepancies
→
03Independent retrievalRecheck authoritative source data
→
04Verifier passConfirm or discard findings
→
VerdictPASSPARTIALFAILERROR
The reviewer finds potential issues; the verifier independently checks the data before recording a final verdict.

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

GlobalPlannerWorkerSynthesisFinal response

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.

Dynamic operational memoryChange guidance without redeploying code
AdministrationDashboard guidance rulesPersisted by mode and type60-second cache refresh
Execution modesGlobalPlannerWorkerSynthesisFinal response
Prompt assemblyUniversal + conditional rulesStructured guidance blockFail open with baseline instructions
Runtime guidance is filtered by execution mode and rule type, cached for speed and designed to continue safely with baseline instructions if the cache is unavailable.

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.

No cross-agent failures

Production errors remain contained to the affected agent type rather than interrupting the full system.

Independent iteration

Prompts, templates and role behaviour can change without destabilizing unrelated workflows.

Context safety

Workload estimation and document-preserving partitioning reduce oversized-call failures.

Multi-tenant correctness

Every retrieval path applies tenant boundaries before content reaches the model.

Operator flexibility

Administrators can change live guidance without a code deployment or system restart.

Auditable delivery

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 →

Planning an AI system that must work with real operational data?