Proof before proposal

Most technology proposals arrive too early.

They look polished. They include the architecture diagram, the delivery phases, the implementation estimate, the benefits, the assumptions, the dependencies and the confident promise that this is the right next step.

But too often, the most important thing has not been proven yet.

• Will the data actually support the use case?
• Will the users trust the output?
• Will the model behave reliably with real business exceptions?
• Will the Salesforce org support the workflow without exposing old technical debt?
• Will the agent respect permissions?
• Will the integration perform at the speed the business needs?
• Will the cost still make sense when the system runs every day, not just in a demo?
• Will the business process change enough for the technology to matter?

These are not small details. They are the difference between a successful implementation and another expensive pilot that quietly disappears.

That is why the next stage of enterprise AI buying needs a different rhythm.

Proof before proposal.

Not proof instead of strategy. Not proof instead of architecture. Not an unpaid demo dressed up as consulting.

Proof before proposal means testing the riskiest assumptions before asking a client to commit to major technology spend. It means a controlled, paid, time-boxed proof-of-concept or proof-of-value engagement that gives leaders evidence before they approve a larger build.

For AI, Agentforce, Salesforce automation, Data Cloud / Data 360, custom internal assistants, retrieval systems, company brain prototypes and AI-native workflow tools, this is not a nice-to-have. It is the responsible way to buy.

The Bill Is Coming Due for AI Experiments

The enterprise AI market has moved from excitement to accountability.

Boards and executives are no longer impressed by the existence of a chatbot. They want to know what it improves, what it costs, who uses it, what risk it creates and whether it can survive production reality.

That pressure is justified. MIT Project NANDA research has been widely reported as finding that most corporate generative AI initiatives produced no measurable profit-and-loss impact. S&P Global Market Intelligence has reported a sharp rise in companies abandoning AI initiatives before production. McKinsey has also found that although AI use is now widespread, only a minority of organisations can point to meaningful EBIT impact.

The exact numbers will keep changing as the market matures. The pattern is already clear.

• Adoption is not the same as value.
• A pilot is not the same as production.
• A demo is not the same as a business case.

The problem is not that AI cannot create value. It can. The problem is that many organisations are still buying AI as if it were ordinary software.

Traditional software procurement assumes a mostly deterministic world. You define requirements, select a vendor, map integrations, estimate delivery, build the system, test the workflow and deploy.

That model still matters. But AI adds a different kind of uncertainty.

Large language models are probabilistic. Their behaviour depends on prompts, grounding, context, retrieval quality, model selection, token budgets, tool access, workflow design and human review. AI agents are even more sensitive because they do not only answer. They may plan, select tools, call systems, update records, trigger actions or hand work to another process.

In that world, a proposal written before proof can become theatre. It may be well intentioned, professionally prepared and technically plausible. But if nobody has tested the underlying assumptions, the proposal is still asking the client to bet on theory.

The Illusion of the Polished Proposal

A polished proposal can hide a lot of uncertainty.

• It can assume the CRM data is clean.
• It can assume the knowledge base is current.
• It can assume the integration API behaves as expected.
• It can assume users will adopt the new workflow.
• It can assume the model will return consistent answers.
• It can assume the agent will stay inside its guardrails.
• It can assume the token cost will remain manageable.
• It can assume the security review will be straightforward.

None of those assumptions are harmless.

In Salesforce environments, the risk often sits below the surface. A sales or service process may look simple in a workshop, but the org may contain years of custom fields, validation rules, flows, managed packages, permission set sprawl, duplicate records, stale automation, unclear ownership and undocumented decisions.

An Agentforce use case may sound clear at the executive level: “Let the agent answer customer questions” or “Let the agent help sales reps prepare account plans.” But the real questions are more precise.

• Which records can the agent access?
• Which fields are sensitive?
• Which actions can it take?
• Which policies should ground the response?
• Which customer exceptions should override the standard answer?
• Which handoff path applies when the agent is unsure?
• Which logs will show what happened?
• Which team will tune the agent when behaviour drifts?

The same is true for custom AI-native applications. A company brain prototype may look impressive when it answers from a curated folder. Production work is messier. Documents conflict. Old versions remain in circulation. Permissions vary by role. Users ask ambiguous questions. Retrieval systems return incomplete context. Models produce confident summaries from weak evidence. Costs rise when prompts become longer and agents call tools repeatedly.

A demo can skip those problems. A proposal can describe how they will be handled later. A proof has to face them.

Demo, Prototype, POC, Pilot and Production Are Not the Same Thing

One reason technology projects go wrong is that teams use the same words to mean different things.

• A demo is a controlled presentation of what a tool can do. It is useful for awareness and stakeholder alignment. It does not prove the tool will work in your environment.
• A prototype is an early model of an experience or workflow. It is useful for testing user flow, interface design and conceptual fit. It does not prove production reliability.
• A proof of concept tests whether something is technically feasible. Can the system connect to the data? Can the model answer from the right sources? Can Agentforce execute the scoped action? Can the integration return the right payload?
• A proof of value tests whether the capability is commercially useful. Does it save time? Reduce rework? Improve response quality? Increase conversion? Shorten case resolution? Reduce manual admin? Help a manager make a better decision?
• A pilot is a limited live deployment with real users, real process constraints and operational support. It tests reliability, adoption, governance and change management.
• An MVP is the simplest production-capable version of a product or workflow that can deliver real value to real users.
• Production is the fully supported operating state, with monitoring, security, ownership, change control, escalation, documentation and ongoing improvement.

These stages are connected, but they are not interchangeable. The danger comes when a business mistakes one for another: a demo is mistaken for proof, a prototype is mistaken for a product, a proof of concept is pushed into production, or a pilot runs forever because nobody defined the exit criteria.

Proof before proposal is partly about restoring discipline to those stages. It asks: what exactly are we proving, and what decision will the proof support?

What a Good Proof Actually Tests

A serious proof engagement is not a science project. It is a structured way to test the assumptions that could make or break the larger investment.

For AI and Salesforce work, those assumptions usually fall into three categories.

• Technical feasibility: Is the data available? Is it clean enough? Can the system retrieve the right information? Can the model produce reliable output? Can the integration run within acceptable latency? Can Salesforce support the required configuration? Can Agentforce access the right context and actions?
• Operational fit: Does the workflow actually make sense? Do users trust the output? Does the AI help at the right moment? Does it reduce work, or does it add another screen to check? Who reviews exceptions? Who owns the process after launch? What happens when the model is wrong?
• Governance and cost: Does the proof respect permissions? Are sensitive fields protected? Are actions scoped? Are human approvals built into high-risk workflows? Are prompts, retrieval, tool calls and outputs logged? What is the cost per request? What happens if an agent loops? What is the likely cost at real volume?

Those questions are not obstacles to innovation. They are the path to innovation that survives.

Proof Patterns for Salesforce and Agentforce

Salesforce is often the right foundation for AI when the use case depends on customer data, revenue workflows, service operations, CRM permissions, metadata, auditability and governed action.

That does not mean every idea should go straight into a full implementation. For Salesforce and Agentforce, proof work should usually start in a sandbox or controlled non-production environment. The purpose is not to build the whole future state. The purpose is to test the conditions that must be true for the future state to be worth building.

For an Agentforce proof, that may include:

• Testing whether the agent can answer from approved knowledge and CRM context.
• Confirming that the agent respects user permissions and field-level access.
• Scoping topics and actions so the agent cannot wander into unsafe work.
• Testing handoff when the agent lacks confidence or reaches a policy boundary.
• Reviewing how prompts, instructions and actions behave with messy real examples.
• Checking observability so the team can see what the agent retrieved, decided and did.
• Estimating the operating cost of sessions, tool calls and model usage.

For a Salesforce automation proof, it may include:

• Validating whether the current data model supports the proposed workflow.
• Testing a Flow or approval path against real edge cases.
• Checking how permission sets, validation rules and existing automations interact.
• Identifying technical debt that would make the larger build risky.
• Proving that the business team can test and approve the process clearly.

For a Data Cloud / Data 360 proof, it may include:

• Auditing the completeness and freshness of target records.
• Testing identity resolution or harmonisation patterns.
• Validating access to external data sources.
• Confirming whether the required customer context is available at the right moment.
• Identifying where data cleanup is needed before AI should be trusted.

The important point is that Salesforce proof work should not be limited to “can we turn the feature on?” The better question is: can this capability operate safely inside the real business architecture?

When the Proof Should Leave Salesforce

Resonant 360 should remain strongly pro-Salesforce where Salesforce is the right operating layer. But being pro-Salesforce does not mean forcing every AI use case into Salesforce.

Some proof work should evaluate custom AI-native architecture. That may be true when the use case depends on large volumes of unstructured knowledge outside CRM, such as contracts, technical manuals, project files, policy libraries, call transcripts, internal procedures or multi-system operational data.

It may also be true when the business needs a lightweight internal tool that sits across several systems, when local or private AI is important for cost control or privacy, or when the workflow involves specialist logic, multi-step review, document generation, private knowledge retrieval or tool orchestration that does not belong entirely inside Salesforce.

In those cases, the proof should test a custom pattern:

• Can retrieval find the right documents?
• Can the system distinguish current sources from stale ones?
• Can the model cite its sources clearly?
• Can permissions be enforced before context reaches the model?
• Can routine tasks use lower-cost or private models?
• Can complex tasks escalate to more capable frontier models?
• Can users correct bad answers?
• Can the system be monitored for hallucinations, retrieval failures and cost spikes?
• Can the tool fit into daily work without creating another isolated app?

This is where the company brain idea becomes practical. You do not begin by building the entire company brain. You begin by proving one valuable slice of operational memory: one department, one workflow, one knowledge domain, one decision point and one measurable improvement.

The Cost Question Has to Be Tested Early

AI cost is not just model price. It is input tokens, output tokens, context length, retrieval calls, tool calls, retries, agent loops, logging, evaluation, storage, hosting, user volume, latency requirements and the operational team needed to maintain the system.

A workflow that looks cheap in a demo can become expensive in production if every question carries a large context window, every answer is verbose, every agent runs multiple tool calls, and every failed response is retried.

This is why model routing belongs in the proof. Not every task needs the most capable model. Routine classification, extraction, summarisation, first-draft responses and low-risk retrieval may be handled by smaller or lower-cost models, including private or local options where appropriate. High-value reasoning, sensitive judgement, complex synthesis, strategic planning and customer-facing escalation may justify more expensive frontier models.

The proof should not simply ask, “Which model is best?” It should ask: which model is good enough for this task, at this risk level, with this data, at this cost, inside this workflow?

Proof Work Needs Governance from Day One

Some teams treat proof work as a reason to relax governance. “It is only a prototype.” “It is only a sandbox.” “It is only internal.” “It is only a small group of users.”

That mindset is dangerous. The proof is where governance habits are formed.

• If the proof ignores permissions, nobody has proven the production security model.
• If the proof uses hand-picked clean data, nobody has proven that the workflow handles reality.
• If the proof does not log retrieval and outputs, nobody can explain why the system answered the way it did.
• If the proof has no approval path, nobody has proven safe action.
• If the proof has no success criteria, nobody can say whether it worked.

A responsible proof should include:

• A clearly defined use case.
• A named business owner.
• A scoped dataset.
• A non-production or controlled environment.
• Permission and data-handling rules.
• Human approval for high-risk outputs or actions.
• Observability for prompts, retrieval, tool calls, cost and errors.
• User feedback.
• Explicit success criteria.
• Explicit non-goals.
• A decision gate at the end.

This does not make the proof slow. It makes the proof useful.

The Proof Should Be Paid

Proof before proposal does not mean free work. In fact, unpaid proof work often creates the wrong incentives.

The client may not commit the right people. The vendor may under-resource the work. Access to data and systems may drift. The proof becomes a sales activity instead of a serious evaluation. Nobody wants to make a hard decision because nobody has invested enough to require one.

A good proof is a paid consulting engagement. It should be scoped, priced and governed like real work. That does not mean it needs to be large. The best proof engagements are usually narrow.

For example:

• Should we proceed with an Agentforce implementation for this service workflow?
• Is our Salesforce data ready enough for AI-assisted account planning?
• Can a custom AI assistant reduce manual document search for our operations team?
• Can we safely automate this internal review process?
• Should this workflow be built natively in Salesforce or as a custom AI-native tool?
• What data cleanup is required before a larger proposal would be credible?

The proof is not the big build. It is the decision engine before the big build.

The Executive Evidence Pack

At the end of a proof engagement, leaders should not receive another vague recommendation. They should receive evidence.

An executive evidence pack should include the original use-case charter, what was tested, what was excluded, what data was used, what worked, what failed, what risks were found and what decision is recommended.

It should include a data readiness score, user feedback, examples of successful and failed outputs, integration findings, permission and security observations, estimated operating costs and the support model required after launch.

It should also include a clear recommendation: scale, pivot, pause or stop.

That last option matters. Sometimes the proof should kill the idea. That is not failure. That is capital protection.

A Practical Resonant 360 Proof-First Model

For Resonant 360, proof before proposal can become a clear entry offer. The model should be simple.

• Define before you build. Choose one business problem. Identify the owner. Clarify the workflow. Agree the success criteria. Define the decision the proof is meant to support. Write down what is out of scope.
• Inspect the data and system reality. For Salesforce work, review relevant objects, fields, permissions, flows, automations, reports, integrations and data quality. For custom AI work, review documents, systems, access rules, source quality, retrieval requirements and model constraints.
• Build the controlled proof. This may be an Agentforce sandbox configuration, a Salesforce automation proof, a Data Cloud readiness exercise, a custom RAG prototype, a company brain slice, an internal assistant or a model-routing experiment.
• Test with users and real examples. Do not rely only on happy paths. Use messy records, unclear requests, stale documents, edge cases, permission boundaries and examples that would usually break a demo.
• Measure what matters. Track retrieval quality, answer usefulness, user trust, error patterns, latency, cost per task, manual effort reduced, support needs and implementation risks.
• Present the evidence. Give the executive team a practical decision: scale, pivot, pause or stop.

That is a much better buying process.

What This Changes About the Proposal

The proposal does not disappear. It gets better.

After proof work, the proposal can be more accurate about scope, budget, risk, data cleanup, architecture, change management, governance, adoption and support.

It can separate what is known from what is still uncertain. It can avoid pretending that messy data is a minor detail. It can identify whether the right build path is Salesforce-native, custom AI-native, or hybrid.

Most importantly, it changes the client relationship. The partner is no longer asking the client to trust a promise. The partner is helping the client make a better decision.

The Strategic Point

AI is not failing because it lacks promise. AI is failing when businesses skip the hard work between possibility and production.

The hard work is data readiness, workflow design, user trust, governance, permissions, model evaluation, cost control, observability and change management. That work cannot be fully solved in a sales proposal. It has to be tested.

For Salesforce, that means proving whether the org, the data, the permissions, the workflows and the Agentforce guardrails can support the use case.

For custom AI-native systems, it means proving whether retrieval, model routing, tool access, user behaviour and governance can support the workflow.

For business leaders, it means refusing to approve major spend on a beautiful theory when a controlled proof could reveal the truth earlier.

The right first step is not always a large implementation. The right first step is often a focused proof.

Proof before proposal. Evidence before investment. Strategy grounded in reality.

That is how companies move from AI theatre to AI that works.

Where Resonant 360 Fits

Resonant 360 is positioned for this exact moment.

On one side, Salesforce remains one of the strongest enterprise foundations for trusted customer data, revenue workflows, service operations, permissions, metadata, automation and governed action.

On the other side, many businesses need custom AI-native operating layers that work across documents, internal knowledge, private models, workflow tools and systems that do not live entirely in Salesforce.

The strategic question is not “Salesforce or custom AI?” The better question is: what should we prove first?

Resonant 360 can help clients answer that question through controlled proof-first engagements:

• Salesforce AI readiness reviews.
• Agentforce proof-of-concept sprints.
• Data Cloud / Data 360 readiness assessments.
• Custom AI assistant prototypes.
• Company brain proof slices.
• RAG and enterprise search validation.
• AI workflow automation proofs.
• Model-routing and cost-control experiments.
• Governance and permission reviews.

The goal is not to build something impressive for a demo. The goal is to create enough evidence for a better decision.

Before a company commits to major technology spend, it should know what is real, what is risky, what is valuable and what should be avoided. That is what proof before proposal is for.

Supporting Sources

• MIT NANDA, via Tom’s Hardware, reporting on corporate generative AI project outcomes, accessed 9 June 2026.
• S&P Global Market Intelligence, Generative AI shows rapid growth but yields mixed results, accessed 9 June 2026.
• S&P Global Market Intelligence, AI experiences rapid adoption, but with mixed outcomes, accessed 9 June 2026.
• McKinsey, The State of AI, accessed 9 June 2026.
• RAND Corporation, The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed, accessed 9 June 2026.
• Salesforce Architects, Well-Architected Overview, accessed 9 June 2026.
• Salesforce Architects, Well-Architected: Compliant, accessed 9 June 2026.
• Salesforce, Agentforce, accessed 9 June 2026.
• Salesforce Developers, Agentforce Trust, accessed 9 June 2026.
• NIST, AI Risk Management Framework, accessed 9 June 2026.
• OWASP, Top 10 for Large Language Model Applications, accessed 9 June 2026.