The problem
The agent is ready and the data is not: three systems disagree, the policy it quotes is last year's, and it can read a folder it should never have seen. That is where the project stalls, before the model ever matters.
What goes wrong
- Someone asks for all the data. The request goes to IT, and six months later there is a lake nobody uses and no agent in production.
- Access rules are bolted on after the pipeline is built, so the agent has already read what it should not have.
- Nothing tells the agent that the document it is quoting was replaced. It answers from the old version, confidently.
The approach
- Scope the pipeline to one workflow: one desk, one document type, one quarter. The smallest set that proves the agent works, reversible if it does not.
- Pick a source of record per field, write the rule down, and send the records where sources still conflict to a queue a named person owns.
- Scope access before the first sync. The agent reads only the folders and channels your team shares with it. If two groups need different answers, they get two agents with two lists.
- Date every record with when it was last confirmed. Re-check old entries against newer evidence. When freshness matters more than speed, the agent reads the source live.
When it works
When one workflow has a clear source of record, or can be given one, and a person owns the conflict queue. A lender, fund, or advisory firm fits when the documents exist and are just scattered.
Why the pipeline comes first
An agent is only as good as what it can read. Ask a knowledge agent about a lending policy and it answers from the policy it was given. If that is last year's version, the answer is wrong, and it will sound sure. If the agent can see a folder it should not, the answer is a breach.
The fix is not a data warehouse project. It is a pipeline sized to the one workflow you want an agent to run, built so it stays clean, permissioned, and current, with one named person settling the exceptions.
Three questions the pipeline has to answer
Is it clean
Systems disagree. The CRM says the client is active, the fund administrator says closed, the spreadsheet on someone's desktop says something else. An agent that reads all three has no way to know which one is right.
Is it permissioned
An agent should see what the workflow needs. No more. It gets a service account of its own. Inboxes, private drives, and HR channels are never on the list. Add a folder and the agent reads it. Remove one and it stops. The security page covers how we handle your data.
Is it current
A policy that changed last month has to reach the agent last month. The pipeline syncs on a schedule you can see. When the agent reads a source live at the moment of the question, the log says it did.
How we build it
A pod builds the pipeline inside your environment, on accounts you own, and your team can cut off our access in one step. The pod first maps the sources for the one workflow and ranks them: which system is the record for which field. Next the connectors come online, on an access list agreed in writing. Then the sync, the freshness marks, and the conflict queue turn on, and the first agent reads from it beside your team. Every read is logged.
When it does not work
It does not work as a side project for the IT team, and it does not work if the plan is to clean everything before an agent reads anything. Clean the one set the first agent needs. The second agent inherits it.
Where to start
If an agent is already stuck on bad data, the FDE Pod builds the pipeline and the agent together. A week in a pod shows how that work runs. If you are not sure your data is ready, ask Roo, Webaroo's AI: Is our data ready for an AI agent to read?
Book 15 minutes with Connor