The primary cost lever in agentic AI is not the model. Your data architecture is.

The real cost driver: data completeness, not model complexity

Take a plain-language request like “move the Acme deal to Negotiation, raise it to $85K, and book time with their CFO.” With clean, structured data, a well-designed agent completes it in about five operations. The account record is current. There is one record, not three. Contact roles and titles are standardized across the system. Most institutions we work with do not look like that yet.

Run the same request against data that was never built for agents:

• The agent searches for "Acme" and finds three account records. It reads each one to pick the right one.
• It reads related opportunities to confirm which deal is the expansion.
• The CFO's title appears as "CFO," "Chief Financial Officer," and "Finance" across contacts, so the agent reads several to find the right person.
• It re-reads records to confirm what it found before it writes.

The outcome is identical. The interaction count climbs from 5 to 12 or more. The agent also burns more model tokens reasoning through the ambiguity, so your model bill rises alongside your Salesforce bill.

This is the principle behind our Data-First AI Blueprint. When an agent has complete, structured, high-quality data, it confirms instead of reasons. Under per-interaction pricing, an agent that confirms is also an agent that makes fewer calls. Data quality is now a line item on the invoice.

What the cost gap looks like in practice

The gap between a data-poor agent and a data-sufficient agent is material and it compounds with adoption. In our work with regional bank clients, agents built on unstructured or duplicate-heavy data consistently require two to three times as many operations per task compared to agents with clean, purpose-built data products underneath them. The cost difference scales directly with the number of users and tasks.

Three dynamics are consistent regardless of your specific platform or pricing model:

• The gap scales with adoption. More users and more tasks mean the cost difference compounds. Success makes a poorly architected program more expensive, not less.
• Platform consumption costs stack. Agent operations, model tokens, bulk data processing, and third-party integrations each run their own meter. Optimizing one without the others leaves money on the table.
• Data-sufficient agents can fit predictable buying models. A user whose agent completes tasks in four or five operations behaves very differently under consumption pricing than one whose agent needs twelve. Build the data foundation and your procurement options improve.

Design for 80 percent inference-light agents

In a mature agentic program, 8 of every 10 agents should be inference-light. Their data is complete enough that they confirm a known answer and act. The other 2 handle complex, cross-domain decisions where heavy reasoning is required and justified.

Think about a regional bank with 10 agents on their roadmap. Six or seven are RM and advisor agents: meeting prep, pipeline updates, client summaries, deposit retention outreach. These agents should be confirming, not reasoning. The data they need is native to Salesforce, the records are clean, and the answer is already in the system. A well-built semantic layer and purpose-built data product means each task runs in four or five interactions. These are your inference-light agents.

The remaining two or three handle credit analysis, risk scoring, and cross-product recommendations. They pull from multiple systems, reason across incomplete information, and weigh competing signals. These agents earn the reasoning cost. They belong in Databricks, where the full credit picture already sits, and the heavy model call happens next to the data rather than through a dozen headless reads.

The mistake is treating all ten the same. One design pattern, one platform, one interaction budget. That approach pays the highest model cost and the highest interaction count on the simple tasks, and it scales in exactly the wrong direction.

This ratio is as much a cost discipline as it is an architecture discipline.

• Inference-light agents are interaction-light. They read the right record once, act, and verify. Updating a pipeline stage, prepping a client meeting, and routing a service case belong here.
• Heavy reasoning agents explore. They pull from many sources and test options before they decide. Credit analysis, portfolio risk review, and cross-product next-best-action belong here.

A mistake we see often is one design pattern for every agent. Teams build everything as a reasoning agent that searches its way to an answer. That pattern pays the highest model cost and the highest interaction cost on every task, including the simple ones.

Classify every agent on your roadmap before you build it. Label it inference-light or heavy reasoning, and set a target for interactions per task at design review.

Put each agent where its data lives

The cost of an agentic operation varies significantly depending on where the agent runs and how much it has to retrieve before it can act. The principle is to move data in bulk to where the agent reasons, and save individual record operations for writes back to the system of record.

That is the logic of domain regionalization:

This is not fragmentation. It is precision. A credit agent that pulls 40 loan records through Salesforce MCP to reason over them pays for 40 interactions. The same agent running in Databricks, where the full credit picture already sits, skips those reads and pays for one interaction to write its recommendation back.

Four architecture moves to make now

1. Count operations per task for every agent on your roadmap. Use a clean, data-ready baseline task as your benchmark; a well-built agent should complete most routine tasks in four to six operations. Any agent running consistently above that is a data problem, not a model problem. Set a target at design review, next to the risk tier.
2. Build the data product before the agent. Start with the use case closest to production. Resolve duplicate accounts, standardize roles and titles, and pre-join the context the agent needs. A well-built semantic layer is a one-time investment that lowers the cost of every agent you add after it.
3. Route heavy reasoning to the data platform. Keep headless calls for reading and writing the system of record. Send exploration across large datasets to Databricks or your data platform of choice.
4. Match the buying model to the usage pattern. Daily power users fit a fixed monthly commitment. Occasional users and pilots fit consumption-based pricing. Understand how your vendor handles usage above any included allocation before you sign a commitment.

Cost ceilings belong with governance, not only procurement. Part 2 of our governed AI series covers how to set them at intake and enforce them at runtime.

The architecture you design now determines your cost at scale.

The consumption rate your platform charges is largely out of your hands. The number of operations each agent needs to complete each task is not. That number comes from decisions you make now: which data products you build, where each agent runs, and which agents confirm versus reason their way to an answer.

The institutions that build the data foundation first will scale agents at a predictable cost per task. The ones that skip it will find the real number in production, after their teams depend on the agents.

The institutions with the most control over that number are building custom integrations rather than relying entirely on out-of-the-box platform components. The architecture decisions made at the start of an engagement determine whether you are optimizing consumption or absorbing it.