A few years ago, enterprise AI discussions tended to start with technology.
Which model should we use? Should we add RAG? Should this become an agent? How much of the workflow can we automate?
The technology has improved dramatically since then, and there are far more choices. Paradoxically, that has made me less interested in starting with the technology.
Across different projects, the wording changed, but the requests often sounded familiar:
“Can we add RAG so the sales team can find what it needs automatically?”
“Can the voice agent make the call and update CRM so people barely have to touch it?”
“If classification accuracy is above 90 percent, can’t we automate it now?”
Each sounds like a technical question. One appears to be about retrieval quality, another about voice AI, another about model accuracy.
Then design work begins, and the questions change.
Which information is even eligible to influence this deal? If a call ends ambiguously, who decides what state CRM should record? If a model is right 90 percent of the time, is it allowed to make a wrong contract-related or customer-data mutation in the other 10 percent?
That is the point where a technology-selection meeting becomes an AX architecture meeting.
In RAG work, retrieval was not the first boundary I needed
Anyone who has spent years in B2B sales knows that work is not difficult only because information is scarce.
Often there is too much of it.
Market reports, product material, previous proposals, CRM records, customer emails, competitor information, and internal notes accumulate continuously. The hard part is deciding which of those facts can actually change the decision in front of you.
I initially approached Enterprise RAG the way many engineers do: improve retrieval quality, tune chunking, choose embeddings carefully, and increase recall.
Those things matter. But once the system touches real business work, a more fundamental problem appears.
Imagine an RFP arrives. The system retrieves a highly relevant market report and a previous proposal. Both look useful. But the current commercial terms live in an ERP or contract repository, while the latest account structure lives in CRM.
If those sources disagree, which one wins?
A RAG system can retrieve the most relevant document and still be wrong operationally if relevance is confused with authority.
So the question changed.
Instead of asking, “Which vector database should we use?” I started asking, “Which information is eligible to influence this decision, and which source wins when sources conflict?”
That shift is also why I now separate Deal Context from broader market knowledge. The goal is not to stuff more information into a context window. The goal is to narrow the information space first, then distinguish source authority from semantic relevance inside that space.
Looking back, two contracts were missing.
The first was Value. Success was never “the RAG system generated an answer.” Success was whether the sales or proposal team could find material evidence faster and make a better decision with less effort.
The second was Authority. Search relevance is not business truth. CRM, signed contracts, approved product knowledge, and current external evidence each have different authority.
Once those boundaries are explicit, the retrieval technology becomes a second-order decision.
Voice agents became harder after the call ended
Voice AI is one of the easiest areas in which to feel how quickly the technology has moved.
A couple of years ago, I was wiring Whisper into n8n-based voice-agent PoCs. At the time, simply recognizing speech and letting a workflow react to it felt impressive.
Today, direct speech-to-speech interaction and tool use are ordinary architectural options. OpenAI’s current Realtime documentation describes stateful speech-to-speech sessions with tool calling, and platforms such as Ultravox can connect directly to telephony providers such as Telnyx for outbound calling.
But when I recently connected an outbound voice agent to a CRM process, the problems that consumed the most design time were not voice quality or latency.
There was a Call Item in Salesforce. A scheduler initiated execution. Once an actual phone call was created, telephony and the voice-agent runtime introduced their own call identities.
Then the real questions started.
How do we prove that this Salesforce Call Item and this external call_id represent the same business operation?
The call connected, but there is almost no transcript. Did the person hang up immediately? Was it voicemail? Was there a transport problem? Is this a failed attempt?
If we should call again, when is it safe? Is the previous call definitely over? If a timeout only hid the response, how do we avoid duplicating a side effect?
And there is a more important question:
If an LLM reads the transcript and classifies the outcome as SUCCESS, does that give it the authority to update CRM?
For me, the answer was no.
The LLM was useful for understanding the meaning of the conversation. SUCCESS, REJECT, VOICEMAIL, and similar semantic classifications are legitimate model work.
But canonical Call Item state, retry eligibility, concurrency, and CRM mutation belonged to Salesforce and the deterministic runtime.
There was another useful lesson in that project.
At contact-center scale, an event-driven webhook architecture and dedicated middleware may be the right choice. But at pilot scale, with only a small number of calls per day, adding a public inbound endpoint, webhook authentication, retransmission behavior, and another operational surface can be unnecessary.
We could keep Salesforce as the system of record and reconcile call state and transcripts through outbound API GET operations at the appropriate time.
The more “real-time” or “agentic” architecture was not automatically the better one.
The question I ended up using for voice-agent design was no longer:
How naturally can the agent speak?
It became:
If this call is a Business Job, who owns its identity, state, retry semantics, and final mutation?
Higher accuracy sometimes meant less automation, not more
Classification PoCs are easy to demo.
You run representative examples, the results look strong, and the accuracy climbs past 90 or 95 percent.
The next question is almost inevitable:
“Isn’t this good enough to automate now?”
In enterprise systems, accuracy and automation coverage are not the same number.
Misclassifying a FAQ may be inexpensive to correct. Misclassifying a contract condition, changing an important CRM field, or sending a wrong customer-facing answer can have a very different consequence.
The same five-percent error rate can represent completely different business risk.
At some point, I stopped treating model confidence as execution authority.
The model can produce a judgment and useful uncertainty signals. The application should decide whether that result receives AUTO, VERIFY, or REVIEW authority based on validation evidence and business risk.
That distinction sounds small. Operationally, it changes everything.
Accuracy is a model-performance metric. Automation coverage is a business-risk policy. They are not the same number.
The human role changes as well.
If Human-in-the-Loop means only “a person handles it when the AI is wrong,” it is not much of an operating model.
Who reviews which risk class? Who may override the model? What evidence must be recorded? Where does the correction go? Can that correction become part of the next evaluation or calibration cycle?
These are operational questions, not UI details.
That is also consistent with the direction of NIST’s AI Risk Management Framework, which explicitly treats human-AI roles, responsibilities, oversight, documentation, and organizational risk management as lifecycle concerns rather than a final checkbox.
Different projects kept converging on the same questions
RAG, voice agents, and AI classification are technically different systems.
Yet after designing several of them, I noticed that my questions were becoming repetitive.
In RAG work, I stopped asking only, “What should we retrieve?” and started asking, “What is material to this decision, and which source has authority?”
In voice-agent work, I stopped asking only, “How natural is the conversation?” and started asking, “Who owns the state and mutation of this call as a Business Job?”
In classification automation, I stopped asking only, “How accurate is the model?” and started asking, “Which kinds of error are we willing to execute automatically?”
Eventually, those questions converged into five groups.
I call them Value, Decision, Authority, Execution, and Adoption.
I do not present these as an industry standard. They are a practical framework I use because they capture questions that repeatedly surfaced while moving PoCs toward production.
1. Value — What has to change for this to be worth doing?
“Build an agent” is not a business outcome.
We need a baseline and a target.
How much processing time should fall? How much triage effort should disappear? What error cost matters? What risk is unacceptable? What is explicitly out of scope?
Without those answers, a successful demo can easily be mistaken for a successful transformation.
2. Decision — Where is semantic uncertainty actually needed?
Before turning an end-to-end process into an agent, I decompose the work.
Interpreting language, comparing evidence, classifying intent, summarizing, or selecting among ambiguous options are good candidates for probabilistic judgment.
Schema validation, authorization, calculation, persistence, serialization, and legal state transitions generally are not.
The goal is not to maximize agent usage. It is to locate the decision grain where uncertainty is real.
3. Authority — When sources conflict, who wins?
Enterprise systems always contain multiple sources.
CRM, ERP, SharePoint, email, RAG, and web search can describe the same entity differently.
The important question is therefore not just “Where is the data?” but “Which source is authoritative when they disagree?”
Read authority and write authority may also differ.
An agent’s ability to access a record does not mean it should be able to mutate it.
4. Execution — How does judgment become a safe state transition?
A valid JSON response from an AI model does not mean the business operation is complete.
The judgment must be validated. Policy and approval must be checked. The legal state transition must be applied. The external mutation must be performed and read back.
That is where business identity, idempotency, concurrency, preconditions, retry, resume, replay, and partial-failure recovery live.
These concerns barely appear in a happy-path PoC. They become some of the most important work in production.
5. Adoption — Put the human into the operating model, not into a fallback box
“Someone will review it at the end” is not an operating model.
Who reviews it? Under what condition? Which risk classes can run automatically? Who can override? What evidence is captured? Does a correction feed the next evaluation cycle?
Only when those questions are explicit does Human-in-the-Loop become part of production control rather than a vague safety promise.
I no longer accept the discovery sentence at face value
Suppose a customer says:
“Have the agent classify customer inquiries, answer them, and update CRM automatically.”
I no longer put that sentence directly into the backlog.
I start with Value. How much should handling time or triage effort fall? What is the tolerance for a wrong CRM mutation?
Then Decision. Intent classification and drafting may be AI work. Known routing rules, schema validation, permission checks, and CRM mutation can remain deterministic.
Then Authority. Customer master data belongs to CRM. Product specifications come from an approved corpus. Contract and pricing truth belongs to contract or ERP authority. An email body is request context; it does not automatically become canonical customer truth.
Then Execution. Define case identity and idempotency. Check the current state before mutation. Read back after the write. After a timeout, do not begin with a blind retry; first reconcile whether the side effect already happened.
Then Adoption. Low-risk FAQ handling may receive AUTO authority. Ambiguous intent may require VERIFY. Contract, pricing, or sensitive mutation may require REVIEW. Human corrections become evaluation-data candidates rather than disappearing into exception handling.
It is still the same business request, but it is now an implementable operating contract.
And at that point, something interesting happens: choosing the technology becomes easier.
You can see where an LLM is useful, where RAG is needed, which capability should be exposed through an API or MCP surface, what n8n can validate quickly in a PoC, and what should move into a durable production service.
The better AI becomes, the more important the boundary becomes
I used to see a new model or agent feature and ask, “Where can I use this?”
My order of questions has changed.
What does success mean?
What actually needs AI judgment?
What do we accept as truth?
Who owns execution authority?
How does the business survive failure?
Where does the human remain accountable, and what does the system learn from that intervention?
Once those boundaries are clear, the choice of model, agent framework, RAG stack, MCP surface, or workflow engine becomes much simpler.
The value of an Enterprise AX consultant is not knowing the largest number of new AI products.
It is putting new AI capabilities inside boundaries that the business can actually operate, govern, recover, and trust.