Taurus, VerbaGPT's local agentic mode, was mid-investigation into a healthcare claims database it hadn't been given any documentation for — four tables, roughly 1,500 lines of column definitions between them. The schema itself didn't even fit in one tool result: 93,878 characters was enough that it got written to a file on disk instead of returned directly, with a note back explaining how to grep it or read it in chunks. Nothing about the actual analysis had started yet, and reading the whole schema in one shot already wasn't an option.
Taurus grepped that file for drug names and their brand equivalents, then again for the relevant table headers, then ran a quick query just to confirm which literal drug and brand strings actually existed in the data (22 variants turned up — clean ones like OZEMPIC and MOUNJARO, and messier ones like TRULICITY INJ 3/0.5). Reasonable reconnaissance. Then it wrote the query that mattered: a join between the prescription table and a demographics table, pulling cost and payer columns by name — r.RXXPX, r.RXSF, r.RXMD, and so on.
The query failed:
invalid identifier 'R.RXXPX'
RXXPX doesn't exist. The real column is RXXP — one letter longer than what was needed, not shorter. It's an understandable slip: several genuine columns in that same table do end in an extra letter (RXBEGYRX, for one), so the pattern wasn't invented from nothing — it just didn't apply here.
What happened next is the actual point of this post. Taurus didn't retry with a different spelling. It grepped the saved schema file again for every column starting with RX, then went a step further and queried the live table directly — SELECT * FROM all_years_rx LIMIT 1 — to get the current column list as it actually exists, rather than trust its own memory of the schema summary. That single probe surfaced RXXP, RXMD, RXMR, RXPV, RXSF — and, as a side effect of running the same check against the demographics table, it also noticed that table's year column was lowercase (year, not YEAR). That got folded into the next query before it could cause a second SQL error.
The corrected query ran clean: 8,878 prescription fills joined to demographics, zero nulls in any of the columns that mattered. Two steps later, working entirely in pandas, a different error:
Error in REPL: 'total_rx_cost'
The SQL had aliased columns to lowercase names — AS total_rx_cost — ordinary practice. But the connection was returning the resulting DataFrame with upper-case column names regardless of how they'd been aliased in the query text. The code assumed its own alias would come back exactly as written. It didn't.
The response was the same instinct as the first time, not a different guess: print(df.columns.tolist()), print(df.head(2)). That turned up TOTAL_RX_COST, not total_rx_cost. The aggregation code got rewritten against the real casing, and the rest of the run — building six charts across drug trends, demographics, and cost — went through without another schema-related error.
Both of these were genuinely Taurus's own errors — a typo and a bad case assumption, not a case of some other tool breaking underneath it. The point isn't that it avoided mistakes; it didn't. It's that the recovery step was identical both times, and it wasn't "try again and hope." It was a cheap, deterministic query whose only job was to produce ground truth before the next line of real code got written. A LIMIT 1 probe and a .columns.tolist() call cost almost nothing next to a silently wrong join or a mislabeled chart three steps later.
The whole session ran on claude-sonnet-4-6 — the same model wrote the line that guessed RXXPX and the line that decided to check rather than guess again a moment later.
None of this depended on the database being a healthcare claims warehouse specifically. Point Taurus at whatever's actually running in your own database, and the naming will be exactly as inconsistent as this one was — because that's what happens to any schema that's been extended over a few years by more than one person. The same check-before-you-trust-it habit applies regardless of what's actually in the tables.
Taurus itself runs locally against your own databases and files — see verbagpt.com for setup. For a feel for the same ask-a-question, get-real-code-back idea without installing anything, VerbaGPT's cloud mode has a live, no-signup demo: try it against a sample dataset →