On this work trip, I’m tracking meal expenses by chatting with an agent from an elevator.
That sounds more ridiculous than it is.
I have used a spreadsheet for this kind of thing before: one section for expenses, another for the meal budget, another for the number of meals left, and formulas to tell me how much I can spend per meal for the rest of the trip.
Yes, I know I could just keep receipts and reconcile everything later through Ramp. That would probably be enough.
But I do not only want to know whether an expense is reimbursable after the trip. I want to know, while I am deciding where to eat, how much I can still spend without making the last two days of the trip unnecessarily cheap.
That is what the spreadsheet was for.
The useful question is not, “What have I spent?”
It is, “What can I still spend per meal?”
A receipt pile answers the first question later. A spreadsheet can answer the second question now, but only after I open it, find the right row, add the expense, mark whether the receipt has been submitted, and make sure I did not type into the wrong column.
None of that is difficult. It is just a surprisingly high amount of friction for buying lunch.
So I built a small trip-expense tracker with a conversational front door. I can say something like:
I spent $18.42 on dinner. Receipt submitted.
Then ask:
What do I have left per meal?
The agent is not keeping a private spreadsheet for me, and it is not writing an expense list into a Markdown note or a loose JSON file somewhere. The ledger lives in Swamp’s data store, owned by a trip-tracker model instance.
That distinction is the point of the project. The model stores the trip configuration, an append-only expense ledger, receipt and reimbursement-status changes, and generated dashboard or archive records as structured, versioned data artifacts. Each trip has its own data boundary. The conversation is only the front door; it is not the database.
The model methods are the part that makes that safe to use conversationally. One method configures the trip rules. Another records an expense. Another marks a receipt or reimbursement status. Read methods build the ledger and dashboard from the stored records. An archive method can produce a final record once the trip is done.
That is different from using Grist as the source of truth, and different from asking an agent to remember what I said last Tuesday. Grist would be a useful interface if I wanted a grid and manually editable database. A spreadsheet would be a useful interface if I wanted formulas in cells. But neither needs to own the accounting rules here.
Swamp owns the durable data and the deterministic math. Hermes translates normal language into a call to the model, then translates the result back into an answer I can use. If I later want a table, a CSV export, or a different interface, those can all read the same ledger instead of becoming separate little systems that disagree with one another.
The tracker keeps the actual accounting rules underneath the conversation. Food reduces the meal budget. Rideshares, baggage fees, and airport parking can still be tracked for reimbursement, but they do not quietly eat into the food budget. A company-provided lunch can show up in the trip plan without pretending I spent money on it.
A spreadsheet can do all of this, obviously. But spreadsheets are good at making the structure visible, not necessarily at making the updates convenient.
Here’s what actually changed: I did not eliminate the ledger. I stopped being the person responsible for manually operating it.
The ledger still exists. The budget still has deterministic math behind it. I can still inspect the expenses, see which receipts need attention, export the trip later, and keep the reimbursement record separate from the meal-budget question.
But the interaction became closer to how I was already thinking about it.
“I just bought coffee.”
“Did I submit that receipt?”
“How much do I have left today?”
That is a better interface for a person moving through airports, hotels, conference halls, and elevators than several columns with frozen header rows.
“But wait,” someone could reasonably say, “isn’t this an absurd amount of infrastructure for tracking a few meals?”
Probably.
I could use Ramp later. I could keep every receipt in a folder. I could open a spreadsheet once each evening. All of those are fine options, and I am not trying to turn a normal work expense into a grand software project.
The point is smaller: a little deterministic automation can make a system useful at the moment a decision is being made, rather than merely accurate when the work is over.
I still like spreadsheets. They are one of the clearest ways to see a small system working.
But on a work trip, I would rather ask, “Can I afford the better sandwich?” than manage four columns before I get back to the elevator.