Personal AI Assistants for Life Admin

I've written about building AI agents for client work — design specs, web development, email marketing. But the same architecture works just as well for the other kind of work: the life admin that eats your evenings and weekends.

Hiring someone. Managing a rental property. Tracking expenses. Filing paperwork. These aren't creative problems. They're operational ones. And operational problems are exactly what agents are good at.

I built two personal assistants using the same MCP + Claude Code pattern that powers my business agents. Here's how they work and why the architecture is portable across any domain.

The Shared Pattern

Both agents follow the same three-layer architecture. This isn't accidental. It's the same pattern I use for every MCP server I build, regardless of what it does.

  Claude Code (AI Layer)
       |
  MCP Server (Tool Interface)
       |
  Business Logic (Domain Rules + Validation)
       |
  Data Store (JSON) + Compliance Refs + Templates

The AI layer handles natural language interaction and decision support. The MCP server exposes domain-specific tools that Claude can call. The business logic layer enforces rules and validates data. The data store persists everything locally as JSON files, with compliance references and document templates sitting alongside.

Swap the domain modules — the business logic, the data schemas, the compliance references — and you have a completely different assistant. The infrastructure is identical.

Household Employment Agent

Hiring a household employee is surprisingly complex. It's not just "find someone good." There are state-specific employment laws, tax withholding obligations, contract requirements, background check protocols, and compensation calculations that vary by region.

Most people figure this out through a combination of Google searches, forum posts, and expensive mistakes. I built an agent that knows the rules upfront and enforces them throughout the process.

Phase-Based Development

The agent is built in two phases that mirror the employment lifecycle:

Phase 1: Hiring. This is the active phase. The agent manages a structured hiring checklist, tracks candidates through the interview pipeline, and runs compensation calculations. Each checklist item links to the relevant legal requirement — not a blog post, but the actual state employment law source. The agent doesn't give advice. It gives citations.

The candidate tracking system is a full CRUD interface exposed through MCP tools: add a candidate, update their status, log interview notes, compare compensation packages. Every interaction is a tool call that Claude can invoke naturally in conversation.

Phase 2: Operations. Once someone is hired, the toolset shifts. Daily care logs, schedule management, payroll calculations, and ongoing compliance tracking. This phase is designed to support the long-term employment relationship — not just the search.

Compliance as Code

This is the design decision that matters most. Employment law isn't stored as prose in a reference document that the AI might or might not remember to check. It's structured data: checklist items with requirement descriptions, legal citations, completion status, and direct links to official sources.

When the agent creates a new hiring checklist, every item is pre-populated from the compliance schema for the relevant state. Items can't be deleted — only marked complete. The agent tracks what's done and what's outstanding, and it surfaces incomplete requirements before the process can move to the next phase.

This is a pattern I think about a lot: encode the rules in the data layer, not the prompt. Prompts are suggestions. Data schemas are constraints. When legal compliance matters, you want constraints.

Template System

The agent ships with templates for employment contracts, legal compliance checklists, and compensation worksheets. These aren't AI-generated on the fly. They're pre-built documents based on actual legal requirements, designed to be filled in with specific values and handed to a real human (or a real lawyer) for review.

The AI's job is to populate them with the right data, not to invent legal language. There's a meaningful difference.

Property Management Agent

Managing rental property involves a different set of operations but the same architectural needs: tracking entities, enforcing rules, generating documents, and producing financial reports.

14 Tools Across 5 Domains

The property management MCP server exposes 14 tools organized into five domains:

• Property: Dashboard overview and property details — unit configurations, addresses, key dates
• Tenants: Add, update, get, and list tenants with full contact and lease association tracking
• Leases: Create and manage lease records with state-specific validation rules baked in
• Contractors: Maintain a directory of service providers with contact info, specialties, and spending history
• Financials: Log transactions, generate reports, and track expense categories

Each domain has its own business logic module. Tenants reference leases by ID. Transactions reference tenants or contractors by ID. Reports aggregate across all domains. The data model is linked, not siloed.

State Law Integration

When the agent creates a lease, it validates against state-specific rules embedded in the business logic layer. Security deposit maximums, required notice periods, move-in checklist deadlines, prohibited lease clauses — these are all enforced at the tool level, not at the prompt level.

If you try to set a security deposit that exceeds the state maximum, the tool rejects it. If you create a lease without the required disclosures, the agent flags what's missing. The compliance logic runs before the data is saved, not after.

This is the same "compliance as code" pattern from the household employment agent. The domain changes. The principle doesn't.

Financial Intelligence

The financial module does more than log numbers. Transactions auto-categorize based on type and description. Contractor spending is tracked against 1099 reporting thresholds — once a contractor crosses $600 in a calendar year, the system flags it for tax reporting. Reports map directly to IRS Schedule E line items, so year-end tax preparation is a query, not a manual reconciliation project.

Every transaction links back to the tenant or contractor it relates to. This means you can pull a financial summary for a specific unit, a specific tenant, or a specific contractor without manually filtering spreadsheet rows. Cross-domain reporting is built into the data model.

Architectural Principles

After building both agents (and the business agents before them), a few principles have solidified:

Separation of concerns. The MCP layer handles tool exposure. The business logic layer handles rules and validation. The data layer handles persistence. Claude handles natural language and decision support. No layer does another layer's job. This makes each layer independently testable and replaceable.

Schema-first data. Every entity — tenants, leases, candidates, transactions — has a defined schema with required fields, types, and validation rules. The AI can create and modify records, but only within the schema's constraints. This prevents the kind of data drift that happens when an AI writes free-form JSON with no guardrails.

Compliance as code, not prose. Legal requirements are structured data with citations, not paragraphs in a system prompt. The agent can reference them, check against them, and surface gaps — but it can't accidentally ignore them because they're enforced at the business logic layer.

Human-readable output. Every template, report, and document the agent produces is designed to be handed to a human. A lawyer reviews the contract. An accountant reviews the financials. The agent does the prep work. The human makes the decisions.

The Takeaway

The MCP pattern is portable. The three-layer architecture — tool interface, business logic, data persistence — works for email marketing, web development, household employment, property management, or anything else with definable workflows and structured data.

If you can describe the entities, define the rules, and list the operations, you can build an agent for it. The domain changes. The architecture doesn't.

I keep building these because the return on investment is immediate and compounding. Every hiring checklist the agent manages is time I'm not spending on Google. Every financial report it generates is an evening I'm not spending in a spreadsheet. Every lease it validates is a legal mistake I'm not making.

The business agents make me money. The personal agents give me time. Same architecture. Same tools. Different domain modules.

That's the whole trick.