Casa Agent

Property knowledge that can be approved, traced, and withdrawn.

Casa's instruction editor with Maintenance, Cleaner and Casa Azul scope chips above an arrival checklist.
The scope sits beside the instruction A procedure applies to named roles and properties. This is the real console with fictional records; the screenshots illustrate the workflow, not a customer deployment.

An assistant for the recurring questions between a property manager and the people who maintain their homes. It answers from approved procedures, asks when context is missing, and routes decisions back to the manager.

I built the decision pipeline, the knowledge lifecycle, and the operator console around one practical problem: a useful answer today must not silently become permission tomorrow. A one-time purchase approval is evidence of a decision. A standing procedure is a separate thing that somebody has to approve.

Role
Product and engineering — retrieval, decision policy, learning review, database migrations, evaluation and console UX.
Status
Working prototype. The decision and review workflow is implemented; production WhatsApp delivery and a supervised customer pilot remain unfinished.
Verification
66/66 before and after on the same authored scenario set and corrected grader, including 27 hard cases. Recorded 5 September 2026.
Tradeoff
More context costs more tokens: approximately 39% more chat input and 14% more output in the final evaluation run.

One worker, several houses, different instructions

A caretaker can work at two properties with different equipment and procedures. A cleaner can need an answer in Portuguese while the manager writes in English. Some questions have a documented answer; others ask for spending or access permission. Treating all of these as generic chat loses the distinction that makes the answer useful.

Casa starts with a known contact and their assigned roles and properties. Retrieval is limited to that allowed scope. The conversation supplies clues about which property is being discussed, including follow-ups. That property selection remains a conversational inference within the allowed corpus, so ambiguous questions still need clarification.

A fictional caretaker's settings showing a 75 euro spending threshold, Portuguese language and reply mode.
Policy belongs to the working relationship Language, spending threshold and whether to ask the manager first are visible contact settings. The three people shown are fictional demo contacts.

Retrieval has an authority order

The manager's canonical instructions outrank reviewed additions. Each gets a separate retrieval budget so learned material cannot crowd out the original procedure. Retrieved passages carry source identifiers that the response schema can select; the server checks those identifiers, and URLs must come from the procedure evidence.

Those checks improve attribution, but an allowed citation does not prove every sentence follows from it. Content checks and human review still matter. Deterministic rules provide additional backstops for clear emergencies, access requests and spending above configured thresholds; natural-language interpretation still has limits.

Learning is a reviewable change to the record

When the manager supplies missing knowledge, Casa retains the original answer as evidence and proposes reusable wording with a rationale and scope. The raw answer stays inactive. An approved addition receives its own linked document, and database retrieval excludes it until approval completes. A correction to a canonical instruction waits for a manual edit.

Retiring that knowledge removes both its learned document and the linked precedent from future answers. Editing disables stale precedent wording. This is maintained, retrieved knowledge; the process does not train the model's weights.

A proposed linen stock-check procedure with original manager answer expanded, scope chips, and Use this and Reject controls.
Read the evidence before accepting the rule The fictional proposal keeps a repeatable linen check while leaving purchase permission with the manager. Neither this answer nor its proposal came from a real customer conversation.

The migration had to preserve passing behavior

The six workstreams covered indexing and scope, proposal activation, retractable learning, evaluation isolation, grounding, and operational UX. The acceptance rule was concrete: no previously passing scenario could become a failure. The comparison rejects missing cases and changed scenario inputs or expectations.

The first current-code run managed only 35/66 because retrieved source IDs and generated IDs disagreed. Later runs exposed follow-up context mistakes and access requests that missed mandatory escalation. Fixing those defects mattered more than adding another retrieval service or a training pipeline.

The final comparison and a fresh repeat passed 66/66. A narrow grader correction recognized equivalent Portuguese repetition counts; it was applied to the baseline too. The baseline ran the earlier brain and policy through an isolated adapter on the migrated database. It was not a replay of a frozen pre-migration production database or historical model version.

The final suite used 184,784 chat input tokens and 29,114 output tokens, against 133,349 and 25,466 for the baseline. That supports a regression result on this sample, with a real token cost. It does not establish universal reliability, lower operating cost, or superiority over a competing product.

Unfinished work should be visible

The console brings waiting questions and operational failures into an attention queue. Procedure saves preserve drafts on failure, expose incomplete indexing for retry, and protect unsaved edits during navigation. Contact preview runs the decision path without sending a message. These controls give the operator somewhere to act when the system cannot finish.

Casa attention queue with a fictional 120 euro purchase question waiting for the manager.
A question that still needs a person The demo shows a purchase request awaiting an answer. The property chips describe the contact's assigned scope, rather than proving which property an escalation targets.

Where this belongs in a property manager's toolkit

Casa's proposed niche is continuing contractor relationships and controlled reuse of operating knowledge. Products already sell AI knowledge bases and handoff, so those features alone are not a competitive argument. respond.io documents knowledge sources and source references; Breezeway documents property answers, sources and captured learning. The useful question is whether Casa's particular approval and scope workflow solves a gap in the manager's existing process. respond.io documentation; Breezeway documentation.

The accompanying use-case document compares six products and proposes a supervised trial. Casa does not manage bookings, collect rent, dispatch technicians or track repair completion. Those systems would remain in place.

What comes next

Complete and verify message delivery, then trial a small set of owner-reviewed procedures with regular contacts. Measure supported replies, missed and unnecessary escalations, wrong-property facts, manager review time and total cost. The product earns a place only if net manager time improves without additional incorrect answers or missed required decisions.

The recorded evaluation and targeted browser checks support the prototype's tested behavior. Real delivery was not re-tested in that verification, and concurrent operators and customer account isolation need work before a shared commercial service.

  • Python
  • Next.js
  • React
  • TypeScript
  • Supabase
  • PostgreSQL / pgvector
  • OpenAI
  • RAG evaluation

Evidence snapshot: 5 September 2026. Source of truth: Casa's six-change verification report and saved evaluation runs. Screenshots use the exported console with read-only fictional data and make no model calls.