A 50-person company doesn't need a data lake to use AI
AI agents need to know what a record means, how it relates to others, who may see it and whether it's current. A small company can provide that without copying all of its data into one place.
A common piece of advice to companies that want to use AI goes like this: first, get all of your data into one place. For a large enterprise that can mean a data lake or a data warehouse, a central store that copies records out of dozens or hundreds of systems so analysts and software can query them together. Smaller companies hear the same advice and conclude that AI is a project for later, after they've paid for that kind of infrastructure.
For a company of 50 people, that conclusion is usually mistaken, because what an AI agent needs most is something a central copy of the data doesn't provide by itself.
What an AI agent needs to answer a business question
Suppose an owner asks an agent a simple question: which clients owe us money and still have open work with us? To answer it, the agent has to know several things that aren't written in any single row of data.
- What a record means. The CRM calls them accounts, the accounting system calls them customers, and the project tool calls them clients. The agent needs to know these are the same clients, and which record in one system matches which record in another.
- How records relate. An invoice belongs to a client and usually to a specific job or engagement. Open work means jobs that haven't been closed, so the agent needs to know how a job connects to the invoices raised against it.
- Who may see it. Billing balances may be restricted to the partners and the finance lead, and an agent answering on someone's behalf has to apply the same restriction.
- Whether it's current. If the accounting data was last copied over yesterday, the agent should know that a payment made this morning may be missing.
Together these make up the context an agent works from. An agent that can read every row in the company but lacks that context will still produce confident answers that are wrong, because it has no reliable way to match a customer in one system to a client in another or to know which figures it isn't allowed to share.
What a central data store does and doesn't provide
A data lake moves rows into one place. That's useful when a company has so many systems that querying each of them separately is impractical. The meaning of the records, the relationships between them and the rules about who sees what still have to be defined by someone after the data lands, and the copy is only as current as its last refresh. For a large enterprise, that definition work is often a major project with its own team. For a 50-person company, building the store first means paying for infrastructure before doing the part that makes the data usable.
Where a small company's data already lives
A typical 50-person professional services firm keeps most of its operating data in a handful of systems: accounting, a CRM, a project or practice management tool, payroll, and email and documents. The firm may pay for 12 to 30 SaaS tools in total, but the records that describe its customers, its jobs and its money are concentrated in a few of them. Most of those systems offer an API or an export, so the data can be reached where it sits.
One owned model of customers, jobs and money
The useful work for a small company is agreeing, once, on what its core records are and how they connect. A customer has one identifier that every system maps to. A job belongs to a customer, has an owner, and moves through the stages the firm actually uses. Money is the invoices, payments and costs attached to each job. Permissions are defined against those records, so the same rules apply whether a person or an agent is asking.
When that model lives in a database the company owns, it becomes the place agents read from. That's the model Clearloom works toward as it builds apps for a client, and under the standard agreement the database schemas belong to the client on payment. An agent working against that schema knows what a job is because the schema defines it, and for the records an owned app holds, it knows the figures are current because that app is where they're entered.
This also keeps the work proportionate to the company. A 50-person firm needs a clear definition of the few records that drive its decisions, and that definition stays useful whichever AI model the company uses next year.
A starting point you can work on this month
- List the systems that hold customer, job and money records. For most small firms it's a short list.
- For each kind of record, decide which system is the system of record, meaning the one whose version wins when two systems disagree.
- Write down who should see billing, compensation and client-confidential information, so the rules exist before any agent touches the data.
- Ask your IT provider which of those systems allow API access on your current plan and how user accounts and permissions are set up. They'll know where the access controls live, and their questions about security are the right ones to answer early.
If you'd like to know which of your current tools you need before you start, Clearloom offers a free SaaS audit at clearloom.ai/audit. It's a 15-minute call. You share your last three months of software invoices, and we send back a ranked list of what to cancel, what to consolidate and the projected savings. You keep the list whether you work with us or not.
Want the real numbers for your own stack?
Send us three months of software invoices. We'll come back with a ranked kill-list and the 12-month ROI math. Free.
Book the audit