Six months in, the AI agent was working. The spreadsheet behind it was not. A short note on what happens when a shared Google Sheet is the source of truth for production work.
The agent had been routing inbound leads for six months. It read a Google Sheet on a fifteen-minute cron, processed any rows in new status, classified the lead, looked up the right account owner, wrote the assignment back to the sheet, and pinged the owner in Slack. The team called it Margaret, for reasons nobody could remember.
Margaret worked. The team trusted her. Then for three weeks she didn't, and nobody noticed.
The sheet had eleven columns when Margaret was built. By the time Margaret broke, it had nineteen. The columns had been added by humans, one at a time, over six months. New territories needed flags. New product lines needed source tags. A regional manager wanted a notes column. The columns were inserted between existing columns, which is what spreadsheets let you do. Margaret read by header name in her own code, so the insertions didn't break her. Until one of the inserts was a column named status that the regional manager intended for a customer-success use, and Margaret's status was the lead-routing status she'd been reading for six months.
The first sheet's status was now in column B. The new status was in column G. Margaret started reading G.
Column G was empty for new leads. Margaret saw empty and concluded the lead had no status, so the lead was new, so the lead needed routing. She routed it. She wrote assigned to column G, where the regional manager's customer-success workflow was tracking needs check-in. The two systems collided silently. The regional manager's reports started showing leads as needing check-in when they'd just been assigned. The account owners' Slack pings started landing on leads they'd already worked.
Three weeks of cross-talk before the regional manager's weekly report flagged the pattern. By then, Margaret had touched 940 leads, of which about 60 had been routed to the wrong owners and another 200 had been added to a customer-success queue that had nothing to do with them.
The team's first instinct was that Margaret had drifted. The model is older, the system prompt is the same, the agent must have somehow learned the wrong thing. The instinct was wrong. Margaret had not drifted. The data layer had drifted, silently, in the way data layers drift when their schema lives in a spreadsheet with no validation, no migration log, and no human accountable for changes.
The fix was structural. We pulled Margaret's input out of the sheet entirely. The lead-routing data now lives in a small Postgres table with a schema definition checked into Git. Changes to the schema require a migration, which requires a commit, which requires a review. The sheet still exists for human convenience — the regional manager can still add notes — but it writes to the table, not as the table. Margaret reads the table.
Six months in, the operating model around Margaret is the same. The data layer underneath her has a name, a schema, and an owner. The kind of breakage that took three weeks to surface now surfaces on the commit that would cause it, because the commit fails the schema check.
The thing we learned, or relearned: the failure mode of an agent that depends on a spreadsheet is not the agent. It is the spreadsheet. Agents are deterministic when their inputs are. Their inputs aren't, when the input is a shared Google Sheet eleven people can edit without coordination.
The shorter version: if you're building an agent, build it against a data store, not a document. The cost of doing it right at the start is one afternoon. The cost of doing it wrong is three weeks of silent damage at month seven.