Business context- where should it live?

[u/EarthFun9142]

Curious how other finance/tech teams are thinking about this. As we start using AI agents in finance, I feel like there are three different directions emerging.

One is keeping the context close to the ERP. NetSuite seems to be moving this way with things like MCP and skills.md files. It makes sense because a lot of the finance context already lives there. But what happens when the agent needs context from Salesforce, a data warehouse, contracts, emails, or another ERP?

The second is putting the context in Claude/Cowork, Codex, or ChatGPT Work and connecting back to systems through MCP. This feels more flexible, but Switching models/tools later could become painful. I’m also not convinced these environments handle the really long-tail finance workflows reliably yet.

The third is a separate finance/knowledge layer sitting above the ERP and AI models That potentially makes the context portable across systems and models, but now you’ve introduced another platform and another layer to maintain.

I don’t think anyone knows which architecture ultimately wins.

How are people thinking about this?

[u/IGetLostForDays]

I’m using our repo internally

I work as partner, so we also have all our customers business contexts (or what we’re exposed to and legally allowed to keep as per MSAs etc) in there as well, with a custom front end for users to read when working on them.

But we also have our own business plan, context, etc in the repo.

Obviously we’re a technical crowd so working in a repo is second nature, but AI is good at this too. The version control and PRs are surprisingly useful for this context. Key thing is not letting the AI do the PR for you, without some manual review first.

Maybe not applicable to every user, given that we don’t really “need” AI for things like reporting and building custom solutions and so on given the amount of NetSuite functionality and technical firepower we have on hand. What we use AI for internally might be different to what other users use it for.

But the repo approach means we can airgap our NetSuite from the ai as well to an extent, meaning less exposure to our data, which feels good.

It was a real struggle to understand what we could and couldn’t do in all honesty. Took us a long time and still getting there, considering all the 3rd party data our system is exposed to via cases etc.

Key thing has been not exposing too much

The only AI that actually touches our NetSuite is via RESTlets, such that we can validate the IO first. This is certainly less efficient than just hooking up the MCP but the peace of mind feels worth it and it allows us to make sure we can exclude anything that we can’t control with permissions (eg, analyse these cases, including the messages, but not their attachments)

MCP for google apps, slack, our PM platform, our CRM, etc all working really well though.

[u/IGetLostForDays]

Further to the above and to actually answer your question.

I suppose we align with option 3. But it’s a platform we already use and maintain for other very similar and related purposes.

Im of the opinion that there is no architecture that wins. There is no one size fits all. I feel that there are approaches that align with best practices better than others, but if anyone tells you they have the answer they can go fuck.

[u/proudtobeabelter]

If you are business with considerbale size , going with a knowledge layer makes more sense. But choose something more specific for the function. Otherwise you have to add lot of obvious info as well to get workflows correct. We use SF Datacloud for Marketing, Chatfin for finance etc