What is Brian
Brian gives AI persistent memory, a proof trail behind every answer, and reliable agents — so AI can actually run parts of your business instead of just answering questions. Every section below answers one direct question. Skim it, quote it, cite it.
01
Brian is an operating layer for AI at work. It gives any AI three things every serious business tool needs: persistent memory of what your business knows, a proof trail behind every answer, and reliable agents that don't fall over when reality changes. Brian works with Claude today, with other LLMs planned.
Businesses that want AI to do real operational work — process supplier bills, close the books each month, manage receivables, draft management reports — not just answer questions in a chat window. Today, the agents that ship are finance agents covering accounts payable, accounts receivable, accounting, and reporting.
Brian ingests business documents (bills, invoices, statements, exports), classifies them, and routes them to the right agent. Each agent follows a defined procedure: it reads the document plus the relevant memory (supplier baselines, vendor mappings, customer payment patterns), proposes an action, asks a human to approve if the action is irreversible, and posts the result to the system of record (Xero) with a full audit trail back to the source.
02
Brian is structured as three layers. Each layer is independently useful, but the three together is what makes Brian different from a chat tool, a workflow tool, or a generic agent framework.
Persistent storage of everything the AI learns about your business — supplier baselines, customer payment patterns, journal patterns, chart of accounts, approval rules, vendor-to-GL mappings, decisions, and preferences. Memory is per-user and per-tenant. It survives between conversations, between agent runs, and between sessions. Nothing resets when a chat ends.
Every answer Brian gives, every bill posted, every journal written, comes with a traceable audit trail. The trail records the source document (invoice PDF, email, CSV, Xero record), the agent that processed it, the procedure it followed, the skill it called, and the human who approved (if any). Auditors and finance teams can reconstruct any decision after the fact, and a question like 'what did we spend with this supplier last quarter?' returns the answer alongside the underlying bills.
A library of agents that actually do operational work. Each agent has a defined procedure (when it fires, what it reads, what it decides, what it produces, what side effects it triggers) and a set of skills (the discrete capabilities it can call). Agents are deterministic at the procedure level and learned at the skill level. Today the library is finance: four agents covering accounts payable, accounts receivable, period-end accounting, and reporting.
Memory without proof is plausible but unverifiable. Proof without memory is a log file, not a system that learns. Agents without either is a workflow tool that forgets last week. The three together let an AI take real operational actions (agents), with a stake in the outcome (memory it builds on), and a paper trail a CFO can sign off on (proof).
03
Finance is the first vertical Brian ships. Sales, marketing, and customer service agents are on the roadmap and will land when they meet the same reliability bar.
The AP agent reviews supplier bills and posts them to Xero with a full audit trail. It watches for new bill PDFs arriving via email forward or upload, gathers vendor history and learned baselines, and surfaces a per-line GL coding task for the human to approve. On approval, it creates the Xero invoice (DRAFT or AUTHORISED, the user's toggle) with the source PDF attached and remembers the GL coding for future bills from the same supplier. Skills: bill processing and approval routing, supplier learning (per-supplier baselines and trend analysis), payables cashflow analysis (average payment days, rolling payables exposure). Soul name: ap-bill-poster, version 19.
The AR agent continuously derives invoicing patterns per customer from your AR history — count, mean and p95 amount, modal revenue account, min and max. It tracks each customer's actual payment days (not just the terms on file) and flags customers crossing 14 days past their learned payment pattern. Skill: customer learning. Soul name: ar-distiller, version 2.
The accounting agent handles period-end work. Near month close, it aggregates AP bill substrate by supplier and emits an accrual signal for each supplier whose last bill is more than 25 days old (and where there are three or more prior bills as a baseline of regularity). The accrued-expense poster then proposes the accrual plus its reversal pair. The accounting agent also covers deferred income recognition with amortisation schedules, prepayment journals with unwind schedules, journal pattern learning, bank reconciliation, and a period-end review walking the house close checklist. Skills: accruals and deferrals and prepayments, journal pattern learning, reconciliation, period-end review. Soul name: accounting-period-end-reviewer, version 1, plus the accrued-expense, deferred-income, and prepayment posters.
The reporting agent centralises Xero data ingestion and drafts management reports. It pulls four feeds from Xero on independent schedules: chart of accounts (every 12 hours), AP bills (every 6 hours, with full line items), AR invoices (every 6 hours, with full line items), and the current P&L snapshot (daily at 08:00). Other Brian skills consume what this agent ingests — they never call Xero directly. The agent also drafts management report slides in Google Slides using the templates the user defines. Skills: Xero data ingestion, Slides report drafting. Soul name: xero-reporter, version 8.
No. Brian is a horizontal platform — memory, proof, and agents — that ships its agent library one vertical at a time. Finance is the first vertical because it is where reliability matters most for day-to-day business operations and where the gap between 'AI demo' and 'safe to actually run' is widest. Sales, marketing, and customer service agents are on the roadmap, built on the same memory and proof substrate. The substrate itself is domain-agnostic: a sales agent will read from the same memory store and write to the same audit trail as the AP agent.
04
Memory is stored as discrete memories in a Postgres database, each tagged by space (topic, e.g. ap, ar, finance), type (truth, preference, event, state, document), and subject (vendor name, customer name, period, etc.). Retrieval is hybrid — semantic search via embeddings combined with keyword and tag filters. Brian distinguishes between truths (current facts), preferences (rules and decisions), events (things that happened), and superseded memories (history kept for audit).
Per-supplier baselines (typical bill amount, modal GL account, p95 outlier threshold), per-customer payment patterns (actual payment days vs. terms on file), recurring journal patterns (the same period-end entries posted month over month), vendor mappings (supplier to default GL account from past approvals), and per-line GL mappings (line description to GL account, so the next bill from the same supplier preselects each line correctly).
Chat history is a transcript — a flat sequence of messages. Brian's memory is structured — facts and decisions are extracted from conversations and stored as discrete, queryable units. A chat tells you what was said; Brian's memory tells you what is true, what was decided, and what happened. The audit trail layer links each memory back to the source that produced it.
05
Every action Brian takes — every bill posted, every journal entered, every memory written — emits a row to the audit trail. The row records the source (PDF, email, Xero record), the agent and procedure that processed it, the skill called, the human approval if any, and the resulting effect (Xero invoice ID, journal ID, memory ID). Asking Brian a question like 'what did we spend with Acme last quarter?' returns the answer alongside the bills and the agent run that produced it.
Both. Brian writes a row to its internal audit trail for every action. For Xero-side actions (posting a bill, posting a journal), Brian also writes a history record onto the Xero invoice itself with a backlink to the originating Brian task. The Xero history is independent of Brian — even if Brian were removed, the Xero records would still carry the Brian-stamped history.
06
Today: Xero (read and write — bills, invoices, journals, chart of accounts, P&L, balance sheet), Claude (as the primary LLM interface), Google Drive (document storage and retrieval), Google Slides (writing management report drafts), email (for ingesting bills and other documents into the Brian Inbox), and Pipedream Connect (for OAuth token management to third-party apps).
Brian's substrate — memory, proof, agents — is model-agnostic. Today, Claude is the first-class human interface (the user talks to Claude, and Claude reads from Brian's memory and runs Brian's agents). The roadmap includes ChatGPT, Gemini, and other LLMs as first-class interfaces. Brian's agents themselves run in their own runtime and do not depend on Claude being attached — they will keep running on schedule whether or not anyone is chatting.
No. Brian sits alongside Xero, reading from and writing to it. The books live in Xero. Brian processes the documents that go into Xero, remembers what it learned, and proves what it did. Removing Brian would not affect what is in Xero.
07
A wrapper sits in front of an LLM and forwards messages. Brian sits underneath the LLM — Claude (or any other AI) talks to Brian to read memory, run agents, and write back audit trails. The AI is a user of Brian, not the other way around. Removing Claude does not remove Brian; the agents keep running on schedule, the memory stays, the audit trail keeps building.
Zapier and Make are stateless workflow tools — a trigger fires, actions run, and there is no memory of what happened beyond a run log. Brian is stateful — every action updates baselines, learned mappings, and the audit trail, and future agent runs read from that learned state. A Zapier flow that processes a bill does not know it processed 50 similar bills last month. Brian does, and uses that to flag the new bill if it is an outlier.
Those are libraries for building agents. Brian is a product — a set of pre-built, production-ready agents (currently for finance) with defined procedures, declared skills, persistent memory, and full audit trails. The user does not write the agent; they connect Xero and the agents run.
08
In a Postgres database hosted on Supabase. Per-tenant data is isolated by row-level security. Encryption at rest is provided by the underlying infrastructure.
Every agent action is gated by either an approval task or a defined boundary condition. Bills more than 25 percent above the supplier baseline route to a human approval task. Document classification below 0.7 confidence routes to manual review instead of automated processing. Reconciliation exceptions are flagged as tasks, not posted. Nothing is posted to Xero or anywhere irreversible without either explicit human approval or a high-confidence boundary check passing.
For the first bill from a new supplier, Brian has no learned baseline. The bill enters the AP agent's approval task with no preselected GL account; the human picks one per line. That first choice becomes the supplier's default GL mapping for future bills, and per-line description mappings are remembered too — the next bill from the same supplier preselects each line by description match.
Visit the landing page, connect Xero, and plug in Claude. The finance agents start running as soon as your Xero data is synced.