What this covers
- An agent needs narrow, live access to specific records, not a copy of your database.
- Read access and write access are separate decisions with separate risk profiles, and should be scoped separately.
- A data warehouse is not a prerequisite. Reporting copies are the wrong source for a transaction that has to be correct now.
- Where the agent runs and where model inference happens are two different questions, and both belong in the contract.
A deployment stands or falls on one thing that rarely appears in a demonstration: whether the agent can actually reach the record it needs, at the moment it needs it, and write back a result the system accepts. Everything else has an answer. This one is specific to your estate.
The good news is that the requirement is smaller than most teams assume. An agent working a quoting or order workflow does not need your ERP. It needs six or seven specific things out of it.
What the agent actually reads
Take order entry as the example. To turn an inbound purchase order into a validated sales order, the agent needs to answer a fixed set of questions, and each one maps to a narrow read.
| Question | What it reads | How current it has to be |
|---|---|---|
| Who is this from? | Customer accounts, contacts, email domains, ship-to addresses | Daily is usually enough |
| What are they asking for? | Catalog items, descriptions, units of measure, customer part aliases | Daily, plus new items on demand |
| What should it cost? | Contract pricing, volume breaks, active discounts | Live. A cached price is a wrong price |
| Can we supply it? | Stock position, inbound supply, lead times | Live |
| Should we? | Credit status, holds, open balance, payment terms | Live |
| Have we seen this before? | Order history for the account | Daily |
Two of those are the reason a nightly extract is not sufficient. Price and availability have to be true at the moment the quote is prepared, because a quote sent from yesterday's price list is a commercial problem the automation created. The rest can tolerate a lag.
An agent reading yesterday's data will be confidently wrong in exactly the cases that matter most.
Why the data warehouse is the wrong source
A reasonable instinct is to point the agent at the reporting layer. The data is already consolidated, access is already governed, and nobody has to touch the production system. It is the wrong call for operational work, for three reasons.
- It is a lagging copy. Built for analysis over time, not for the state of one record right now.
- It is often reshaped. Aggregations, derived fields and conformed dimensions are useful for reporting and lossy for a transaction.
- It cannot be written to. The agent has to create a sales order, not describe one, and that write has to go through the system's own validation.
The warehouse remains the right place to measure the agent afterwards. It is not the right place for it to work from.
Reads and writes are different decisions
Teams tend to negotiate ERP access as a single question. Splitting it makes both halves easier to agree.
Read access is broad and low risk. The agent needs to see a lot in order to decide well, and seeing does not change anything. The controls that matter are the ordinary ones: a named service identity, scoped to the entities it needs, logged.
Write access is narrow and high risk, and should be scoped like a job description rather than a permission set. For an order agent, the entire write surface is typically: create a sales order in draft or released state, attach the source document, and write a note. Not update pricing. Not amend the customer record. Not delete anything.
There is a second reason to keep writes narrow. Anything the agent creates goes through the system's own validation, which means the ERP remains the authority on what a valid order is. The agent does not get to decide that a mandatory field is optional.
How the connection is actually made
In descending order of preference, and most estates end up with a mixture.
- 01The system's own API
Where a supported interface exists for the entities involved, this is the answer. It enforces the same validation as the user interface and it survives upgrades.
- 02A supported extension point
Many systems expose an integration or extension framework for exactly this. Slower to build against, but it is a sanctioned path rather than a workaround.
- 03A database read with an API write
Common in older estates: read directly where no interface exists, write through a supported path so validation is never bypassed. Acceptable, with the read scoped to specific views.
- 04Interface automation
Driving the application the way a user would, where nothing else exists. It works, it is the most fragile option, and it should be a deliberate last resort rather than a default.
What none of these require is a replatforming project. The agent adapts to the interface that exists; that is the premise of the whole approach, and it is why a deployment is scoped in weeks against a specific workflow rather than as a program of work.
Where it runs
Two questions get conflated and they deserve separate answers in writing.
The first is where the agent runs. Ours runs inside the customer's own infrastructure, in the same environment as the systems it works with. That is what makes narrow, live access possible without opening a system of record to the public internet, and it means your operational data is not copied into a shared service in order to be processed.
The second is where model inference happens, and it is a separate decision with its own data terms. It is agreed per deployment and it should be named explicitly in the contract rather than implied. Security sets out the deployment boundary and what we do and do not claim about it.
What to check before you start
- 01Can we reach live pricing and availability, or only a nightly copy? If only a copy, that is the first thing to solve.
- 02Is there a supported way to create the target record, and what does it validate?
- 03Who owns the service identity, and how is its access reviewed?
- 04Where does the master data for catalog items and customer aliases actually live, and is it one place or several?
- 05What does the ERP log about an externally created record, and is that enough to reconstruct a transaction?
These are the questions a Workflow Review answers for a specific workflow, against your actual estate rather than in the abstract. Most of the time the constraint is not the age of the system. It is whether anyone can say where the authoritative price lives.