The Smartest Agent in the Room Can't Fix a Broken Spreadsheet
Everyone is putting AI agents on everything. Customer support, code generation, data analysis, workflow automation. The pitch is always the same: “Just describe what you want in natural language, and the agent does the rest.”
So here’s a question that’s rarely being asked:
What happens when the agent writes to a system that has no rules?
The Temptation
I run a small consultancy. I need to track work hours, create invoices, record payments, and manage contractor payroll. Like most small companies, I started with Excel.
Then AI agents came along — and suddenly Excel felt smart. Why build a custom application with forms and screens when you can just talk to an agent?
“Record 8 hours for Alex on the consulting engagement, March 15.” “Create an invoice for Client A for March.” “Record a payment of 136,000 DKK, bank ref 12345.”
The agent understands the intent, finds the right spreadsheet, writes the rows. No UI needed. Just natural language and a spreadsheet.
It sounds perfect. Until you look at what happens next.
What the Agent Can’t Do
An AI agent is an interface — it translates human intent into actions. It can be incredibly smart about understanding what you want. But it cannot enforce what the underlying system doesn’t support.
Here’s what happens in practice:
You tell the agent to record a payment. It writes a row in Excel. A week later, someone opens the file and changes the amount. No trace. No prevention. The agent never knows.
You tell the agent to approve an invoice. It updates a cell to “Approved”. But there’s no payment method on the invoice — the agent didn’t check, or it checked but nothing stopped a direct edit later.
Two people use the agent simultaneously. One records a payment while the other updates an expense. Excel locks the file — or worse, last-write-wins. Data lost.
You tell the agent to close the March ledger. It writes “closed” in a column. Nothing prevents someone from editing March’s numbers after it’s closed. The sequential integrity of your financial records is a suggestion, not an enforcement.
You tell the agent to void a payment. It deletes the row. The original payment — the one your accountant needs for the audit trail — is gone.
The Core Problem
Rules must live in the system, not in the prompt.
An agent’s prompt can say “never modify a closed ledger” — but that’s a suggestion, not an enforcement. A controlled API with a database makes it a physical impossibility.
You can put instructions in the prompt:
- “Always check if the invoice has a payment method before approving”
- “Never delete a payment — mark it as voided instead”
- “Don’t allow edits to non-draft invoices”
But these are hopes. They depend on the agent following them perfectly, every time, with no hallucinations, no edge cases, no one bypassing the agent to edit the file directly.
A controlled API doesn’t hope. It refuses.
{
"error": "Only draft invoices can be edited"
}{
"error": "Invoice must have a payment method before approval"
}{
"error": "Cannot close this month — previous month's ledger is still open"
}The agent gets a clear error back. It can explain it to the user. The data stays consistent.
What a Controlled API Gives You
The system I built has 33 entities and enforces rules that no spreadsheet can:
Immutability — once an invoice is approved, only the status can change. Line items, amounts, addresses — all frozen. The API physically blocks any modification attempt.
Void, don’t delete — payments are voided with a timestamp and reason. The original record stays. Your accountant can see what happened and when. The audit trail is complete.
Transactional integrity — when you create a contact and mark it as primary, both the contact creation and the parent company update happen in a single database transaction. Either both succeed, or neither does. No half-states.
Sequential close — you can’t close February’s ledger until January’s is closed. You can’t reopen January if February is already closed. The chain is enforced, not hoped for.
Computed status — invoice payment status is never set manually. It’s always computed from the sum of non-voided payments. Pay 5,000 of a 10,000 invoice → Partially Paid. Void the payment → reverts to Sent. The agent doesn’t decide — the math decides.
The Legal Dimension
This isn’t just about engineering elegance. In Denmark, bogføringsloven (the bookkeeping act) requires businesses to maintain financial records that are:
- Systematic — structured, not ad hoc
- Traceable — every record has an origin and a history
- Protected against modification — once entered, records can’t be silently changed
An Excel file fails all three. A database with audit fields, foreign keys, and immutability guards satisfies all three.
So Where Does the AI Agent Go?
Here’s the twist: I am building an AI agent on top of this system. But the agent talks to the API, not to a spreadsheet.
The agent is the interface — smart, conversational, convenient. The API is the authority — strict, transactional, legally sound.
“Create a payout for Alex, March, 70,000 DKK”
The agent calls POST /api/contractorpayouts. The API validates, creates the record with audit fields, defaults the salary from the contractor’s profile. The agent reports back: “Created. Payout for Alex, March 2026, 70,000 DKK. Status: Draft.”
If the agent tries something invalid:
“Approve that invoice”
The API responds: “Invoice must have a payment method before approval.” The agent tells the user. No data corruption. No silent failure.
The agent is the pilot. The API is the aircraft. You want a great pilot — but you definitely want an aircraft, not a car.
The Bottom Line
The question isn’t whether AI agents are useful — they are, enormously. The question is what’s underneath them.
A spreadsheet gives the agent a blank canvas with no rules. A controlled API gives the agent a structured world where every action is validated, every state transition is guarded, and every record is traceable.
Build the system first. Then let the agent talk to it.
#AI #Architecture #Agents #APIDesign #AIgineering #NordTekIT