What data and infrastructure do we need to build to support our AI use cases?

Start from the use case, not the data project

The instinct is to clean up all the firm data first, build a warehouse, and then decide what to do with it. The published material runs the other way. The AI strategy answer on this site says to pick the capability where the firm hurts most, rebuild it so AI does the work and a named person supervises the judgment, prove the measure moved, and take the next one. The IT essay in the newer book says the cause of most technology problems in the current era is the absence of design rather than poor execution: without it, tools are selected in isolation, workflows fracture across systems, and data becomes fragmented and inconsistent.

As an inference, each use case defines its own data requirement. A proposal workflow needs past proposals, scopes, prices and outcomes. A forecasting workflow needs opportunity history and the buyer evidence behind each stage. An account expansion workflow needs client communications and engagement history. Build the data each capability needs as you rebuild it, against one shared design, and the foundation accumulates in the right order.

What the data layer is for

The IT essay lists the questions a firm must now answer, and one of them is how data is structured to support reasoning, not just reporting. Its reference architecture puts the data layer between the workflows and the intelligence: it unifies operational, financial and delivery data into a consistent, accessible foundation, so the intelligence layer can interpret data, identify patterns and inform decisions across the firm. The essay credits the previous era with real progress, including centralizing data, but notes that the data was still fragmented.

As an inference, the difference between reporting and reasoning is the difference between a number and its explanation. A report needs a total. Reasoning needs the context behind it: why a deal was lost, what the client said before they expanded, which scope assumption broke on an engagement that ran over. That context is mostly text, and most firms do not keep it.

The data most boutiques already have and do not keep

The account executive essay in the newer book identifies the shift that made this possible. Most buyer and seller conversations in professional services moved to recorded video platforms, so for the first time the conversation itself became capturable: verbatim, time-stamped and reviewable. The essay says that recording alone did not solve the problem, because it created more raw information than anyone could analyze, and that the second breakthrough is AI analyzing those conversations continuously.

The lead generation essay lists what an AI agent should take in to understand why a firm wins: the ideal client profile, past deals won and lost, positioning, pricing, client transcripts, service descriptions, value propositions, founder interviews, case studies and benchmarking data. The account management essay describes the same system reading client emails, summarizing meetings and analyzing deliverables to detect risk and surface opportunity.

As an inference, four kinds of data do most of the work in a boutique. Conversations with buyers and clients. Commercial history, meaning every opportunity with its stage evidence and the stated reason it was won or lost. Engagement economics, meaning scope, effort, cost to deliver and margin by engagement, which the all-in cost answer on this site depends on. And the intellectual property: methods, frameworks, templates and the best deliverables, which the replication chapter of the 2020 book says should be captured so expertise belongs to the firm rather than to individuals.

Structure it so AI can reason over it

Collective 54 publishes no data model or schema. As an inference from the material, a few rules make most of the difference. Give every client and engagement one identifier that every system uses, so a conversation, a proposal, a timesheet and an invoice can be connected. Record reasons, not just outcomes: a lost deal with no stated reason teaches nothing. Keep text with its context, including who said it, when, and on which opportunity or engagement. Decide one system of record for each kind of data, which the CRM answer on this site applies to sales. And retire the spreadsheets that hold the real numbers in parallel, because the system cannot reason over what it cannot see.

The infrastructure around the data

The IT essay names two more layers the data depends on. The integration layer orchestrates communication across software applications, AI systems and external tools so workflows move end to end without brittle handoffs or manual intervention. The governance layer enforces security, access control, compliance and decision rights, so intelligence is applied responsibly and consistently as the firm scales.

The essay is clear about who builds what. IT is overhead and execution stays outsourced: provisioning, security, access, uptime, integrations and support are handled by external providers. What the firm must not outsource is the design, because generalist providers keep systems running but do not design how intelligence is applied to selling, scoping, pricing, delivering and expanding work. The contracts and IP answer on this site covers the client data restrictions governance has to respect.

Why buyers will look at it

The IT essay says sophisticated buyers evaluate coherence rather than tool count, and that fragmented systems, brittle integrations, unclear data lineage and ungoverned AI usage look risky regardless of growth. As an inference, a firm that can show where each number came from, and which conversation or record sits behind it, is easier to diligence than one that rebuilds its numbers in spreadsheets for every buyer request.

What we do not prescribe

Collective 54 names no data platform, warehouse, vendor or managed provider, and publishes no data model, retention policy or technology budget. The published positions are the five-layer reference architecture, data structured for reasoning and not just reporting, unifying operational, financial and delivery data, recorded conversations as a new data source, what an AI agent should ingest, the firm owning the design while execution stays outsourced, and coherence and data lineage as what buyers evaluate.

When this answer flips

If client contracts or regulation restrict where client data can go, as an inference, settle that in governance before connecting any system to it.

If the firm is small and runs on a handful of tools, the tech stack answer on this site suggests a one-page architecture is enough; the data rules above still apply.

And if data is what you sell to clients, as in a subscription to proprietary data, it is a product and an intellectual property decision, not only internal infrastructure.

The short answer

Work backward from the use cases and build the data each one needs against one shared design, rather than starting with a firm-wide data project. The IT essay says data should be structured to support reasoning, not just reporting, in a layer that unifies operational, financial and delivery data. For a boutique the most valuable data is usually thrown away today: recorded buyer and client conversations, the reasons deals were won and lost, the real cost of each engagement, and the methods and deliverables that hold the expertise of the firm. Connect it with one identifier per client and engagement, record reasons as well as outcomes, and keep one system of record for each kind of data. Around it, build integration so work moves end to end and governance for security, access, compliance and decision rights. Own the design and outsource the execution. Buyers will check the lineage.