Review a design doc: a maintenance agent for 38,000 apartments

You are the solutions architect on the Brightwell Residential account (fictional). Their team sends you this design doc two weeks before launch and asks for a review. The session runs 60 minutes: about 10 minutes reading, 20 minutes presenting your findings, then 20 to 25 minutes of pushback from the team lead.

Design doc: "Fixie", the tenant maintenance agent (v1)

1. Goal. Brightwell manages 38,000 apartments in 120 buildings. Tenants report maintenance problems by SMS or web chat. Fixie triages each request, creates a work order, books a vendor and answers status questions. Target: 80% of requests handled with no staff involvement. Launch: all 120 buildings on January 15, at the start of lease renewal season.

2. Volume. About 9,000 conversations a day, spread over 16 waking hours. A conversation averages 6 turns. The peak hour is twice the average hour. About 40% of conversations end in a new work order. 22% of tenants prefer Spanish; v1 is English only.

3. Architecture. The SMS gateway and the web chat call a webhook. One agent service (a single container) sends each turn to the large Claude model with the tools below, served by an MCP server that wraps our property system (PropSys) and our vendor booking service (FixNow). The agent calls tools as needed and replies. Most turns use one or two tools. We use the "latest" model alias so we always get improvements.

4. Tools.

• get_tenant(phone): returns the tenant, unit and lease for a phone number.
• get_unit(unit_id): returns unit details, access notes and the entry code for vendors.
• list_work_orders(unit_id): all work orders for a unit, all years.
• create_work_order(unit_id, category, priority, description).
• schedule_vendor(work_order_id): finds open slots, holds one and confirms it (3 FixNow calls).
• issue_rent_credit(unit_id, amount, reason): for outages over 24 hours. Credits post to the tenant ledger at once.
• send_sms(phone, text).
• search_knowledge(query): searches our building manuals (PDFs for every building).

5. Identity. SMS tenants are identified by the sender's phone number through get_tenant. Web chat tenants log in.

6. Prompt. A 2,000-token system prompt, 3,000 tokens of tool definitions, the conversation so far, and the unit's full work-order history so the agent has context (on average 40 work orders x 150 tokens = 6,000 tokens).

7. Capacity and cost. Each conversation uses about 12,000 input tokens and 800 output tokens. 9,000 x 12,000 = 108 million input tokens a day, which is $324 at $3 per million. 9,000 x 800 = 7.2 million output tokens, which is $108 at $15 per million. Total $432 a day, about $13,000 a month. FixNow allows 60 requests a minute. We make one FixNow call per conversation, so 9,000 a day is about 0.1 a second, far below the limit.

8. Safety. The system prompt tells Fixie never to share another tenant's data, to issue credits only when policy allows (up to $250), and to tell tenants to call 911 for fire or gas.

9. Testing. Our property managers tested 50 conversations by hand. 47 were good.

10. Reliability. If Claude or PropSys is down, Fixie replies "Please try again later." Failed tool calls are retried 3 times.

11. Logging. We log every prompt and response to our analytics warehouse and keep them for 5 years for analysis.

Your tasks:

1. Summarize the design in two sentences.
2. Rank the top three risks by impact and likelihood. Give the evidence from the doc and a concrete fix for each.
3. Check the doc's capacity and cost math, and give corrected numbers.
4. List what is missing from the doc.
5. Then defend your ranking when the team lead pushes back.

Give yourself 10 minutes with the doc. Then write a two-sentence summary, your top three risks in order, and the corrected monthly cost.