What an AI agent needs access to, and how far it actually gets

Two questions get asked about agents now. The first is whether the model is good enough, and that one has mostly been settled. The second is how far the agent can actually reach into the business, and that one has not.

I get asked it in a specific form. Can it look at the CRM, the delivery system, and finance, and tell me whether this project made money. The short answer is that it can reach further than it could a year ago, and not as far as the demo suggests. The distance between those two is worth being precise about, because that distance is where the budget goes.

The wiring stopped being the hard part

Start with what actually changed, because something did. On August 26 Salesforce and Anthropic announced Claudeforce, an expanded partnership. In the announcement Salesforce describes AIforce, its enterprise harness, as bringing “all your business data and workflows to any agent through MCP servers, APIs, and CLI tools, without complicated and costly integrations.” Claude becomes the default model for Slack. Through Amazon Bedrock, Claude runs inside what Salesforce calls its Trust Boundary, which is the arrangement a bank or a hospital system needs before a model gets near its records. The first shipping piece is a plugin with 37 prebuilt sales skills, in pilot now, with an open beta expected in September 2026 (Salesforce, August 26, 2026).

Read that honestly and it cuts against a story I could have told a year ago. Getting an agent to read a Salesforce record over a governed connection used to be an integration project with a scoping document and a change control board. A good part of it is now something an administrator switches on once. The platform vendors are commoditizing the connection layer, they are doing it faster than most people expected, and I think that is genuinely good for the buyers.

It does retire an argument, though. “We can wire Salesforce to Claude” was worth saying in March. It is a checkbox in September, and I would rather say that out loud than keep charging for it.

Notice what got solved, because it is narrower than the headline. Connection got solved. Reach did not.

Reach is four distances, and you have the shortest one

When somebody says an agent can reach across their systems, they are usually describing one thing and buying four.

Can it get there at all. Can it tell that this record over here and that record over there are the same client. Is it allowed to do the thing, in each system, decided separately. And when it does the thing, whose name is on the action, and where does the trail live when somebody asks in eighteen months.

The first one is getting cheap. The other three are where the work moved, and they are not model problems. Three of the four are decisions your business has to make about itself.

The join you have to build yourself

Record matching is the least glamorous item on that list and the one that quietly decides everything.

Here is a clean example from a product line we work in most weeks. Kantata SX, which most people still know as Kimble, is a Salesforce-native managed package. The CRM objects and the delivery objects live in the same org. We proved this out directly against a live schema: the record ids the delivery API hands back are the same eighteen character Salesforce ids. Same record, not a mirror of it. There is no matching problem in that direction, because there is nothing to match.

Kantata OX, from the same vendor, in the same product family, is a separate platform with a genuinely different object model, joined to Salesforce by a connector. Projects and tasks on one side, accounts and opportunities on the other, tied together by whatever the implementation decided to tie them together with. Sometimes a well-maintained external id. Often a name, and names get edited.

Same vendor, same category of software, and “can the agent follow one client across both systems” has two different answers depending on which one you bought.

Then there is the version most firms actually live in. A client is an Account in Salesforce, a customer record in the accounting system, and a billing entity under a slightly different legal name because the paperwork was signed by a subsidiary. A person resolves that in about two seconds from memory and never mentions doing it. An agent resolves it from a key. If nobody ever built the key, the agent still returns an answer, and the answer is confident and wrong about which client it is describing, which is worse than no answer at all.

That work has a name nobody has put in a keynote. It is entity resolution, it is unglamorous, and it is most of the difference between an agent that summarizes one system and an agent that can answer the question somebody actually asked.

AI agent permissions across systems are not one setting

The second thing people buy without noticing is permission scope, and the mistake is treating it as a single grant.

An agent’s rights are decided separately in every system it touches. Read in the CRM. Write in the delivery system. Read in finance. Post in the channel where the team works. That is four grants, usually four administrators, approved in four different quarters, and the thing you have actually authorized is the union of all four. I have yet to walk into a firm where that union was written down anywhere. It cannot be, really, because every security review is organized one system at a time. That is how the questionnaires are built.

The Claudeforce announcement is worth reading precisely on this. An administrator connects it once, Salesforce says, “with authentication and permissions managed centrally,” and every seller on the team has access from day one. That is a real improvement and I do not want to undersell it. It is also central management of one platform’s permissions. It is not the union across the four systems the answer actually lives in, and no vendor can hand you that, because two of those systems are not theirs.

There is a second split inside the same conversation. An agent that can read four systems is an exposure question. An agent that can write in one of them is a “who signed this” question, and they are not the same risk with different dials. Most firms scope both under one approval, and then find out which one they meant later.

The systems disagree about the answer, not only about where it lives

Now assume the good case. Connections are governed, records resolve cleanly, permissions are granted deliberately and written down.

The agent still has to answer “did this project make money,” and the systems it is reading do not agree on what that question means.

Scope lives in the quote. Plan and actuals live in the delivery system. Cost is a rate that resolves against a resource’s grade and geography at the moment the assignment starts, so it is a number with a date attached, not a constant. Recognized revenue accrues against the delivery record on a method somebody chose per engagement, and the choices are not equivalent: milestone, percent complete, fixed, time and materials. The invoice is a separate event over in finance, and it can lead or lag the recognition by a long way. Recognition and invoicing are different things that both look like revenue from a distance.

So there are at least two defensible answers to the partner’s question, they differ by the recognition method and the invoice timing, and both of them are true. A person handed that situation asks “which way do you want it,” and that question is the whole of the expertise. An agent handed four connections and no ruling will pick one, and it will not mention that it picked.

That is the part I would want to understand before I spent anything on the agent. It is not a data quality problem, and it is certainly not a model problem. It is that the semantics were never written down, because for twenty years they lived in the heads of the four people who ran the four systems, and those four people reconciled it in a meeting every month without ever calling it a definition.

So how far can it reach

As far as an API call, today, on most platforms, and further every quarter. That part is real and it is accelerating.

As far as a business motion across three systems, with the permissions intact and the numbers meaning the same thing at both ends, only where somebody has done the work to make that true. Resolve the records. Write down the permission union rather than assuming it. Decide what the number means before something automated has to decide on your behalf.

That is the same work we have been doing for eleven years under other names, across close to a hundred professional services implementations. Data cleanups, org merges, PSA implementations, the integration nobody wanted to own. New label, same discipline. The version of this that runs before you spend anything is the four questions worth answering first.

The reach question sounds like a question about the agent. Every time I have worked it through with a firm, it has turned out to be a question about them.

FAQ