# Your AI Can Find the Record. That Doesn't Make It the Answer.

Published: 2026-09-18T13:00:00.000Z · Author: Rod Amora · Canonical URL: https://rodamora.com/blog/your-ai-can-find-the-record-that-doesnt-make-it-the-answer

> At Berry, we keep the sales and onboarding conversations available to the agent so it can follow what changes. But we still have to decide what counts as an agreement and what proves the work was done.

Your AI can find a meeting transcript and still give you the wrong account of what the client needs. Before you let it answer for the company, decide where it should look, how it should follow what changed, and when somebody needs to ask the client instead of choosing between records.

That last part matters because two notes can describe different stages of understanding the same client. Putting them in one system helps you find them, but you still have to work out what happened between them.

We had to do that at Berry. The consultants were going back to sales recordings and transcripts because the handoff notes sometimes described the client's needs too superficially, or treated a financial problem as a sales problem, or the other way around.

So the consultant taking over the work had to read more into what the client was saying before they could be comfortable with the handoff. They had the notes, but having the notes wasn't enough to understand the job.

## The conversation wasn't finished at the sales call

The salesperson got better at understanding what the client needed, but getting it right was hard at first. The consultants weren't going back through the recording just to find a date somebody had copied incorrectly, they were trying to understand what the client expected and needed from us.

Then, in the first meeting, the onboarding meeting, they asked the questions needed to get that understanding right before the work started. The original conversation helped them prepare, and the client helped them settle what it meant.

Every note and every meeting transcript went into the project management system. The [agent](https://rodamora.com/glossary/ai-agent) had access to what happened on the sales call, what happened during onboarding and what happened later, which is how we keep track of things that change during client work.

I co-founded Berry and ran its AI transition myself, and this was part of the work we had to do around the tool. Giving the agent access to the history didn't remove the consultant's job of asking the client the necessary questions.

And I wouldn't read a difference between the sales notes and the onboarding notes as proof that someone recorded the wrong thing. Our understanding could have improved, and the answer needs to account for that instead of treating the earlier note as the final word.

## Adding a tool can add another record

Now, getting the history into a place the agent can reach is one problem. You can create that problem without replacing any of your existing software, just by adding a transcript tool while people keep writing notes somewhere else.

Both tools may have a useful job, and neither is waiting to be switched off. So waiting until the company finishes moving to the new system won't settle where those conversations belong.

Working in two systems during a workflow switch has taken two to four weeks in my experience, maybe more if we keep redesigning the process. That's the period of learning the new way while the old way still runs.

But keeping the client history usable needs attention again when you add another tool or change where people record agreements.

And the tools can write records as well as read them. On one team I watch, a junior built a [skill](https://rodamora.com/glossary/skill) that read meeting transcripts, pulled out tasks and filed them in the project tool, with dates based on what the meeting agreed.

Nobody senior had asked him to build it. He knew the work well enough to see something people were copying by hand and make the tool do it.

That is useful initiative, and it doesn't make him the person who should decide who can change a client promise. If you run the company, you need to settle that with the person responsible for delivery, so whoever builds the tool has a rule to work with.

Your team can help write it, but they shouldn't have to guess which commitments the company stands behind.

## Decide what supports the answer

[Justin McKelvey recommends](https://justinmckelvey.com/blog/ai-automation-for-multi-brand-businesses) that owners running two companies with separate customer systems “declare which system is authoritative, field by field.” In everyday terms, write down where each answer should come from before the AI uses those records.

I agree with that as a starting point. Contact details can come from the customer system, the agreed scope from the signed proposal and approved changes, and delivery needs evidence that the work was sent.

But the Berry handoff is why I wouldn't stop at a list of systems. A rule saying to read the sales note wouldn't have resolved the questions the consultants asked at onboarding, and a rule saying to read only the latest note would leave out the conversation that came before it.

For the client's needs, I'd want the agent to follow the relevant history and explain what was clarified. For a commitment, I'd want it to find what was agreed and whether an approved change replaced it.

Those are different checks, even when the records live in the same place.

You might decide the responsible thing is to clean up every record before doing anything with AI. I understand the instinct, but cleaning up the notes can't decide whether a later conversation changed the agreement, somebody still has to settle that.

And bringing all the software together can become a much larger job than the work you wanted AI to do. McKelvey calls consolidating the two customer systems first “a six-month data migration wearing an AI costume”, which is his warning about making consolidation the prerequisite, not a timeline I'm giving you for your firm.

I would write the rules for the work you're about to automate, including where to look and what counts as a change. That page is my recommendation, not a fix I have measured at Berry, and it needs to be available to the people and the agent doing the work.

It's related to [writing down how the process runs](https://rodamora.com/blog/document-the-process-first-or-the-agent-scales-the-chaos), but it answers a particular part of that job, what supports the answer we're about to give this client?

## Follow the change, or ask

Take a deadline as an example, not a reported incident. Suppose the sales meeting records one date, then the client asks during onboarding whether the work could arrive earlier.

The later transcript records a request. It doesn't, by itself, tell you the company accepted it, so an agent shouldn't put the requested date into the next client update just because it's the newest date it found.

If the person allowed to change the commitment approved it, the agent needs the record of that approval. Your rule should say where that gets recorded and who can make the decision, rather than leave the person building the tool to choose.

If the records don't show whether the request was accepted, the agent needs a rule for stopping or asking, not encouragement to fill the gap. It should hold the answer and show the relevant records to the person responsible for delivery, who can settle the question with the client if needed.

That is the part of the page I would test with whoever builds the workflow. Give it an earlier agreement and a later request without approval, then check that it asks rather than treats the request as a promise.

A page on its own doesn't make an AI stop.

And when someone resolves the question, keep the answer with the client history so the next person doesn't have to reconstruct it again. Some disagreements need a record corrected, others need a missing decision, and the person responsible needs time to do that work.

## Agreement still isn't proof of delivery

There is a limit even when you have a rule and the records agree, and [we found it in a client status update at Berry](https://rodamora.com/blog/ai-native-without-starting-over). The update passed its checks because a task was marked closed, then the client said the work had never arrived.

The records agreed with each other and they were still wrong about reality.

So for a question like “was it delivered?”, I want the check to reach the file that was sent or the delivery message, including who it went to. A closed task can tell you someone finished a step internally, it doesn't by itself establish that the client received the work.

If the message shows a failed send, or the file went to the wrong person, you don't call it delivered because the project tool says closed. The evidence needs to support the claim you're making, especially when [being wrong is expensive](https://rodamora.com/blog/cheap-mistakes-go-to-ai-expensive-ones-wait).

And if another person or AI checks the update, give that checker the underlying evidence too. Checking against the copied status that produced the answer is how you can get agreement without finding the mistake.

## Start with an answer the client will use

This assumes someone owns the work and can decide what counts as an agreement or proof of completion. If those decisions still live in the owner's head, listing the software won't get them out, that conversation comes first.

And if you are replacing a system with a planned switch-off date, you still need the migration work. These rules don't move or sync your data, and access to the history doesn't guarantee the agent will understand it correctly.

I'm drawing on Berry's experience here, not a measured comparison of firms using this approach. I don't have a result to promise you from writing the page.

What I would do this week is take a client answer your AI has produced, a date, a scope, a price or a status, and follow it back with the person who owns the work. Find the record it used, check what was clarified or approved later, and look for the evidence behind anything it says was completed.

Where that leaves an unanswered question, settle it before the next answer goes out. Record the decision where the team and the agent can find it.