What expense tracking looks like when agents do the work.
My girlfriend and I used to track shared expenses in a Google Sheet. It sort of worked — but we both also have personal expenses, and sharing one sheet meant she could see all of mine. She ended up using a separate tool for hers. Two systems, no privacy, manual entry for both. We wanted one place where we could manage shared expenses together while still logging personal ones privately.
So I built a couples expense tracking app. Both partners log everything — personal and shared — but each can only see their own personal expenses plus the shared ones. No peeking at each other's personal spending. It solved the privacy problem.
But the core friction remained — every expense still required my attention. Open the app, pick a category, fill in the fields. I was determined not to miss any, which made it feel like a chore. The obvious next step was to add AI features to the app — smart categorization, receipt scanning, the things everyone's building right now. I started down that path — but it meant managing API keys, maintaining another integration layer, all to make the app slightly smarter. The cost didn't match the gain. Then I realized: why add AI to the app when the AI agent is already sitting right there?
I say "lunch $12" to my coding agent. It parses the description, matches the category from my history, infers the date and type, and confirms before writing. A few seconds, and I don't leave my terminal.
This wasn't just a better input method — it removed tool switching entirely. I'm already working in my terminal. The agent is already there. Logging an expense became part of my existing workflow instead of an interruption.
The system behind it is three pieces:
No custom backend. No API layer. The schema is the product — constraints, types, and access rules do the work that application code normally would.
Easier logging was the first win. But the real payoff came from what I'd actually built — not just a better interface, but a foundation. A database schema connected to agents through MCP. Once that exists, plugging in new data sources is cheap.
Getting your own transaction data programmatically — from banks, transit cards, government e-invoice systems — isn't something a single builder can easily access. Those integrations are built for companies, not individuals. But I can teach an agent to navigate the same web portals I'd use manually, fetch my transactions, cross-reference them against what's already logged, and surface the gaps — unmatched invoices, missing entries, amount mismatches. I review what the agent flags and decide what to do with each one.
These ingestion skills are separate from the expense tracking skill, but they all connect to the same schema. My email triage agent already extracts bank transactions from PDF statements — routing them into the expense schema is just one more downstream call. The hard part was the foundation — extending it is easy. The pieces are there to make this fully automatic — it's a conversation away from running on a schedule.
Most of my expenses now log themselves. The agent handles the tedious parts — parsing, categorizing, ingesting payment data, reconciling against what's already tracked. I handle the judgment calls — confirming, querying, deciding what to investigate.
Because agents can reason about the data, new capabilities just appear. Which categories are growing? What does spending look like week over week? Are there days I forgot to log? I don't build dashboards for these — I just ask, and the agent queries and answers.
The system grows the same way. When I wanted to track income or payment methods, the agent suggested the schema changes, ran the migration, and I added a small skill to handle the new workflow. What would normally be a feature release is just a conversation.
The database is the product. Both the agent and the app are just views into the same schema. When I tightened the privacy rules in the database, both interfaces picked it up automatically — no app update, no skill rewrite.
The right interface depends on context. At my desk, the agent is faster. On the go, the app still wins. They coexist. "AI replaces apps" is a better headline than it is a reality.
System design > application code. The skill file is about 200 lines. The schema is about 170 lines. Together, they replace what would normally be a full backend. The intelligence lives in the structure, not in code.
The skill file is the API layer. It defines what agents can insert, what to confirm first, what to query before writing. The database enforces hard constraints — types, access rules, foreign keys. The skill enforces soft ones — workflow, categories, confirmation. Agents can still get it wrong, and for a personal system that's a low-stakes correction. For a product with real users, some of those soft constraints would need to become hard ones. But the pattern is worth testing at this scale first.
Once the foundation exists, capabilities compound. I started with logging. Then querying. Then automated ingestion. Then analysis. Each new capability was easy because the schema and agent connection were already there.
The system is open source. The repo contains the schema, the skill file, and a setup guide. It works with any AI coding agent that can connect to Supabase — plug it in, run the setup, and you have couples expense tracking in your terminal.