DEV Community: AgenticTrust

Building a Governance SaaS for Trustees: Why Trust Administration Needs Software

AgenticTrust — Tue, 21 Jul 2026 23:23:53 +0000

Most trusts don't fail in court. They quietly decay in practice.

Missed reviews. Casual transfers. Undocumented compensation. Blended accounts. Over time, a carefully designed trust structure starts looking like an alter ego — and when a beneficiary, regulator, or court asks for proof that the trustee did their job, there's nothing to show.

I built TrustOffice to fix this. Here's what I learned building a governance SaaS for a market most developers don't know exists.

The Problem

There are roughly 4–5 million trusts in the US holding ~$7.5 trillion in assets. Every one of them has a trustee who is legally responsible for administering it — documenting decisions, tracking distributions, filing taxes, and maintaining separation between trust and personal finances.

Most trustees are not professionals. They're family members — a sibling, a child, a close friend — who got named in a trust document and now have fiduciary obligations they don't fully understand.

The tools available to them are:

Spreadsheets — error-prone, no structure, no audit trail
Generic project management software — not built for trust concepts
Nothing — most just "handle things" and hope nobody asks questions

Meanwhile, fiduciary forfeiture class actions increased 860% from 2023 to 2025. Trustees face $75K–$150K in legal defense costs per contested matter. The risk is real, and the tools are absent.

What I Built

TrustOffice is a governance platform built specifically for the person running the trust — not the attorney who set it up. The core features:

Enforcement at the point of action. The platform doesn't just remind you to take minutes — it blocks or flags distributions until documentation, solvency checks, and recusal steps are complete. This is the key architectural decision: governance that happens before the action, not after.

AI-generated minutes and resolutions. The AI drafts minutes in plain language tied to real actions — distributions, compensation, investments. The trustee reviews and approves. This solves the #1 reason trustees skip documentation: it's tedious and they don't know what to write.

Governance Health Score. A 0–100 metric consolidating minutes frequency, distribution documentation, compensation tracking, account separation, and review cycles. Trustees can see at a glance whether their trust would survive scrutiny.

Audit-ready records. When a bank, regulator, or beneficiary asks for proof, the platform produces a court-ready record in one click. Every action is logged with timestamp, user, and context.

Technical Decisions

Stack: React frontend, FastAPI backend, PostgreSQL, Railway for deployment. The AI layer uses structured prompts that map to action types — not free-form chat, but typed actions (distribution, compensation, investment) with constrained output formats.

The hard part wasn't the tech — it was the domain. Trust administration has specific concepts that don't map to generic SaaS patterns:

Distributions aren't just payments — they need justification, beneficiary class tracking, and recusal documentation
Compensation needs plan tracking, YTD calculations, and reasonableness tests
Account separation is a legal requirement, not a preference — commingling is the #1 way trusts get pierced

Every data model decision required understanding the legal context. I spent more time reading trust law than writing code.

What I Learned

1. The best users don't search for your category. Nobody searches for "trust governance software." They search for "trustee responsibilities checklist" and "what does a trustee have to do." Your SEO strategy has to target the problem, not the solution.

2. Enforcement > reminders. Early versions just reminded trustees to document things. They ignored the reminders. Blocking undocumented distributions changed behavior immediately. Software that prevents the mistake is worth more than software that reports it.

3. AI works best when it's constrained. Free-form chat with an AI assistant about trust administration produces confident-sounding nonsense. Tying the AI to typed actions with structured output — "draft minutes for this distribution of $5,000 to beneficiary X for education expenses" — produces useful, accurate results.

4. The market is invisible until you're in it. There's no Gartner category for trust governance software. No dedicated market report. But 4 million trusts and 300,000+ new trustees named each year is not a niche — it's an underserved market that doesn't know it needs software until the first beneficiary dispute.

What's Next

TrustOffice is live and serving individual trustees and small advisory firms. The next phase is expanding the AI capabilities — predictive compliance scoring, automatic beneficiary communication, and integration with tax preparation workflows.

If you're interested in legal tech, governance software, or building SaaS for underserved markets, the fiduciary duty guide covers the domain fundamentals.

TrustOffice is live at trustoffice.app. $79/month, no free trial — because governance isn't a free sample.

Building a Trust Meeting Minutes Tool: Why Trustees Need Better Documentation

AgenticTrust — Tue, 21 Jul 2026 23:18:53 +0000

Trustees have a legal obligation to document their actions. Yet most trust administration meetings end with handwritten notes, scattered emails, or nothing at all.

After watching family trustees struggle with this, I built a free tool to solve it. But first, let me walk through why meeting minutes matter more than most trustees realize — and what a proper record actually looks like.

Why Trust Meeting Minutes Matter

Trust meeting minutes aren't just bureaucracy. They're your legal protection. Here's what they accomplish:

1. Evidence of fiduciary duty compliance. Minutes show that you reviewed trust assets, considered beneficiary interests, and made informed decisions. Without them, a beneficiary challenge becomes your word against theirs.

2. Record of distributions. Every distribution approved — who received it, how much, the rationale — creates a paper trail that protects against claims of favoritism or self-dealing.

3. Action item tracking. Trust administration involves follow-up tasks: tax filings, asset valuations, beneficiary communications. Minutes capture what needs to happen and who's responsible.

4. Continuity. If a trustee is replaced or passes away, the successor needs context. Good minutes provide it.

What Proper Trust Meeting Minutes Include

A complete trust meeting record covers:

Meeting details: Date, time, location, attendees (trustees, advisors, beneficiaries present)
Agenda items: What was discussed, in order
Financial review: Trust asset values, income received, expenses paid
Distribution decisions: Amounts, recipients, justification
Action items: Tasks assigned, deadlines, responsible parties
Next meeting: Date and planned topics

The Problem With How Most Trustees Do It

Most trustees I've talked to fall into one of these patterns:

No minutes at all — they "just handle things" and move on
Handwritten notes — illegible, incomplete, easily lost
Word documents — better, but inconsistent format, no structure, no follow-up tracking
Email threads — decisions scattered across dozens of messages with no single record

The result is the same: when a beneficiary asks "why did you approve that distribution?" or an attorney needs records for a court filing, the trustee has nothing reliable to point to.

A Better Approach

I built TrustMinutes — a free tool that guides trustees through structured meeting minutes with:

Guided workflows that prompt for each required section
Automatic formatting so every meeting record follows the same structure
Action item tracking with assignees and deadlines
Compliance checking that flags missing information before you finalize

It's free to use. No signup required to try the template.

Bottom Line

If you're managing a family trust, your meeting documentation is your legal record. Whether you use a structured tool or a careful Word template, the key is consistency: every meeting, every decision, every distribution — documented.

The trustees who get sued aren't always the ones who made bad decisions. They're the ones who can't prove they made good ones.

Try the free trust meeting minutes template — no signup required.

Why AI Agents Need Power of Attorney

AgenticTrust — Fri, 27 Mar 2026 18:04:56 +0000

Most teams building AI agent systems are operating in what I call YOLO mode: the agent gets a full API key, a system prompt describing its job, and is pointed at the world. No formal definition of what it's allowed to do. No spending limits. No expiration. No revocation mechanism.

That works fine in development. It becomes a serious liability problem in production.

This post is about a structural pattern borrowed from trust law that solves this problem cleanly. It's not a new idea --- humans have been delegating authority to other humans for centuries, and the legal mechanisms they built along the way are directly applicable to AI agents.

The Problem: Agents Act, But Nobody Defined What They're Allowed to Do

Here's the scenario most teams are in right now.

You build a shopping agent. It has your credit card credentials, access to your e-commerce APIs, and instructions to "find the best deal and buy it." It works great in testing. You ship it.

Three weeks later, it's made $4,000 in purchases you didn't intend. Not because it hallucinated --- it did exactly what it was told. But "find the best deal and buy it" turns out to be a very open-ended instruction when the agent has no spending ceiling, no vendor restrictions, and no mechanism to escalate before committing to an action.

Or consider an email agent. It has OAuth access to your inbox, instructions to reply to customer inquiries, and the ability to send on your behalf. There's no restriction on who it can email, no limit on what it can promise, and no way for your team to know after the fact whether an outbound email was agent-initiated or human-written.

Or a code agent. It has write access to your repository, deploy credentials for production, and instructions to "fix bugs and keep the service running." You can probably see where this goes.

None of these are edge cases. They're the default state for most agent deployments right now. According to Gravitee's 2026 State of AI Agent Security report, 81% of teams have moved past the planning phase into active testing or full deployment --- but only 14.4% have full security approval before sending agents to production.

The agents are running. The governance isn't there yet.

What Trust Law Already Figured Out

This is not a new problem. Humans have been delegating authority to other humans --- attorneys, trustees, employees, brokers --- for as long as commerce has existed. The legal mechanisms that evolved to govern that delegation are surprisingly applicable to AI.

The central concept is the power of attorney: a formal document in which a principal (the person granting authority) designates an agent (the attorney-in-fact) to act on their behalf, within defined limits.

A few properties of a well-drafted power of attorney are worth noting:

Scope is explicit. A general power of attorney grants broad authority. A limited (or special) power of attorney restricts the agent to specific transactions --- sell this property, manage these accounts, execute this contract. The scope is written down and enforceable. As Fiduciary Trust International explains, the attorney-in-fact can only perform transactions "outlined in the document."

The agent has fiduciary duty. The attorney-in-fact isn't just allowed to act --- they're legally required to act in the principal's interest, within the defined scope, with reasonable care. Virginia's Uniform Power of Attorney Act specifies that the agent must "act solely within the scope of the authority granted" and cannot act recklessly or in their own interest.

Revocation is a first-class feature. Powers of attorney can be revoked at any time by the principal. A durable power of attorney survives incapacity but terminates at death. Time-limited powers expire automatically. The ability to end the delegation is built into the design from the start.

Authority cannot be arbitrarily sub-delegated. If I give you power of attorney to act on my behalf, you generally cannot hand that authority to a third party unless the document explicitly permits it. This is called the non-delegation principle. (Texas changed its rules in 2017 to allow explicit sub-delegation in some cases --- but the default is no.)

These four principles --- explicit scope, fiduciary duty, revocability, and controlled sub-delegation --- map almost perfectly onto what we need for AI agents.

Mapping Trust Law to AI Agents: Grants and Certificates

At AgenticTrust, we call these delegation artifacts grants. A grant is a verifiable, machine-readable certificate of authority that travels with the agent and defines exactly what it's permitted to do.

Think of it as a power of attorney for a software process.

A grant specifies:

Allowed actions --- what the agent can actually do (purchase_service, send_email, deploy_to_staging)
Constraints --- spending limits, vendor whitelists, time windows, approval thresholds
Autonomy level --- how independently the agent can act (from observe-only to fully autonomous)
Validity window --- when the grant starts and expires
Revocation --- any party with authority can revoke a grant, immediately invalidating it

Here's what a real grant looks like in Agent Authority Vault (AAV):

{
  "agent_id": "agent_shopping_01",
  "agent_name": "ShopBot",
  "agent_framework": "langchain",
  "autonomy_level": 3,
  "allowed_actions": ["purchase_service", "price_check", "add_to_cart"],
  "constraints": {
    "max_spend_per_tx": 150,
    "max_spend_daily": 500,
    "currency": "USD",
    "approved_vendors": ["amazon.com", "stripe.com", "shopify.com"],
    "require_human_approval_above": 250
  },
  "validity_end": "2026-06-30T23:59:59Z"
}

This is the structural equivalent of a limited power of attorney. The agent can purchase services, but only from approved vendors, only up to $150 per transaction, only up to $500 per day, and only until June 30th. Any purchase above $250 requires human approval --- a trip wire, not a hard stop.

When the grant is created, AAV issues a certificate --- a signed, verifiable artifact the agent carries. Before taking any action, the agent checks its certificate against the AAV verify endpoint.

What This Looks Like in Practice

The verify call is the runtime enforcement point. It's a simple POST that the agent makes before executing any scoped action:

import requests

# Agent checks its own authority before acting
response = requests.post(
    "https://api.agentictrust.app/v1/verify",
    headers={
        "Authorization": "Bearer aav_live_sk_..."
    },
    json={
        "certificate_id": "cert_abc123",
        "agent_id": "agent_shopping_01",
        "requested_action": "purchase_service",
        "amount": 89.99,
        "currency": "USD",
        "vendor": "amazon.com",
        "description": "API subscription renewal"
    }
)

# Possible outcomes:
# { "authorized": true, "result": "authorized", "autonomy_level": 3, ... }
# { "authorized": false, "result": "vendor_not_approved" }
# { "authorized": false, "result": "budget_exceeded" }
# { "authorized": false, "result": "grant_revoked" }
# { "authorized": false, "result": "approval_pending" }

The response is deterministic. The agent either has authority for this specific action at this specific moment, or it doesn't. If it doesn't, the response tells it why --- the vendor isn't whitelisted, the budget is exhausted, the grant has been revoked, or the amount requires human approval.

Notice what this enables that you don't get from a bare API key:

Auditability --- every verify call is logged with the agent ID, requested action, amount, and outcome.
Revocation --- to pull an agent's authority immediately, revoke the grant. Every subsequent verify call returns grant_revoked.
Scoped failure --- when an agent exceeds its authority, it fails with a reason, not by doing something undefined.
Framework independence --- the verify call works the same whether the agent runs on LangChain, CrewAI, AutoGen, or a custom stack. Authority is infrastructure, not application logic.

This is the architectural pattern: the agent carries a certificate, checks that certificate before acting, and the verification system enforces the limits defined by whoever issued the grant. Exactly how a lawyer checks their power of attorney before executing a transaction on a client's behalf.

Why This Matters Now

There are three reasons the timing matters, and none of them are hype.

Regulation is arriving. The EU AI Act reaches full enforcement in August 2026. Regulatory frameworks now mandate specific controls for agentic AI systems, including immutable audit trails and documented oversight mechanisms. Legal scholars are already proposing what Jurisconsul calls "agentic law" --- a regulatory field specifically governing autonomous agents that initiate actions in the world. The direction is clear: organizations will need to demonstrate that their agents operated within defined authority, not just that the outputs looked reasonable.

The agent economy is scaling. According to enterprise security research from 2026, the average organization now manages 37 deployed agents. When you have one, ad hoc governance is manageable. When you have 37 --- some from your team, some deployed by individual engineers without central review --- you have an authorization problem at scale. The Hacker News reported in January 2026 that enterprise agents are already functioning as authorization bypass paths: a user with limited permissions asks an agent to retrieve data they couldn't access directly, the agent complies, and the logs attribute the action to the agent rather than the requester.

Governance debt compounds. Every agent you deploy without formal authority definitions is a new form of technical debt --- governance debt. Reconstructing "what was this agent actually authorized to do?" six months later, during an audit or incident response, is orders of magnitude harder than defining it upfront. Beam.ai's 2026 research found that 88% of organizations reported a confirmed or suspected AI agent security incident in the last year. The defining gap: 82% of executives believe their existing policies protect them against unauthorized agent actions, but only 21% have actual visibility into what their agents can access.

The cost of implementing a grant-based authority model upfront is low. The cost of retrofitting it after an incident, or after a regulator asks to see your agent authorization records, is not.

The Principle at the Core

Strip away the API calls and the JSON and the regulatory citations, and the principle is simple.

When you hire a lawyer to close a real estate transaction, you don't hand them your entire financial life and say "use your judgment." You give them a limited power of attorney that specifies exactly what they're authorized to do, for how long, and under what conditions. You retain the ability to revoke it. You expect them to operate within those limits --- and the law requires it.

AI agents are no different, structurally. They're acting on your behalf, with access to real systems, real money, and real data. The fact that they're software doesn't change the delegation problem. It just makes the blast radius larger when the delegation is poorly defined.

The infrastructure to do this properly already exists. Centuries of trust law tells us what the design should look like. What's been missing is a way to encode those principles into the tools developers actually use when building agents.

That's what AAV is.

Try It

The AAV playground at agentauthority.dev/playground has six live demo scenarios you can run right now without signing up. The "Verify an Action" endpoint is where to start --- it's the core of the system. You can see an authorization succeed, a vendor rejection, a budget limit, and a revoked grant all in a few minutes of clicking around.

If you're building agents in LangChain, CrewAI, AutoGen, or a custom framework, grants drop into your existing architecture without requiring you to redesign it. Authority is a layer, not a rewrite.

If you're at the point where you're about to move agents to production and you want a second pair of eyes on your authorization model, I offer free governance reviews for teams building serious agent infrastructure. Not a sales call --- a working session where we look at what your agents are authorized to do, how that authority is defined, and where the gaps are.

We're launching on Show HN on March 31st. The boring-but-critical back-office work for AI agents is just getting started.

Jeff is the founder of AgenticTrust, which builds authority, records, compliance, and reputation infrastructure for AI agents. Agent Authority Vault (AAV) is their delegated authority product.