Automations MVP · measured 24 Aug 2026

Three Jobs, Measured

The Triage Agents pitch names three jobs and an overlaps table of the triggers, conditions and actions they share. That table is the measuring stick, so this is it filled in against what the engine actually does today — verified against a live deployment, not against the code alone.

Short version: every trigger the three jobs need is working. The conditions are most of the way there. The actions exist but two of them have never once run, and one capability that all three jobs list is built, tested, and has no implementation anywhere.

The three jobs

Job 1 · Auto Assign

Route & assign requests to the right person or team

Get every incoming request to the right technician, shop, team or contractor for its type and location, instead of a person hand-picking an assignee each time.

Best covered
Job 2 · Prioritize & Categorize

Categorize and prioritize incoming requests

Decide what a request actually is and how urgent it is — the classification the other two jobs depend on.

Present but unproven
Job 3 · Schedule Work

Schedule when work will be completed

Decide when a request is supposed to be done, rather than applying one default the organization picked once at implementation.

Headline ask is expressible today

The overlaps table, filled in

Capability Assign Categorize Schedule Where we are Evidence
Triggers
Work Request Created ✔✔✔ Working trigger.record.submitted — seeded and enabled on test-3
Work Request Approved ✔✔✔ Working trigger.record.approved — this is the half of the top gap that said assignment “fires only at creation”
Work Request Edited ✔✔✔ Working trigger.record.fieldChanged — depth-limited so a plan cannot re-trigger itself forever
Conditions
Building Group, Building, Resource ✔✔✔ Partial Building and Resource are both readable and scopeable. Building group has no field at all.
Module, Request Type ✔✔✔ Working Both, twice over — as plan scope and as conditions
Requesting User & User Type ✔✔✔ Missing Neither is in the readable field set. No plan can branch on who filed the request.
Request Priority ✔·✔ Built, unexercised PriorityID is readable — but priority is switched off in every environment we have tested in
Custom Field Values ✔✔✔ Working Matched by field name against real options — verified with “On hold status:” is “Waiting on parts”
LLM Judgement on Routing ✔✔✔ No implementation Block, port, cost metering and unit tests all exist. Nothing implements ILlmClassifier, so the block is absent from every catalogue.
Actions
Assign / Reassign — fixed ✔·· Working Both blocks, both exercised against real records
Prioritize — fixed ·✔· Never run Gated on the organization having priorities on, which none of our environments do
Edit — fixed ·✔✔ Working Deliberately five fields: name, due date, start, end, location. Anything that re-scopes a record is refused.
Switch Module — fixed ·✔· Never applied Exists, but declares requiresAPerson — so it can never run unattended, by design
Assign · Prioritize · Edit · Switch — LLM variants ✔✔✔ Not started The LlmAction cost tier is defined and nothing implements it. Its own comment calls it “the tier that needs a ceiling.”
Schedule requests as a record type ✔·· Missing The engine accepts WorkRequest and nothing else. Named explicitly in the top gap, with three sources.

What this actually means

The most-corroborated ask in the whole pitch is buildable today

Job 3’s dominant request, raised independently by four accounts, is to derive the due date from priority rather than from request type. Every piece of that plan exists and is verified working: read PriorityID, then set DueDate as a number of days from now. The demonstration set already runs the same shape for a different condition.

The catch is the same one that dogs Job 2 — priority is disabled everywhere we have tested, so this specific plan has never been run end to end.

The top gap for Job 1 is closed on both of its halves

Limited auto-assignment conditions is the best-grounded gap in the set — stated by FMX reps on four separate calls. It has two halves, and the engine closes both: assignment can now fire on approval and on edit, not only at creation, and conditions can read custom fields rather than just request type and building.

The only triggers are the creation of the request, and then the sub triggers need to be request type or building. FMX, on a customer call — the constraint the engine removes

Job 2 is the one carrying the most risk

Mechanically it looks covered: prioritize, switch module and edit all exist. But prioritize has never run, switch module has never been applied, and switch module can never run unattended because it declares that it requires a person — a module decides who can see a request, so that constraint is deliberate rather than incidental.

More importantly, the job’s headline ask is exactly the capability with no implementation: deciding that a leak is high priority is a judgement, not a rule. FMX has already told a customer this is a future-AI answer.

Routing by who asked is not expressible at all

All three jobs list requesting user and user type as a condition, and neither is in the readable field set. Several of the routing rules customers described — a sub-category chosen by the requester, a campus zone, a tier-1/tier-2 handoff — depend on branching on something about the person or their selections rather than the record’s own columns.

What would move the most, in order

  1. one adapter

    Implement ILlmClassifier

    The only missing capability that all three jobs list, and the only one where the engine work is already finished — block, port, metering and tests included. Nothing else on this list unblocks three jobs at once.

  2. small

    Put a read allow-list in front of the classifier’s input

    Do this before the adapter, not after. The input binding walks any property by reflection today, and the readable field list is enforced nowhere — so what leaves for the model is currently wider than intended. This is K-12 data; it is a product decision, and it is far cheaper to answer now than after the first plan is authored.

  3. small

    Add requesting user and user type as conditions

    Named by all three jobs and absent entirely. Likely just an addition to the readable set plus the binding work, and it unlocks the routing rules customers described most concretely.

  4. unknown

    Decide whether schedule requests are in scope

    The engine is WorkRequest-only. Auto-assign not existing for scheduling is called out in the top gap with its own evidence — one account keystrokes 10–15 assignees per schedule request. Either it is MVP or it is explicitly deferred; right now it is neither.

  5. config

    Turn priority on somewhere we can test

    Two rows of this table are unverifiable until then, and one of them is Job 3’s headline ask.