Data Strategy for Superintelligence: What to Capture First

The data worth capturing first is the record of how your company decides and works: decisions with their reasons, the exceptions and corrections that never reach a manual, and the process steps people actually follow. Store these in plain, portable formats with an owner and a permission level, because a more capable model will read them far better than today's models do, but it cannot reconstruct context that was never written down. Context, provenance and control matter more than raw volume.

Key takeaways

• Decisions with their reasons outrank raw documents, because the reason is the part nobody can recover later.
• Exceptions, overrides and corrections show where the written process and the real process differ, so capture them early.
• Keep records in open formats you own, each with an owner, a date, a scope and a permission level.
• Store outcomes next to decisions, so a future model can learn what worked and not only what was chosen.
• Start with one role and one decision area, and keep sensitive data out until its access rules are written.

Why capture company data before the models get stronger?

Models will keep improving at reasoning, writing, planning and using tools. What they will not bring with them is your company's context: why you accept certain customers and decline others, which supplier promises are reliable, what an approval really means in your finance team, and which rule has an unwritten exception.

That context lives in people, chat threads, inboxes and habits. It decays. Staff change roles, threads expire, tools get replaced, and the reason behind a decision fades faster than the decision itself. Capturing it costs little while the person who knows is still in the room. Recovering it later costs far more, and sometimes it cannot be done at all.

This is also why the strategy does not depend on guessing which model wins. You are not preparing training data for a specific system. You are building a record that any capable model, now or later, can retrieve and reason over. The AWS guidance on comparing retrieval and fine-tuning is a useful reference here: for most companies, the first and most durable step is keeping knowledge in a form that a model can look up at the moment of work, rather than baking it into model weights. That puts the weight on the quality of your records, not on a particular model choice. For the wider architecture, see Build a Company Superintelligence Layer That Improves With Models.

Which records are most worth capturing first?

Rank by one test: how hard is it to recreate this later, and how much would a capable agent gain from having it? Here is the order we recommend, highest value first.

• Decision records with reasons: what was decided, who decided, which options were rejected and why, and what constraints applied at the time.
• Exceptions and overrides: every time a person departs from the standard process, the case, the reason and who approved it.
• Corrections: every time a person edits, rejects or rewrites work produced by a colleague or an agent, with a short note on what was wrong.
• Process records as practiced: the real steps, handoffs, owners, approvals and tools involved in a recurring piece of work, written by the people who do it.
• Outcome records: what happened after the decision or the work, including late results, complaints, reversals and repeat contacts.
• Interaction history with customers and suppliers: summaries of commitments, preferences, disputes and how they were resolved.
• Reference definitions: glossary, product and service descriptions, policy documents, roles and approval limits, each marked current or superseded.

Notice what is missing from the top of the list: the giant archive of old files. Archives are useful later, but they are mostly facts without reasons. A folder of past proposals tells a model what you sent. A decision record tells it why you sent that version to that client, which is the part that transfers to new situations.

Exceptions and corrections rank high for a specific reason. They are the cheapest source of truth about where your documented process fails. A model that only reads the official procedure will repeat the official procedure. A model that also reads the exceptions learns how your business really behaves.

What makes a record usable by a future model?

A record is usable when a stranger, human or machine, could pick it up in a year and act on it correctly. That is a low-tech standard, and it shapes the format more than any tool choice.

• An owner: a named person or role who can confirm or correct the record.
• A date and a status: when it was written, and whether it is current, under review or superseded.
• A scope: which team, product, customer segment or process it applies to.
• A source: where the information came from, such as a meeting, a ticket or a policy.
• A permission level: who may read it, and which agents may retrieve it.
• Plain language: short sentences, defined terms, no private shorthand.
• A link to the outcome: where the result of the decision or action was later recorded.

Two cautions. First, more is not better. Guidance on context engineering for agents stresses giving a model a small set of high-signal information at the moment it needs it, rather than everything you own. A tidy, current set of decision records beats a large pile of undated notes. Second, keep records in open formats such as plain text, structured documents or standard exports, so you can move them between systems. That protects you from being tied to one vendor's storage, a point we cover in How to Avoid AI Vendor Lock-In With Business Agents.

What is a step-by-step plan to start capturing?

Do this for one role or one decision area first, not the whole company. A narrow start produces a working pattern you can copy.

• Step one: choose one recurring area where judgment matters, such as quoting, refunds, supplier selection, hiring screens or incident triage.
• Step two: name an owner for the area who has the authority to say what is correct.
• Step three: write a short decision record template with fields for the situation, the options, the choice, the reason, the approver and the date.
• Step four: capture at the point of work. A record written in two minutes after the decision is better than a report written a month later.
• Step five: add an exception log. Whenever someone departs from the standard process, they add one entry with the reason.
• Step six: record outcomes. Schedule a light check, so each decision gets an outcome note once the result is known.
• Step seven: set permissions and retention. Decide who and what can read each type of record, and when records expire or get reviewed.
• Step eight: test retrieval with real questions. Ask an agent or a search tool ten questions your team actually asks, and mark whether the answer was correct, grounded in a record and appropriately scoped. Evaluation guidance such as the OpenAI evals guide and Anthropic's writing on agent evals describes how to turn these checks into repeatable tests.
• Step nine: back up the records and test a restore, following the approach in AI Agent Backup and Restore: What to Save and How to Test It.
• Step ten: review quarterly, retire stale records and expand to the next area only when the first one is reliable.

The retrieval test in step eight is the part most teams skip. It is also the part that tells you whether your records are actually usable, instead of merely stored.

What does this look like in practice? An illustrative scenario

Illustrative scenario: a regional distribution company wants an agent to help its accounts team handle customer credit requests. The written credit policy is two pages. In practice, the senior accountant approves exceptions based on payment history, seasonal cash flow and the relationship with the customer's owner, none of which is in the policy.

The team starts with one thing: every credit exception gets a short record. It states the request, the customer's situation, the decision, the reason and the approver. When the customer later pays on time or late, someone adds a one-line outcome note. They also log each time an agent's draft reply is corrected, with a few words on what was wrong.

After a few months the company has a compact, current body of cases. A newly onboarded accountant can read them. An agent can retrieve the closest past cases when a request arrives and propose a draft with the precedents cited, leaving approval with the senior accountant. When a stronger model is adopted later, the same records improve its answers immediately, because the reasons and outcomes were captured in a form that does not depend on any one model.

Nothing in this scenario required a data lake, a new platform or a large project. It required a template, an owner and a habit.

What should you leave out or handle carefully?

Capturing more is not always safer or wiser. Some material needs rules before it goes anywhere near an agent.

• Credentials and secrets: never store passwords, tokens or keys inside records. Access belongs in a controlled secrets system.
• Personal data: capture only what the purpose needs, and check where it is stored and processed. Our guide to AI data residency for business explains the questions to ask.
• Privileged or confidential material: legal advice, board matters and employee evaluations need explicit access rules, or should stay out of scope.
• Unreviewed drafts and speculation: label them as drafts, or leave them out, so a model does not treat a guess as policy.
• Anything where consent or contractual terms are unclear: resolve that first.

A risk framework helps structure these decisions. The NIST AI Risk Management Framework offers a plain vocabulary for mapping, measuring and managing risk, and it applies to data choices as much as to models. Keeping agents' permissions narrower than the records you hold is a sound default, reviewed on a schedule, as described in How to Run a Permission Review for Your AI Agents, Step by Step.

How does a managed approach handle this?

Be Human treats record capture as part of defining a role, not as a separate data project. In a first engagement we agree on one useful role, the decisions and processes it touches, the memory and tools it needs, the approval boundaries and an observable success criterion. We then help set up the decision, exception and outcome records for that role, keep them in portable formats the company owns, and apply permissions so each agent retrieves only what its role allows. Under managed operations, retrieval is tested on recurring checks, stale records are flagged to their owners, and changes go through human approval. For a broader orientation, see How to Prepare Your Company for Superintelligent AI Today.

Frequently asked questions

Do we need to clean all our data before we start? No. Cleaning everything first is the usual way these efforts stall. Start with one role, capture new decisions and exceptions as they happen, and clean older material only when a real question needs it.

Should we fine-tune a model on our data instead? For most companies, not as a first step. Keeping well-organized, permissioned records that a model can retrieve at the moment of work is easier to update, easier to audit and easier to remove from, and it carries over when you change models. Fine-tuning can be considered later for specific, stable behaviors, once your records and evaluations are in place.

Who should own the records? A named business owner for each area should own correctness, and a technical owner should own storage, access and backups. Splitting them avoids two failure modes: records that are accurate but unreachable, and records that are reachable but wrong. Review the owners whenever people change roles.

How do we know the capture effort is working? Test it with real questions from your team and check whether answers are correct, grounded in a specific record and limited to what the asker may see. Also watch whether people add records without being chased, since habit is the best sign the template fits the work. If retrieval tests fail, fix the records before changing the model.

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