Spreadsheet Companies Facing Superintelligence: Records to Fix First

AI for companies running on spreadsheets starts with the records that define how work gets done: customers, orders, prices, approvals and the person who owns each decision. A future, far more capable agent will only be as useful as the records it can read, so the first job is to turn scattered sheets into a small set of identified, defined and permissioned records. Start with the few tables that important decisions depend on, not with the most advanced model you can buy.

Key takeaways

• Structure the records that decisions depend on before you evaluate any model or vendor.
• Give each core record one owner, one definition of every field and one visible change history.
• Decide what an agent may read, draft, write and approve, and write those boundaries down before connecting anything.
• Keep an audit trail of what the agent read and changed, so you can review its work and reverse mistakes.
• Judge readiness by whether a new agent can answer real operating questions from your records without hidden help.

Why spreadsheets are a readiness problem, not a failure

Spreadsheets are not the problem. Many well-run companies keep their operations in them, and they work because people carry the missing context in their heads. A column called Status may mean three different things in three tabs. The real discount rule lives in an email thread. The customer's billing contact is in a comment on a cell that someone deleted last quarter. Human staff compensate for these gaps by asking a colleague or remembering an exception.

An agent does not reliably compensate in that way. It reads what is in the records and acts on it, and when the records are ambiguous, its output is ambiguous too. This is true at any level of capability. A more capable system inherits the same ambiguity unless the business makes its meaning explicit. Readiness for more capable AI is therefore mostly a matter of making implicit knowledge visible, owned and testable.

Which records should you structure first?

Choose records by three criteria: how often decisions depend on them, how costly an error is, and how many people touch them. A record that is used daily by five teams and drives invoices matters more than an archive of old proposals. Most spreadsheet-first companies find the same short list of candidates:

• Customers and accounts: one identifier per organization, with legal name, commercial owner and current status.
• Products or services: one catalog that reflects what is actually sold, including the terms that apply.
• Orders or jobs: each item tracked from request to delivery, with a defined set of states and dates for each change.
• Prices and exceptions: the standard rules, plus every exception, who approved it and the stated reason.
• Suppliers and contracts: the responsible person, the renewal logic and where the signed document lives.
• Decisions and approvals: what was decided, by whom, on what basis and under which limit.

You do not need all six at once. Pick the one or two that serve the process you most want help with, and leave the rest in their current form until the first structure works.

A step-by-step plan for the first records

The work is mostly unglamorous, and it is the part that determines whether any later agent is useful. A practical sequence looks like this:

• Step one: choose one process that already generates repeated questions, such as quoting, order status or renewals.
• Step two: write the ten questions the process must answer in plain language, the kind a new employee would ask in their first week.
• Step three: list every sheet, tab, inbox and chat channel where the answers currently live.
• Step four: choose one source of truth for each field and mark the duplicates for retirement, with a handover period you set and communicate.
• Step five: define each field with its name, allowed values, owner and rule for updating it.
• Step six: add stable identifiers so that the same customer or order is the same row everywhere it appears.
• Step seven: test the structure with the ten questions and record each failure as a missing or unclear definition.

The last step is the one most teams skip. A failed answer is useful information, because it points to a field nobody has defined yet.

Illustrative scenario: a small services firm preparing a quoting agent

The following scenario is illustrative and does not describe a real client. A services firm keeps its quotes in one spreadsheet, its discount approvals in email threads and its project status in a team chat. Before anyone considers an agent to draft quotes, the team agrees on one customer identifier, moves every discount approval into a single table with columns for approver, amount category and reason, and defines accepted quote as a signed document filed in the contract folder, not as a status that someone types.

The first test against the ten questions fails on several items. Each failure traces back to something nobody had written down, such as which discount levels need a second approver or whether a quote can be revised after acceptance. The firm fixes those definitions first. The agent is not connected until the team can answer the questions from the records alone, and until the people who approve discounts know exactly what the agent is allowed to propose.

Permissions and audit trails come with the records

Structured records make permissions possible. Once a field has an owner and a classification, you can decide who and what may read it. A sensible starting pattern is narrow access: the agent reads only the records its role needs, drafts changes in designated fields, and cannot approve anything itself. Approvals stay with named humans, recorded in the table, not in a chat message the agent might misread.

Treat text inside your records as input that can be wrong or even hostile. A note pasted by a customer into a comment field can contain instructions, and an agent that reads that field should not treat the instruction as an order. The safer design separates reading from acting, and requires an explicit human step before anything leaves the company. Keep a log of which records the agent read, what it proposed and what a person changed. The OpenTelemetry observability primer explains the general idea of recording system behavior so that it can be inspected later, and the same discipline applies to agent activity.

Finally, keep a small set of evaluation questions with known correct answers, and rerun them whenever a record structure, rule or tool changes. Anthropic's guidance on context engineering for agents makes a related point: what the agent sees at each step matters as much as the instructions it was given. Clean records are the foundation of that context.

How Be Human's managed approach handles the records

Be Human's managed approach begins with a first engagement that names one useful role, maps the memory and tools that role needs, sets approval boundaries and defines an observable success criterion. In practice, the record structure is treated as part of that scope, so the agent is connected only after the fields it depends on have owners and definitions. The agent's memory, channels, tools and permissions remain under the company's control. Managed operations then include monitoring, recurring evaluations, integration maintenance and permission review, which keeps the records checked as the business changes. The AI stack architecture map is a useful one-page starting point for seeing where those records sit relative to tools and people.

Where to start this month

The next step is smaller than most leaders expect. Choose one process, write its ten questions, and list the places where the answers live today. Then assign an owner to each core field and agree on the approval boundary for the first agent role. Review the permission review steps before granting access to anything sensitive. If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can a company run on spreadsheets and still prepare for more capable AI? Yes. Spreadsheets can hold the records an agent needs, provided the fields are defined, owned and identified consistently. The problem is not the file format but the unstated meaning inside it. Many companies make real progress by structuring a few core sheets before changing anything else.

Do we need to clean every spreadsheet before starting? No. Start with the one process that generates the most repeated questions and the records it depends on. Clean those first, test them against real questions, and only then expand. Trying to fix everything at once usually stalls the work before any useful answer appears.

Who should own the records? Each core record should have a named business owner who decides what its fields mean and approves changes to them. Technical staff can implement the structure, but they should not be the only people who understand it. Ownership is what keeps definitions from drifting as the business changes.

How do we know the records are ready for an agent? Write a set of real operating questions and check whether someone outside the team could answer them from the records alone. Any question that needs a hidden exception, a verbal rule or a colleague's memory shows a gap. Repeat the test after each change, because readiness is something you confirm, not something you declare.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.