Same Model. Different Context.
How an A/B experiment led me to the idea of an Enterprise Identity
A few words before I start
I’m not an AI researcher. I’m not a software developer. And I’m definitely not a coder.
My professional background is somewhere between product lifecycle management, business strategy, consulting and technology. For years, I’ve been working at the intersection of engineering and business — trying to understand how product knowledge can be turned into better processes, better decisions and, ultimately, better business outcomes.
So when generative AI arrived, I didn’t approach it by asking:
How do I build an AI system?
I approached it from the opposite direction:
What could this technology do with the knowledge, context and experience that already exist inside a company?
I came to Enterprise AI from the problem, not from the technology.
Initially, I used AI like many others did: for research, analysis, writing and structuring information.
And it worked remarkably well.
But there was one thing that increasingly bothered me.
Damn … why do I have to explain everything again?
Every new conversation seemed to start from almost the same place.
Who is the company?
What does it do?
What are its products?
What terminology do we use?
Why is this particular topic relevant?
How does engineering relate to the business?
The model wasn’t doing anything wrong.
It simply didn’t have the context.
And I found myself repeatedly explaining things that were completely obvious to me.
At the same time, AI agents were becoming one of the dominant topics in the industry.
Research Agents. Sales Agents. Engineering Agents. Service Agents.
The promise was compelling: instead of repeatedly instructing a general-purpose AI, specialized agents could take over specific tasks.
Maybe that was the answer.
But before going too far down that road, I wanted to understand something more fundamental.
What happens when an AI doesn’t just know a lot — but knows more about the company it is working for?
That question became the starting point for an experiment.
Two agents. One model.
The setup was deliberately simple.
I gave two AI agents the same task.
Both used the same underlying language model.
Agent A essentially received the task and the information required to answer it.
Agent B received the same task — but I gave it something Agent A didn’t have:
additional context about the company it was working for.
Importantly, this wasn’t some perfectly integrated internal enterprise knowledge base.
At this stage, the company-specific context came from publicly available information.
The model was the same.
The task was the same.
The main variable I wanted to change was the context.
Conceptually, the experiment looked something like this:
Same model. Same task. Different context.
And the difference was much larger than I expected.
The interesting part wasn’t that B knew more
Of course, an AI with more information can produce a more informed answer.
That wasn’t particularly surprising.
What caught my attention was something else.
Agent B didn’t simply produce an answer containing more company facts.
It appeared to approach the task differently.
The terminology was closer to the language I would expect in the company.
The priorities were closer to the way I would discuss the problem with colleagues.
Connections between engineering questions and business implications appeared more naturally.
The answer felt less like:
“Here is what an AI knows about this topic.”
and more like:
“Here is how someone working in this environment might look at this problem.”
That distinction caught my attention.
Because I hadn’t changed the model.
I had changed its context.
Maybe the Agent wasn’t the whole story
Until then, I had been thinking a lot about AI agents.
And that seemed like the obvious level at which to think about Enterprise AI.
A Sales Agent.
A Research Agent.
An Engineering Agent.
A Service Agent.
Give each agent the right role, the right instructions and the right capabilities.
But the A/B experiment suggested another possibility.
Maybe part of what makes an AI useful inside an enterprise isn’t located inside the agent at all.
Maybe the company surrounding the model matters just as much.
At that point, I didn’t have a sophisticated theory for this.
I simply had two outputs in front of me that were surprisingly different.
And one variable that seemed to explain a significant part of that difference:
Context.
The idea of an Enterprise Identity
If company context could make such a difference, could I capture that context in a more systematic way?
The fact that I was still working primarily with publicly available company information made this question particularly interesting.
Companies already leave a surprisingly rich trail of information about themselves in the public domain.
They describe their products.
They explain their capabilities.
They position themselves in markets.
They talk about customers.
They announce partnerships.
They publish strategies and priorities.
Executives give interviews.
Job advertisements reveal capabilities a company is building.
Success stories reveal how it wants to be perceived.
Individually, these are pieces of information.
Get Dr. Robert Hauser’s stories in your inbox
Join Medium for free to get updates from this writer.
But together, I started wondering whether they could form something more coherent.
I began calling it:
Enterprise Identity
Not identity in the branding sense.
And not a persona telling an AI what role to pretend to play.
I was thinking about something more fundamental:
a structured representation of the enterprise the AI is operating within.
Something that could help the model understand questions such as:
Who is this company?
What does it do?
What does it care about?
What products and capabilities define it?
How does it talk about its customers?
How does it connect engineering with business?
And from which perspective does it typically look at a problem?
My first mental model was remarkably simple:
Public Information
↓
Company Signals
↓
Enterprise Identity
↓
LLM
I didn’t know whether Enterprise Identity was even the right term.
I certainly didn’t know what should eventually belong inside it.
But it gave me a way to describe what I had observed in the A/B experiment.
And it introduced an important distinction:
AGENT PERSONA
“Who should you pretend to be?”
vs.
ENTERPRISE IDENTITY
“What organization are you operating within?”
That was a much more interesting question.
My first hypothesis
I could roughly describe it like this:
Nothing particularly revolutionary.
I wasn’t thinking about sophisticated context architectures.
I wasn’t thinking about Knowledge Assets.
I wasn’t thinking about persistent knowledge environments or Second Brains.
My conclusion from the experiment was simply:
Context matters. A lot.
So I did what seemed logical.
I added more.
More company knowledge, of course only from external sources like homepage.
More structured product knowledge.
More customer context.
More professional perspectives.
More methods.
And eventually, more architecture to manage all of it.
For a while, that seemed like the obvious direction.
It wasn’t.
This is where the experiment really started
Looking back, that first A/B test didn’t give me an architecture.
It gave me a question.
If the same language model produces such different results depending on the context surrounding it, where does the useful intelligence of an Enterprise AI system actually come from?
The model?
The prompt?
The agent?
The knowledge?
The context?
Or the interaction between all of them?
I didn’t know.
And that’s probably the most important part of this story.
Because instead of starting with an answer and designing an architecture around it, I started experimenting.
I added things.
I removed things.
I built several generations of the system.
Some changes made it better.
Some made it more complicated without making it more useful.
And some results forced me to reconsider assumptions I had been quite confident about.
That’s what I want to document in this series.
Why I’m sharing this
There is already plenty of excellent work on AI agents, RAG, knowledge graphs, semantic layers, memory and Context Engineering.
I’m not trying to add another grand theory to that list.
And I’m definitely not presenting a finished framework.
What I found increasingly valuable were the moments when an assumption didn’t survive an experiment.
When something worked for a different reason than I had expected.
When adding something helped.
When adding something made things worse.
And when a result forced me to change my mental model of the system.
Those are the moments I want to document.
Think of this series less as a framework and more as a logbook from an ongoing Enterprise AI experiment.
And for each entry, I’ll try to separate three things:
What I observed.
What I think it means.
What I still don’t know.
Some of the assumptions I make along the way will probably turn out to be wrong.
That’s part of the experiment.
And it’s one of the reasons I’m sharing it.
There are people looking at these questions from very different perspectives — AI engineering, software architecture, knowledge management, PLM, enterprise semantics and organizational design.
I’d rather expose my assumptions to those perspectives than quietly build around them.
So this first logbook entry ends with a very simple observation:
Same model. Same task. Different context. Different result.
And my response to that observation seemed equally obvious:
If context helps, add more context.
As I was about to find out, it wasn’t quite that simple.
Next part: I Built Too Much Around the LLM
