Common mistake

One model, one chat, no lanes

The system answers everything from memory, mixes law with habit, drafts without citations, and moves too close to real action. It feels efficient right up to the moment it misses a clause, a deadline, or a conflict.

Better design

Separate the jobs, log the steps

The system reads, retrieves, drafts, checks, and escalates in stages. The workflow engine decides what happens next. Human review sits at the points where fiduciary judgment, legal uncertainty, or money movement begins.

Layer 1

UTC baseline

Plain English: the model-law starting point.

The UTC is the baseline operating frame for trustee duties, delegation, information rights, and trustee powers. It is the map, not always the final destination.

Layer 2

Missouri enacted law

Plain English: the pilot state rulebook we actually compare against the UTC.

Missouri matters because enacted law can change timing, wording, and structure. It also matters here because Missouri has a directed-trust and trust-protector statute, so the system must model who may direct whom.

Layer 3

Federal tax overlay

Plain English: the separate tax rule set that rides on top of trust law.

Tax filing, tax elections, and reporting calendars do not replace trust law. They are a separate layer that the system has to track without pretending every tax question is a trust-law question.

Layer 4

Fiduciary best practice

Plain English: the careful way a serious trustee operates even when a statute is quiet.

This is where clean records, reasoned memos, orderly approvals, and conflict checks live. Best practice is not identical to statute, but it matters in real administration.

Layer 5

Workflow logic

Plain English: the operating recipe the office uses to do the work.

This includes states, reminders, approvals, and document routing. It is not law. If the workflow conflicts with the trust instrument or governing law, the workflow loses.

Agent 1

Legal retrieval and citation agent

Plain English: the machine that finds the rule.

What it does: retrieves the trust instrument, amendments, restatements, court orders, Missouri statutes, UTC materials, and current official tax instructions when needed, then returns source-backed answers with citations and conflict flags.

What can go wrong: if it mixes stale tax instructions, wrong-state law, or blog content with controlling authority, the whole stack starts from a bad premise.

Agent 2

Trust document interpretation agent

Plain English: the machine that reads the trust papers.

What it does: builds a clause map showing trustee powers, distribution standards, beneficiary classes, protector or director roles, tax-sensitive provisions, notice requirements, succession rules, and special consent rights.

What can go wrong: it misses an amendment, ignores a defined term, or treats ambiguous language as settled when counsel review is still needed.

Agent 3

Workflow and calendar agent

Plain English: the machine that runs the task list and the clock.

What it does: opens matters, assigns state, tracks deadlines, chases missing inputs, and routes the matter to the next step only when prerequisites are present.

What can go wrong: a reminder fires with no context, or a matter gets marked complete even though the trustee memo, approval, or supporting valuation is missing.

Agent 4

Trustee memo and decision-log agent

Plain English: the machine that drafts the written record.

What it does: turns facts, clauses, governing authority, options, and risks into a clean trustee memo, then converts the final approved result into a short decision log entry.

What can go wrong: the memo looks polished but contains unsupported conclusions, or it hides the fact that the hard judgment came from a human trustee.

Agent 5

Beneficiary communication draft agent

Plain English: the machine that prepares beneficiary-facing language.

What it does: drafts notices, responses, cover letters, report summaries, and plain-English explanations without changing the underlying legal position.

What can go wrong: it sends the wrong tone, includes material meant only for internal use, or drafts as though a discretionary request has already been approved.

Agent 6

Tax and filing reminder agent

Plain English: the machine that tracks filing duties and missing tax inputs.

What it does: monitors trust-level filing calendars, data dependencies, return-prep handoffs, and recurring reporting items such as Form 1041 packages and related state work.

What can go wrong: it mistakes a filing reminder for tax advice, or treats a date as final without checking current official instructions and the trust’s actual facts.

Agent 7

Quality-control and exception agent

Plain English: the machine that says stop.

What it does: checks for missing approvals, inconsistent beneficiary data, unsupported distributions, missing valuations, wrong document versions, and contradictions between the trust and the proposed action.

What can go wrong: if it is too weak, it misses real risk; if it is too noisy, people stop respecting its warnings.

Prompt pattern

Read-only role

Use only the provided trust documents, approved records, and listed authorities. Return citations, confidence, and unresolved conflicts. Do not create tasks, alter records, send communications, or recommend execution of an action without a human checkpoint.

Prompt pattern

Limited-write role

You may create draft artifacts or internal workflow entries only inside the assigned matter. Do not change the matter state, trigger outside communications, or overwrite existing records without an approval token.

Prompt pattern

Action-enabled role

You may execute only the specific action identified in the approval record. Before acting, verify the matter ID, approval ID, authority scope, target beneficiary or account, and current exception status. If anything is missing, stop.

Role class

Read-only agents

Legal retrieval, trust interpretation, and most quality-control work should start here. These agents may read, summarize, compare, and draft, but they should not change records or send anything outside the system.

Role class

Limited-write agents

Workflow and document assembly roles may create internal tasks, draft artifacts, and structured data packets. They still should not approve, pay, file, or decide the substance of a discretionary matter.

Role class

Action-enabled agents

Use these sparingly. An action-enabled role should exist only where the action is low-discretion, tightly scoped, reversible if needed, and supported by a logged approval token.

Human-only zone

What should stay human

Discretionary distributions, conflict questions, settlements, litigation calls, trust modifications, tax elections, asset sales with judgment content, related-party matters, and anything that feels materially non-routine should remain human-reviewed and usually human-approved.

Core system

System of record

The official trust file should hold trust versions, amendments, acceptance documents, tax IDs, asset data, beneficiary data, advisor contacts, reports, and final approved outputs. Agents should read from this system first.

Core system

Workflow engine

This is the traffic cop. It opens matters, assigns states, enforces prerequisites, records approvals, and blocks unauthorized jumps from draft to action.

Core system

Document store

This holds versioned documents, source packets, generated drafts, final signed copies, and comparison history. If the system cannot show which version it used, it is not ready for trustee work.

Core system

Identity and approval service

This controls who may review, approve, reject, or execute. Agents should never decide their own authority. They should receive authority from this layer, not invent it.

Always checkpoint

Approval checkpoints

• Discretionary distribution decisions
• Beneficiary notices that describe rights, denials, or sensitive facts
• Asset sales, concentration changes, or related-party transactions
• Tax return filing packages, elections, and extension decisions
• Any action taken under a protector, director, or other power-to-direct structure
• Trust modification, decanting, termination, or settlement steps

Always escalate

Escalation triggers

• Ambiguous or conflicting trust language
• Missing amendments, incomplete family data, or unclear beneficiary status
• Conflicts between the trust instrument and enacted state law
• Material tax consequences or uncertain filing treatment
• Missing valuation support or incomplete asset information
• Unusual distribution patterns, hardship claims, or family-conflict facts
• Any issue suggesting self-dealing, loyalty concerns, or authority mismatch

Architecture rule

Use approved templates

Trustee notices, report cover letters, decision memos, advisor requests, and routine administrative letters should come from approved templates, not blank-page generation.

Architecture rule

Use structured data fields

Names, trust titles, dates, tax ID fragments, beneficiary classes, asset descriptions, and approval IDs should be inserted from controlled fields wherever possible.

Architecture rule

Use source-backed narrative blocks

When the system explains a distribution standard, reporting right, or tax deadline, it should pull from an approved narrative block tied to a source packet, not improvise from memory.

Architecture rule

Version every final output

The final sent or signed document should carry a version stamp, matter ID, source packet link, and approval record so the office can later show exactly what was used.

Failure mode

One agent gets to do everything

The office treats one model as researcher, interpreter, drafter, reviewer, and operator. That removes the very separation that makes a fiduciary system defensible.

Failure mode

The wrong document version wins

The stack reads an old restatement, misses a later amendment, or fails to account for a court order. From that point forward, every clean-looking output is built on sand.

Failure mode

Best practice gets mislabeled as law

The output sounds authoritative, but it quietly turns office preference into a supposed legal requirement, or treats model-law UTC language as enacted Missouri text.

Failure mode

A draft becomes a live action

A beneficiary response, reminder, or report summary is generated for review, but the system is allowed to send it before the trustee or reviewer signs off.

Failure mode

The calendar runs without facts

The reminder engine knows a date but not the missing inputs, the responsible reviewer, or the related trust clause. The office gets noise instead of control.

Failure mode

The exception engine is ignored

Too many weak warnings train the office to click past real risk. In trustee operations, a stop signal only works if people believe it matters.

Failure mode

Directed authority is not modeled

The system assumes the acting trustee controls the decision, even though the trust gives a protector, advisor, or director the relevant power. That can distort both process and liability analysis.

Failure mode

The log is too thin to defend

Later, nobody can show what sources were used, who approved the step, what the unresolved issues were, or why the trustee took the action. That is operational weakness with legal consequences.