In AX projects, I sometimes walk into a meeting with an idea that looks technically solid.
Connect the data. Reduce repetitive work. Let AI organize information that people used to search for manually. It can even recommend candidate strategies based on past cases.
The room usually does not react badly.
“That sounds good.”
“Let’s give it a try.”
There may be no strong objections at all.
And yet, strangely, progress starts to slow down afterward.
A data request takes much longer than expected. Scheduling interviews with the people who actually do the work becomes difficult. Even after a PoC is ready, almost no one provides feedback when asked to test it.
Nobody clearly opposed the project in the meeting, but people do not actually step into it.
After going through several AX projects, one thing became increasingly clear to me.
In AI adoption, the most difficult person may not be the person who argues against the project. It may be the person who says nothing.
Not Opposing the Project Does Not Mean Agreeing with It
Explicit resistance is often easier to deal with.
“What’s the plan if the AI is wrong?”
“Our work is not that simple.”
“I think you’re saying that because you don’t really know how the process works in practice.”
Those comments may make a meeting uncomfortable.
But they have one major advantage.
At least you know what the other person is worried about.
The harder case is silence.
People nod in meetings, but they do not actively provide data.
When you ask them to test something, the answer is, “I’ll take a look when I have time.”
Even after a new system is available, they continue doing the work in Excel or with the old process.
On the surface, they are not opposing the project.
In practice, however, the project never really enters their day-to-day work.
I began to think of this state as Silent Resistance.
And in real projects, I found this much harder to resolve than open disagreement.
Resistance from the Business Often Has Rational Reasons
From the perspective of the team pushing an AI project, the easiest explanation is simple:
“People do not like change.”
But once you talk seriously with the people doing the work, the situation is usually more complicated.
They often understand very well what happens when a new system fails.
A consultant may leave when the project ends.
A developer may finish the feature and move on to the next project.
But when the system produces the wrong result, the people who have to explain it to the customer, recover from a bad decision, and restore a broken process are usually the people in the business.
So a question like this is perfectly reasonable:
“The result could be wrong. What happens if management starts trusting it?”
I do not think that is simply a question about AI accuracy.
There is much more inside it.
There is anxiety that the AI may produce a wrong answer.
There is anxiety that once the answer appears as a number or a Recommendation, it may gain even more authority.
And there is a fear that, eventually, the judgment they have built their role around may itself be transferred to a system.
Sometimes It Is More Frightening That AI Will Be Trusted Than That AI Will Be Wrong
Imagine a sales system that analyzes customer data and shows this:
Win Probability: 73%
Recommended Strategy: A
Once a number appears on a screen, it has a strange kind of power.
If executives or decision-makers begin to trust that number, the business user faces a new problem.
That person may know something the model does not.
“This customer is dealing with something that cannot be explained by the numbers right now.”
“The executive sponsor changed recently.”
“We had problems in the last project, so we need a different approach this time.”
But the system still says 73%.
At that point, the discomfort is no longer just the technical concern that “AI can be wrong.”
It becomes:
What if the number produced by the system is trusted more than the context I know?
And that leads to an even more fundamental question:
“Then won’t AI eventually make the decisions I used to make?”
I do not think that question should be dismissed as simple resistance to change.
Tacit Knowledge Is Not Just Data We Have Not Collected Yet
One phrase appears frequently in Enterprise AI discussions:
Tacit Knowledge.
It is the knowledge that is not in the documents, not in CRM, and not in the official process, yet still determines how the work actually gets done.
A documented process may say:
Review the customer request, assess it, obtain approval, and respond.
But the person doing the work may tell you something very different.
“You should not follow that process for this customer.”
“For this type of case, we check with Legal before asking the team leader for approval.”
“The system says we do it this way, but in practice we handle it differently.”
“For that person, you should call before sending an email.”
Those details are what often move the work forward.
And during AX projects, I came to believe that tacit knowledge should not be treated simply as data that still needs to be extracted and loaded into a Knowledge Base.
For some people, that knowledge is part of how they have created value inside the organization for years.
Who should be contacted first?
How should a particular customer be persuaded?
How does the real decision-making structure differ from the official org chart?
When does something other than price matter more in a proposal?
These are not random facts. They are expertise accumulated through years of work.
Sometimes they are also a source of influence inside the organization.
So when we say, “Please put that knowledge into the system,” the person hearing it may interpret the request very differently:
“After I put everything I know into the system, what will I be evaluated for?”
I do not consider that feeling irrational.
If anything, it is a reality that people designing AX should acknowledge first.
I No Longer Try to Win the Argument in the Room
In projects, I also hear objections like this:
“There is so much wrong data in the first place. How can AI make a good decision from that?”
Technically, the answer is straightforward.
If the data is wrong, the output can be wrong.
Garbage In, Garbage Out.
You can immediately respond that the real problem is data quality, not AI itself.
But I have become less convinced that logically defeating the objection in the room is the right response.
The sentence we hear may not contain the person’s actual concern in full.
A question that sounds like a data-quality issue may be carrying something else underneath it:
“If the result is wrong, won’t I be the one who is accountable?”
“What if management starts making decisions based only on the AI output?”
“Is this system ultimately being built to reduce people like us?”
Explaining GIGO does not make those questions disappear.
What matters more is creating another opportunity for explanation.
Which data is used?
Which data is intentionally excluded?
What does the system do when the data is insufficient?
Where does AI stop at a recommendation, and where does a person make the final decision?
If the system produces the wrong result, how can a person correct it and feed that correction back into the system?
I think of this less as persuasion and more as increasing transparency.
Answering every objection immediately is not always the best answer.
Sometimes the first task is understanding why the person asked the question at all.
An Agent Can Read More Data, but It Cannot Simply Replace Human Judgment
It is true that an AI Agent can review more data than a person.
No salesperson can remember thousands of historical Deals.
It is also unrealistic for one person to continuously compare competitor moves, market news, customer information, old proposals, and Win/Loss data at the same time.
Agents are making more of that possible.
But that does not mean an Agent can fully replace human judgment.
That is especially true in B2B business.
I sometimes put it this way:
“As long as your counterpart at the customer has not been replaced by an agent, it is hard to imagine your own judgment being fully replaced by one.”
The customer is still a person.
That person has a performance evaluation, internal stakeholders, budget constraints, and the mood of the organization at that particular moment.
The formal org chart may not reflect the real centers of influence.
Sometimes who says something, and in what order, matters more than the proposal itself.
Even an Agent that has read vast amounts of data cannot reduce all of that perfectly to numbers.
That is exactly where experience and tacit knowledge still matter.
That Does Not Mean Humans Should Keep Relying Only on Instinct
There is one misunderstanding to avoid here.
Saying that AI cannot fully replace human judgment is not the same as saying humans should keep making decisions based only on their own intuition.
The competitive environment is already changing.
Customers use data.
Competitors use data.
They analyze which proposals won in the past and which Offerings worked with which customers.
They search for similar Deals, compare competitive situations, and simulate different possibilities.
From that, they can generate a short list of strategy candidates with higher Win Probability before the human decision begins.
In the past, a person might have had to invent three strategies from scratch.
Now data and AI can narrow the space first:
Strategy A.
Strategy B.
Strategy C.
The person’s job is not to pick whichever one has the highest probability score.
It is to add customer context, relationships, timing, and judgment back onto those candidates.
I think that is one of the strongest practical forms of decision-making we can build.
Not Human vs. AI, but Human with better evidence.
AX Should Not Push People Out of the Decision Loop
That is why I do not think the goal of good AX should be to remove people.
I see the direction almost the other way around.
AI should take over much of the repetitive searching, comparing, collecting, and organizing that people had to do before they could make a judgment.
Find similar cases across hundreds of historical Deals.
Collect competitor information.
Compare possible strategies.
Raise questions that may have been missed.
Then show the result to a person.
At that point, the business user adds context that the system does not have.
“This customer is different from the past cases.”
“This time, delivery matters more than price.”
“That stakeholder does not respond to this kind of approach.”
At that moment, tacit knowledge is no longer information competing with AI. It becomes information that modifies the candidates AI produced.
The business user’s question also starts to change.
From:
“Is AI going to do my job?”
to:
“What changes if we add that condition too?”
I think that shift matters a great deal.
When resistance turns into questions, and questions turn into requirements, the user stops being only an evaluator of the system and becomes a co-designer.
That is when an AX project starts to resemble the real work it is supposed to support.
One Practical Problem Still Remains
Imagine that a business user says in a meeting:
“Then what changes if you include the condition I just explained?”
The consultant answers:
“Yes, we can do that. We’ll incorporate it and show you in next week’s demo.”
In the past, that sounded perfectly normal.
But while working on AX projects, I began to realize that “next week” can be a much bigger problem than it appears.
The person has just shared experience.
A question has just emerged.
They are trying, at that moment, to put some of their tacit knowledge into the system.
If the result only comes back a week later, the conversation has already been interrupted.
By then, other work has taken over.
They may not remember exactly why they raised the point.
When they look at the PoC again, it may no longer feel like something that came from their own knowledge and input.
The situation is very different if the result can be shown again in the same session, or shortly afterward.
“No, that’s not what I meant. I meant this kind of case.”
You change it.
“Then what if we do it this way?”
Another detail appears.
You change it again.
At some point, I stopped seeing the purpose of a PoC as merely proving that something is technically possible.
A PoC is closer to a conversation tool between people and the system.
What matters is not only completeness. It is keeping that conversation from breaking.
So the thing I wanted to reduce was not simply development time.
Feedback Latency.
The time between what a business user says and when that idea comes back as something they can actually see and interact with.
That Led Me to Rethink the Development Environment Itself
The problem is that I do not work in a single environment.
There is Salesforce. There is n8n. There is FastAPI and Docker. There are multiple APIs and Git repositories.
You can still build a PoC by asking AI for code, copying the result to a server, running it, bringing the logs back, asking another question, and repeating the cycle.
But even if the interaction between the person and the AI becomes faster, the distance between the AI and the actual execution environment remains large.
That led me to another question.
My development environment already contains Codex CLI, which can read a repository, modify code, run commands, and execute tests.
So why should I think of it only as a Coding Assistant that a person uses from a terminal?
“Could Codex CLI itself become an execution tool that my Agentic Workflow can call?”
What I wanted was not a fully autonomous Agent designed to eliminate the developer.
I wanted an environment where an idea that emerged in a conversation with the business could become working behavior in a very short time, be shown again, and then be revised again.
In other words, I was not really trying to build a system that writes code faster.
I was trying to build a system that turns the feedback loop faster.
In the next article, I will start from that question and explain how I began connecting Codex CLI to my existing development environment and treating it as an execution tool that can be called through an API-like interface.
I will also cover the principle that became even more important in that process:
The real question is not how much freedom to give an Agent, but where to allow freedom and where to impose deterministic control.
Fast PoC iteration does not justify giving up control.
Next Article
I Needed a PoC Faster Than an Explanation: Why I Put Codex CLI into My AX Workflow
How I started treating Codex CLI not merely as a Coding Assistant but as an executable Agentic Tool, connected it to a FastAPI, Git, and Docker-based development environment, and used it to reduce Feedback Latency.