Trusted Agents
Up until now, Brian has been a memory and substrate layer. Documents and data flow in from your connected systems, get classified, semantically tagged, and made queryable. Useful, but mostly invisible. The value compounds quietly in the background.
This week that changed. The substrate became the foundation for something I've wanted to build for a long time: trusted agents that actually do the work.
The first one is an AP agent. It works like this. An invoice arrives via Gmail, drag-and-drop, Drive, however. The substrate ingests it, classifies it, extracts what matters. The AP agent picks it up, drafts the invoice in Xero, then asks for your approval through Brian's UI.
The approval drawer shows the bill, renders the PDF, lets you approve and remember the coding pattern, reject, or add notes.
When you approve, the agent posts to Xero, attaches the PDF, writes your notes to the invoice, and adds an audit trail entry to the Xero history saying it was posted by Brian agent with the agent ID. Then it gives you a link back to the agent in Brian's web UI showing the completed task with full lineage of what happened.
Two and a half hours to build, end to end.
The second agent is a finance report agent. Built this morning in fifteen minutes. It pulls reports from Xero (chart of accounts, aged debtors, aged creditors, P&L, balance sheet, anything Xero exposes via API), runs them through classification, and stores them in the substrate alongside everything else.
Which means every other agent now has historical context. The AP agent gets sharper because it knows your supplier spending patterns over time. The AR agent I'm building next gets context on customer payment behaviour before it sends its first email.
This is the compounding the substrate was always meant to enable. Every agent I author makes every other agent better, because they all share the same understanding of the business.
The reason this works, and the reason I keep using the word "trusted", is that every action is auditable end-to-end. Raw payload preserved as immutable bytes. Every interpretation versioned. Every decision tied to the data and policy that informed it. When Brian's agent posts an invoice to Xero, you can trace exactly what it saw, what it concluded, and what it did. That's the trust posture finance teams need before they'll let an agent touch their books, and it's baked into the architecture rather than bolted on.
AR agent is next. Then collections, customer behaviour analysis, board reporting. Beyond finance, the same pattern applies to any operations work that's recurring, structured, and follows known patterns.
Which is where I want to ask: what would you want an agent to do for you?
Specific use cases, not abstract ones. The actual recurring work that lands on your desk every week that you'd rather hand off. The reports nobody reads but somebody has to write. The reconciliation you do every month-end. The follow-ups you keep meaning to send. The data pulls that take an hour every Friday.
Drop use cases into Claude and ask it to submit a support ticket. The next agents I build are the ones people actually want.
