Before automating a workflow, agree which data to trust

Most automation projects start with the workflow. Map the steps, pick the tool, connect the systems, switch it on. The data question comes later. Usually in week three, when the agent produces an answer nobody believes.

Ask a simple question in most firms: what is the current contract value for this client? Finance has one number in the accounting system. The account manager has another in the CRM. The project lead has a third in a spreadsheet that gets updated most Fridays. Each of them can explain why their number is right. None of them is wrong on purpose. They work from different sources, and until now that was fine, because a person closed the gap in their head.

An agent cannot do that. It does not ask which number is right. It takes the one it is given and acts on it, quickly and every time. If three systems disagree, automation does not fix the disagreement. It scales it.

Automation inherits whatever the data already is

A person doing a task carries context nobody wrote down. They know the CRM status is rarely updated after a contract is signed. They know the region field changed meaning when the sales team reorganised. They know the invoice export misses credit notes, so they add them by hand.

That knowledge is the real control layer in most workflows, and it lives in people's heads. When you hand the workflow to an agent, you take the person out and keep the data. Every quiet correction they used to make goes with them.

This is why so many pilots look good in a demo and fail in production. The demo runs on a clean sample. Production runs on the real thing.

What agreeing on the data actually means

It is not a data quality project. You do not need perfect data to automate. You need an agreement about the figures this one workflow depends on. It covers four things.

1. Which system holds the version of record. For every figure the workflow uses, name one source. Not “the CRM, mostly”. One system. Everything else is a copy.
2. Who owns it. A named person who is accountable for that figure being right. Not the IT team in general. The person who would notice first if it went wrong.
3. Where it breaks. Fields whose meaning has changed. Manual steps where someone exports a file, fixes it and imports it again. Two systems that disagree on purpose, because they measure different things under the same name.
4. What happens when sources disagree. Sooner or later the agent will meet a conflict. Decide now what it does: stop, flag it to the owner, or follow the version of record and note the gap.

That is the whole agreement. It fits on one page per workflow. Most firms have never written it down.

An example: the monthly client report

Take a workflow almost every services firm wants to automate: the monthly report to each client. Hours spent, budget used, work delivered, what comes next.

On paper it is a strong candidate. It passes the three tests for a first agent: a fixed format, a named person who can check it quickly, and a mistake that is caught before it goes out. Then you look at the data.

• Hours come from the time tracker. But some people log a whole week on Friday afternoon, against whichever project they remember.
• Budget sits in the accounting system. But change requests are approved by email and only reach accounting at the end of the quarter.
• Work delivered lives on the project board. But a ticket marked done might mean finished, or it might mean sent to the client for review.

An agent that builds the report from those sources will produce something that looks right and is wrong in ways the client spots first. The account manager then spends longer fixing the report than writing it used to take. And the team decides the AI does not work.

Now run the same workflow after the agreement.

• Hours. The time tracker is the version of record. Time is logged by Tuesday for the week before. The delivery lead owns it.
• Budget. Accounting is the source. Approved change requests go in on the day they are approved. Finance owns it.
• Work delivered. Only tickets in the Accepted column count.
• Conflicts. When hours run more than ten percent over budget, the agent does not send. It puts the report in front of the account manager at the gate.

Same workflow. Same agent. A very different result, and nothing about the AI changed.

Why this belongs before the build

Every firm finds its data problems eventually. The question is when, and what it costs.

Found before the build, a data gap is a conversation and a decision. Found during the build, it is rework. Found after go live, it is a wrong number in front of a client and a team that stops trusting the agent. Trust lost that way is slow to win back.

There is a second reason. The agreement you write for one workflow carries over. Once the firm agrees that accounting is the version of record for budget, the next agent that touches budget starts from that decision, not from a fresh argument. The data agreement compounds, the same way a good specification does.

Where Runbaze fits

On Runbaze, the agreement becomes part of how the work runs. The specification for each agent names its sources and its rule for conflicts. When the data does not match, the output lands at a gate, and a named person decides. Every run goes on the record: which sources the agent read, what it produced, which model ran and who approved it. When someone asks where a number came from, the answer is already there.

But a platform can only enforce an agreement that exists. The agreement comes first.

Start with a scan

If you are about to automate a workflow, ask the people who run it today one question: where does each number come from, and who would know if it were wrong? If the answers differ, that is your first piece of work.

A Data Foundation Scan does this properly, in four weeks, for a fixed fee. For each system and critical data flow, it answers four questions. Which system holds the version of record, and who owns it. Where the data breaks. What that blocks today. And what it takes to fix, in the order that unblocks the most. You get one document, the Data Readiness Assessment, and it is yours whether or not you continue with us.

Know which data to trust first. Then automate on top of it.