Patricio Barreto

I built a lead-generation script that found prospects by location and job title, qualified the leads by hand, and reached out to the ones that fit. Running those first sales calls taught me how our clients actually run their businesses, and that understanding shaped what I built next.

In a routine monthly call, a tax preparer mentioned they were spending about 30 minutes before every client call just piecing together context. I asked the preparers what they actually needed before a call, mapped each answer to data Soundboard already had, and built the client summaries. Prep time dropped to about 5 minutes. The summaries, the Ops Q&A agent, the QuickBooks automations, and the automated monthly reports all started the same way, in those monthly calls.

See: Client summaries

My rule for what to automate next was simple. First, the low-hanging fruit: changes with the most impact for the least work. Then, whatever was taking the most of the team's time, if it could be automated reliably; if it couldn't, I moved on to the next thing rather than forcing it. Transaction categorization is the clearest example. It was where bookkeepers spent the most hours, which is why it was the first agent I built, and the first one I rebuilt.

See: Transaction categorization

The preparers came to me with a plan: set up a project in Claude with the team's instructions, and open it whenever they needed to write to a client. It would have worked, but every message meant leaving Soundboard, copying the client's conversation into another tool, and relying on instructions someone had to keep updated by hand. Drafting inside Soundboard would be faster, and more accurate, because it could read the actual thread and learn from the team's real past answers. The preparers were glad to have it built for them, and now report replying to clients about 40% faster.

See: Ops Q&A agent

The preparers asked for an AI-written analysis of each client's financials, and for a measure of how responsive each client is to the team's questions and tasks. The financial analysis would have had a model restate, in words, what the computed table already showed clearly, spending tokens on every summary without telling preparers anything new, so I didn't build it. The responsiveness measure was something the data could show and preparers couldn't easily see on their own, so I built it.

See: Client summaries

The first version of transaction categorization, built in 2023, ran on the OpenAI Assistants API. It got categorization live at about 90% accuracy, but it took around 20 seconds per transaction, and when it got something wrong, I had no way to see why or fix it. That was my mistake: for a core feature, I had picked infrastructure I couldn't inspect. Nobody asked me to revisit it, and when I proposed a rebuild to Soundboard's CEO, the pushback was fair: it already works. Instead of arguing, I built a proof of concept and showed its retrieval and categorization accuracy across different transactions and clients. The rebuild in 2024 took two weeks and reached about 3 seconds per transaction and 99% accuracy. Since then, I build core AI features on pieces I can measure and change, and proposing work got easier: when I later suggested the Ops Q&A agent, there was far less hesitation.

See: Transaction categorization

Totals, carryforwards, and financial comparisons are computed in code. The model only handles the decisions that actually need judgment. In the tax agent, 50 of the 155 line items never touch a model at all, and the client summaries show financials as a computed table rather than asking a model to describe them.

See: Tax-filing agent · Client summaries

A category outside the client's chart of accounts becomes "uncategorized," a theme ID that doesn't exist is rejected, and a precedent the model claims to have used must be one it was actually given. Wherever an answer can be checked, the check lives in code, not in the prompt.

See: Transaction categorization · Client summaries · Ops Q&A agent

The categorizer abstains below high confidence, the tax agent marks a line item "insufficient" when the evidence isn't there, and BugBot says what information it's missing instead of inventing a diagnosis. A person reviewing a blank catches it; a person reviewing a plausible wrong answer often doesn't.

See: Transaction categorization · Tax-filing agent · BugBot

Evaluating retrieval on its own tells me whether a mistake came from missing context or bad reasoning, instead of only knowing the final answer was wrong. And I check the measurement too: a similarity threshold that would have rejected every real match, and an evaluation that scored 0% because of a bug in its own test data, were both caught before they mattered.

See: Eval harness · Ops Q&A agent · Transaction categorization

Agents ground their answers in the company's own confirmed history, and every correction feeds back into it: confirmed categories, a preparer's fix to a tax line item, a correction to a summary. What an agent must never learn from is its own output, so the Ops Q&A agent filters out any precedent that came from an AI draft.

See: Transaction categorization · Tax-filing agent · Ops Q&A agent

Every client's data changes every month, but not every client is reviewed every month, so automatic refreshes would keep producing summaries nobody opens. Instead, summaries refresh when a preparer opens one, processing only what changed since the last refresh; the cost is about a minute of waiting. The same thinking runs through the rest: BugBot analyzes each cluster of errors once a day instead of every log line, and structured inputs go to a cheaper model while the stronger one is reserved for messy ones.

See: Client summaries · BugBot