Skip to main content

Overview

In one line: HIGHFIELD is an AI assistant ("Alex Carter") that runs a property's entire maintenance process by email and chat — from "my tap is leaking" all the way to the contractor finishing and getting paid — writing everything into Microsoft Business Central.

What it is​

HIGHFIELD is an AI-powered property-maintenance coordinator built on the Lua agent platform. It presents as a single friendly persona — Alex Carter, Property Maintenance Coordinator (src/index.ts:69,73) — that talks to people in natural language and quietly does the back-office work behind the scenes: logging issues, finding contractors, getting quotes approved, scheduling visits, and closing the loop.

Every piece of data it touches is stored in Microsoft Dynamics 365 Business Central (the property company's real accounting/ERP system), so the AI is not a side database — it writes into the system of record (README.md:1-4).

The problem it solves​

Property maintenance is a coordination problem. A tenant reports a problem; someone has to understand it, find a suitable contractor, get a quote, check it's within budget (and get sign-off if it isn't), agree a visit time that suits the tenant, make sure the work gets done, collect proof and an invoice, and finally check the tenant is happy.

Traditionally that's a person juggling phone calls and email threads — and things fall through the cracks: slow responses, lost photos, double-bookings, surprise costs. HIGHFIELD automates that whole chain and keeps a complete, auditable trail on every ticket (src/index.ts:52-64).

Who uses it​

The agent figures out which kind of user you are automatically, from your phone number or email, before it does anything else (src/index.ts:110-119):

  • Tenants — people living in the managed properties. They report issues, send photos, confirm visit times, and give feedback. They use the tenant-facing toolset (the property-maintenance skill, src/skills/maintenance.skill.ts).
  • Vendors / contractors — the trades who do the repairs. They browse available jobs, claim them, submit quotes, offer visit times, start work, and complete jobs with photos and an invoice (the vendor-management skill, src/skills/vendor.skill.ts).
  • Admins / approvers — property managers and the finance approver. They sign off on costly quotes, ask the agent questions ("how many open tickets in this building?"), and give instructions when something's stuck. Admin powers unlock only when the sender's email matches a configured approver address (the admin skill, src/skills/admin.skill.ts:18-20).

The value​

For the property company, the value is speed, consistency, and a defensible paper trail.

  • Nothing gets dropped. Each tenant message becomes a ticket — there is deliberately no "sorry, I can't help with that" exit for a registered tenant (src/index.ts:144-148).
  • Financial control is automatic. Quotes over a threshold can't proceed without an approver's reply (src/utils/constants.ts:146).
  • It avoids legal exposure. The agent is carefully written never to tell a tenant in writing that an issue is "urgent" or "serious" — because that becomes a written admission the client could be held to (src/index.ts:389-427).

How people reach it​

The same agent is reachable over web chat and — most importantly for the live deployment — email (a tenant or contractor simply replies to a thread). The system understands email threads, reconnects a reply to the right ticket, and keeps each ticket's correspondence organised. Proactive nudges (escalations, daily and weekly briefs, completion reminders) go out on a schedule without anyone asking.

Gotchas & failure modes​

⚠️ Deployment drift is real. The deployed build (dist-v2/sources/*, hashed filenames) can diverge from the working-tree src/. For example, the live build has an LLM_FAILOVER_MODEL lever and a () => resolveModel(...) model selector that the current branch lacks. Never assume src/ matches production — verify with lua <type> versions. See Operations.

HIGHFIELD is live. Changes follow a strict discipline: diagnose before designing, additive-only, one primitive per deploy, smoke between. See Operations & runbook.