Custom AI workflows that stop at the decision

The useful question about AI in property management is not what it can do. It is where it should be made to stop.

Get that line wrong in the permissive direction and you have a system that serves a notice on the wrong ground, or credits a payment against the wrong instalment, at three in the morning, with no human able to say why. Get it wrong in the restrictive direction and you have an expensive autocomplete that saves nobody any time.

The line we draw

AI does the reading, the extraction, the classification and the drafting. A human takes every decision that has a consequence outside the system.

Steps two and three are doing very different jobs and it is worth being precise about which is which. Understanding a document is genuinely a language problem, and a model is far better at it than a regular expression. Deciding whether a Section 8 on ground 8 has been given at least the statutory notice period is not a language problem. It is arithmetic against a statute, and it belongs in code where it is testable and where it behaves identically every time.

Where this earns its keep

Certificates. A gas safety record arrives as a PDF or a photograph. The model extracts the type, the issue date, the expiry, the engineer and the property. A person confirms it in a couple of seconds rather than typing five fields. The certificate record only comes into existence after that confirmation — so every certificate in the system is one a human has looked at.

Bank statements. Uploaded as PDFs, read into transactions, matched against expected rent. The matching is a proposal; the reconciliation is yours to accept.

Maintenance triage. A tenant reports damp in a first-floor bedroom in free text. The model classifies the hazard and the urgency, which determines what timescales apply and what surfaces on the dashboard. What it does not do is instruct a contractor by itself.

The failure we designed against

Here is a real one, because it is more instructive than a principle.

Recording rent is a common assistant action. The proposal card used to calculate “this clears the instalment” against the outstanding balance, while the endpoint that actually performs the action decides paid-or-not against the full instalment amount. With £600 already recorded against £1,200, the card correctly displayed “already recorded: £600” and then, immediately below, asserted that confirming would clear it. Confirming left the instalment part-paid — and overwrote the earlier £600.

Nothing errored. The figures on screen were all correct. The consequence sentence was computed by different logic from the action it described, and that gap is where the harm lived — on the arrears number a Ground 8 claim rests on.

The fix was not better prose. A proposal’s stated outcome is now derived from the same rule the action uses, and a test runs every case through both paths and fails the build if they disagree. That is the general lesson for anyone building this: a confirmation step is only a control if what it promises is computed by the thing that will happen.

What we build in a bespoke AI engagement

Usually one of three things. An extraction path for a document type you receive constantly and key in by hand. A classification step that routes work correctly at intake. Or an assistant capability specific to how you operate — a question your team asks daily that currently requires someone to open four screens.

All three follow the same shape above, and we would rather show you the confirmation step early than at the end, because that step is usually the difference between a client who trusts the automation and a client who quietly stops using it.

If there is a document or a decision your team repeats hundreds of times a month, that is the conversation to have: hello@tekniti.ai.