Multi-Agent AI Platform for Interior Design, Product Data, and Project Workflows

By Amar Kumar

A proposed multi-agent interior design AI platform for a product team building customer-facing experiences in 3D modeling, interior design, architecture, and procurement. The architecture would use Mastra orchestration with TypeScript services, Python data pipelines, and PostgreSQL — three specialized agents (SKU ingestion, design selection, project coordination) sharing memory, tool registries, and eval gates so outputs are reliable enough for production workflows, not demo chat.

Proposed outcome: Observable Mastra agents that reason over structured product catalogs, call internal APIs with retries and handoffs, and ship measurable quality improvements through traces, evals, and regression suites.

Scenario

This brief describes a proposed solution — not a delivered engagement. It maps a pattern common to design-tech products: an existing codebase, a growing SKU catalog, and a need for agents that integrate with real systems rather than generic chat wrappers.

• Platform: Interior design / architecture product with 3D modeling, room planning, and procurement
• Owner profile: Product engineering team with production TypeScript apps; agents must be observable, testable, and safe to deploy incrementally
• Scope: SKU ingestion agent, design agent, project agent — plus shared orchestration, memory, evals, and voice/SMS surfaces
• Stack direction: TypeScript + Mastra for orchestration and APIs; Python for bulk data normalization; AWS + PostgreSQL for state

Problem

Generic LLM chat does not survive contact with structured product data, budget constraints, or procurement handoffs:

• Catalog chaos — SKUs arrive from vendors with inconsistent attributes, missing dimensions, and duplicate variants; manual cleanup blocks new product launches
• Design hallucination — agents pick products that do not exist in catalog, violate room constraints, or ignore budget without grounded retrieval
• Project drift — scope, budget, and status live in separate systems; users get stale updates unless an agent coordinates across project, design, and procurement APIs
• No shared memory — each chat session forgets prior room context, approved selections, and open procurement tasks
• Unobservable failures — without traces and evals, tool-call errors, retry storms, and prompt regressions surface only in customer complaints
• Unsafe automation — publishing unvalidated SKU records or placing procurement actions without permission gates risks revenue and trust

Requirements

Functional

• SKU ingestion agent — gather vendor feeds, validate schema, enrich attributes, flag gaps, stage records for human review, publish to catalog API
• Design agent — select products from catalog given room context, style preferences, constraints (dimensions, budget, availability); explain tradeoffs; persist selections to project state
• Project agent — track scope and budget, coordinate status updates via text or voice, support procurement workflows, hand off to design or catalog agents when needed
• Shared orchestration — Mastra workflows with explicit handoffs, retries, and dead-letter handling
• Tool layer — typed tools for catalog search, project CRUD, procurement quotes, 3D asset metadata, notifications (SMS/voice)
• Evals & regression — golden datasets for SKU validation, design constraint satisfaction, and project status accuracy

Non-functional

• Production-grade logging, tracing (OpenTelemetry-compatible), and structured audit trails
• Human-in-the-loop gates for catalog publish and procurement commits
• Role-based permissions on tools (read-only vs write vs approve)
• P95 agent turn latency targets for customer-facing surfaces; async jobs for bulk SKU ingestion
• Idempotent tool calls with dedupe keys on writes
• AWS deployment with secrets in Parameter Store or Secrets Manager

Architecture

Three layers: customer surfaces (web/voice) call a Mastra orchestration plane that routes to specialized agents; agents read/write PostgreSQL shared memory and call internal product/design/project APIs via typed tools. Python workers handle heavy SKU normalization off the hot path.

flowchart TB classDef surface fill:#dbeafe,stroke:#2563eb,color:#1e3a8a classDef orch fill:#ede9fe,stroke:#7c3aed,color:#5b21b6 classDef agent fill:#f1f5f9,stroke:#64748b,color:#334155 classDef data fill:#ccfbf1,stroke:#0d9488,color:#115e59 classDef ext fill:#f8fafc,stroke:#475569,color:#334155 WEB["Web app\n3D + design UI"]:::surface VOICE["Voice / SMS\nTwilio"]:::surface API["Agent API\nHono / Next.js"]:::surface WEB --> API VOICE --> API ROUTER["Mastra router\nworkflow + handoffs"]:::orch API --> ROUTER SKU["SKU Ingestion Agent\nvalidate · enrich · stage"]:::agent DES["Design Agent\ncatalog · constraints"]:::agent PRJ["Project Agent\nscope · budget · notify"]:::agent ROUTER --> SKU ROUTER --> DES ROUTER --> PRJ SKU -.->|"handoff"| DES DES -.->|"handoff"| PRJ PRJ -.->|"handoff"| SKU PG[("PostgreSQL\nprojects · staging · selections\nagent_runs · memory")]:::data SKU --> PG DES --> PG PRJ --> PG PY["Python worker\nvendor normalization"]:::ext CAT["Catalog API"]:::ext PROC["Procurement API"]:::ext PY --> PG PG --> CAT PG --> PROC

Platform architecture — customer surfaces, Mastra router, three agents, shared PostgreSQL memory, and internal APIs

sequenceDiagram autonumber participant U as User participant API as Agent API participant R as Mastra Router participant D as Design Agent participant PG as PostgreSQL participant CAT as Catalog API participant E as Eval Gate U->>API: room brief + budget API->>R: start design workflow R->>PG: load project memory R->>D: design turn D->>CAT: search_catalog(filters) CAT-->>D: SKU candidates D->>D: check_dimensions_fit D->>PG: save_selections D-->>R: shortlist + rationale R->>E: constraint rubric alt eval pass E-->>API: stream response API-->>U: ranked products else eval fail E-->>R: retry with feedback R->>D: refine selection end

Design session sequence — grounded catalog search, constraint checks, and eval gate before user response

End-to-end flow

Happy-path flow from customer or ops trigger through eval-gated tool execution

Recommended stack

Recommendation: Mastra in TypeScript for agent orchestration and customer APIs, Python for vendor feed normalization, PostgreSQL for durable memory, and AWS (ECS, SQS, RDS) for production deploy.

Why Mastra over LangGraph-only? The product context expects TypeScript-first agent code alongside existing apps. Mastra provides agent primitives, memory, and workflow composition in TS without splitting orchestration into a separate Python service. Python remains for data-heavy SKU pipelines where the ecosystem is stronger.

Why not a single mega-agent? SKU validation, design selection, and project coordination have different tools, eval rubrics, and blast radii. Separate agents with explicit handoffs keep prompts smaller and failures isolated.

Agent design

1 — SKU Ingestion Agent

• Input: vendor CSV/JSON/API feed, existing catalog schema, enrichment rules
• Output: staged product_staging rows with validation report, missing-field checklist, suggested attribute fills
• Tools: parse_vendor_feed, validate_sku_schema, lookup_existing_variant, enrich_from_supplier_api, stage_for_review, publish_to_catalog (gated)
• QA gates: schema pass, no duplicate SKU collision, required dimensions present, price within sanity bounds; human approve before publish_to_catalog

2 — Design Agent

• Input: user brief, room dimensions, style tags, budget ceiling, project ID
• Output: ranked product shortlist with rationale, constraint satisfaction notes, persisted design_selections
• Tools: search_catalog (filtered + vector), get_room_context, check_dimensions_fit, estimate_line_total, save_selection, request_alternative
• QA gates: every SKU must resolve to live catalog ID; budget sum ≤ ceiling unless user override flag; dimensions checked against room bounds

3 — Project Agent

• Input: project ID, user message (text/voice), notification preferences
• Output: status summaries, scope/budget deltas, procurement task updates, handoff payloads to design or SKU agents
• Tools: get_project_state, update_milestone, create_procurement_request, send_sms, initiate_voice_call, handoff_to_agent
• QA gates: no procurement commit without explicit user confirmation token; budget alerts before threshold breach

Shared memory model

• Thread memory — current session messages and tool results (Mastra memory store)
• Project memory — durable rows: room context, selections, budget ledger, open tasks (PostgreSQL)
• Catalog memory — normalized SKU index refreshed on publish events (PostgreSQL + optional pgvector)

Example Mastra tool registration for catalog search — typed schema keeps the design agent grounded to real SKUs:

import { createTool } from "@mastra/core";
import { z } from "zod";

export const searchCatalogTool = createTool({
  id: "search_catalog",
  description: "Query published SKUs by room, style, and budget ceiling",
  inputSchema: z.object({
    roomType: z.enum(["living", "bedroom", "kitchen", "bath"]),
    styleTags: z.array(z.string()).max(5),
    maxBudgetCents: z.number().int().positive(),
    minWidthCm: z.number().optional(),
    maxWidthCm: z.number().optional(),
  }),
  execute: async ({ context, input }) => {
    const rows = await context.catalog.search({
      ...input,
      status: "published",
    });
    return { candidates: rows.slice(0, 12), total: rows.length };
  },
});

Implementation plan

Reporting & ops

Weekly engineering digest: eval regressions, top tool errors, SKU backlog age, P95 design session latency.

Proposed deliverables

Following the phased plan above, a build would ship these artifacts:

• Mastra monorepo with three agents, shared tool registry, and workflow handoff definitions
• PostgreSQL schemas and migrations for project memory, SKU staging, and audit logs
• Python SKU normalization service with vendor adapter pattern
• Customer-facing streaming API for design sessions with session memory
• Twilio SMS/voice integration for project status updates
• Eval harness with golden datasets and CI regression gate
• OpenTelemetry dashboards and on-call runbook for agent failures

Effort estimate

Indicative engineering effort for the phased plan (assumes existing product APIs are documented or discoverable, one staging AWS environment, human-in-the-loop for catalog publish until eval thresholds are trusted):

Scope assumes three agents at production quality, not proof-of-concept demos. Parallel work on Python ingestion and TypeScript orchestration can compress calendar time with two engineers.

Glossary