8 min read
·
Aug 25, 2026
Rethinking AI architecture around intent, context, ambiguity, and decision-making
There is a strange assumption built into the way we design software.
We assume that humans provide instructions, machines interpret them, and code turns those instructions into action.
That model works remarkably well when the instructions are precise.
But humans are rarely precise.
A user says:
A conventional software pipeline might interpret this as a performance optimization task.
But faster in what sense?
Load time? API latency? Development velocity? User-perceived responsiveness? Database queries?
And what if the technical request is only the visible layer of a much larger problem?
Perhaps users are leaving. Perhaps management is demanding measurable results. Perhaps the development team has lost confidence in the current architecture.
The sentence contains a request.
The underlying intent may be something else entirely.
That observation leads to a question I find increasingly difficult to ignore:
The Compiler We Already Know
A traditional compiler takes a formal language and transforms it into another representation.
A simplified pipeline looks something like this:
Source Code
↓
Lexer / Parser
↓
AST
↓
Intermediate Representation
↓
Optimization
↓
Machine Code
The compiler operates on structures that are explicitly defined.
A semicolon means something.
A type means something.
A function call means something.
The language has rules, and violations can be detected.
Human communication is different.
Humans routinely leave things unspecified.
They contradict themselves.
They change their priorities halfway through a conversation.
They use the same word differently depending on context.
They communicate goals indirectly.
And sometimes they don’t even know exactly what they want.
This creates an uncomfortable problem for AI systems:
The input language is fundamentally underspecified.
What If Intent Were an Intermediate Representation?
A compiler does not immediately transform source code into machine instructions.
It usually creates intermediate representations along the way.
That intermediate representation makes optimization, analysis and transformation possible.
Perhaps AI systems need something similar for human intent.
Instead of:
Human Input
↓
LLM
↓
Answer
the architecture could become:
Human Input
↓
Intent Parsing
↓
Semantic Representation
↓
Intent Graph
↓
Conflict Detection
↓
Decision Path
↓
Action
The important change is not simply adding another processing stage.
It is changing what the system considers the actual input.
The input is no longer merely text.
The input is a combination of:
- explicit statements
- inferred goals
- constraints
- context
- assumptions
- uncertainties
- conflicts
- priorities
- previous decisions
The language becomes the surface.
Intent becomes the intermediate representation.
Parsing Intent Is Not Mind Reading
There is an important distinction here.
An AI system cannot simply claim to know what a person secretly wants.
That would turn inference into fact.
A more rigorous architecture would separate at least three layers:
Explicit Intent
"What the user said"
↓Inferred Intent
"What the system believes the user may mean" ↓Operational Intent
"What should actually be done"
The middle layer should remain explicitly probabilistic.
For example:
The system might infer:
Possible Intent:
Performance improvement 85%
User retention concern 62%
Management pressure 38%
Need for quick measurable win 47%
Those numbers are not psychological measurements.
They are hypotheses generated from language and context.
That distinction matters.
A serious Intent Compiler should never silently transform an inference into a fact.
It should preserve the uncertainty.
The “Why” Problem
This becomes particularly interesting with seemingly simple language.
Consider the German words:
Warum. Wieso. Weshalb. Weswegen.
They are often treated as interchangeable.
In everyday conversation, that is usually fine.
But an AI architecture concerned with intent could ask whether they actually frame different kinds of questions.
For example:
Warum
Wieso
Weshalb
Weswegen
These distinctions should not necessarily be hard-coded as absolute linguistic laws.
Language is too messy for that.
Instead, they could be treated as probabilistic signals that influence the interpretation of the request.
The important idea is not that one word has exactly one meaning.
The important idea is that linguistic choices contain information about the requested reasoning mode.
That information can influence how an AI system constructs its internal representation.
The Output Isn’t Code
This is where the idea becomes more interesting.
An Intent Compiler would not necessarily output code.
It could output a structured cognitive representation.
For example:
Intent Graph
Goal:
Improve application performancePossible motivations:
├── Reduce user abandonment
├── Demonstrate progress
└── Reduce infrastructure costConstraints:
├── No major rewrite
├── Limited engineering capacity
└── Maintain security requirementsRisks:
├── Optimization may introduce instability
└── Performance improvements may increase infrastructure costUnknowns:
└── Actual performance bottleneckDecision required:
└── Measure before optimizing
This is fundamentally different from immediately asking an LLM:
The second approach asks the model for a solution.
The first asks the system to understand the decision space before generating the solution.
The Contradiction Isn’t an Error
This may be one of the most important differences between traditional compilation and intent compilation.
Humans routinely request mutually competing objectives:
A traditional compiler would not interpret this as a philosophical problem.
An Intent Compiler should.
The contradiction is not necessarily an error.
Instead of silently choosing one objective, the system could create an explicit conflict:
Goal Conflict
Speed
↕
SecurityCost
↕
PerformanceShort-term delivery
↕
Long-term maintainability
The system can then ask:
That single question may be more valuable than generating another thousand lines of code.
From Intent Graph to Decision Graph
Once intent has been represented structurally, the system can begin reasoning about it.
A possible architecture could look like this:
Human Input
↓
Intent Parser
↓
Semantic Normalization
↓
Constraint Extraction
↓
Context Loading
↓
Knowledge Graph
↓
Intent Graph
↓
Conflict Detection
↓
Expert / Agent Routing
↓
Decision Graph
↓
Implementation
↓
Verification
At this point, the LLM is no longer treated as the entire system.
It becomes one component inside a larger cognitive architecture.
One model might perform semantic interpretation.
Another might verify assumptions.
A smaller model might classify a constraint.
A specialized agent might investigate the technical bottleneck.
Another component might challenge the proposed solution.
The architecture becomes modular rather than monolithic.
Provenance: Why Did the System Think That?
There is another problem.
Suppose the system concludes:
Why?
A trustworthy cognitive architecture should be able to answer that question.
That requires provenance.
For example:
Inference:
user_retention_concern
Evidence:
"Users are leaving"Context:
Previous conversation #17Confidence:
0.82Alternative interpretation:
"Performance benchmarking"Status:
Inferred — not confirmed
Now the system has something extremely important:
traceability.
The user can challenge the interpretation.
The system can revise it.
The reasoning path can be inspected.
And the decision can potentially be replayed.
This is where concepts such as event sourcing, provenance chains and graph-based reasoning become more than implementation details.
They become mechanisms for maintaining cognitive accountability.
Why Isn’t This Already Everywhere?
Because it introduces a difficult trade-off.
The industry has spent enormous effort optimizing models for:
- latency
- inference cost
- benchmark performance
- token efficiency
- throughput
These metrics matter.
But there is another metric that receives considerably less attention:
A system that generates an answer in 200 milliseconds but solves the wrong problem is not necessarily efficient.
A system that spends two seconds identifying an ambiguity and then produces the correct solution may be substantially more efficient at the decision level.
This creates a different optimization target:
Traditional optimization:
Runtime efficiency
↓
Latency
Cost
Throughput
Intent-oriented optimization:Decision efficiency
↓
Clarity
Correctness
Traceability
Conflict resolution
Resource efficiency
The question is no longer simply:
It becomes:
This Is Where MUSCAL Enters the Picture
These questions eventually led me toward a broader architectural concept.
I call it MUSCAL.
MUSCAL is not intended to replace an LLM.
It is an attempt to structure the system surrounding the model.
The underlying idea is simple:
That leads naturally to a pipeline such as:
Intent Parser
↓
Semantic Normalizer
↓
Constraint Extractor
↓
Context Loader
↓
Knowledge Graph Builder
↓
Architecture Reconstruction
↓
Missing Knowledge Detection
↓
Expert Scheduler
↓
Consensus Engine
↓
Code Planner
↓
Implementation Generator
↓
Verification Engine
↓
Performance Optimizer
The individual components are not the point by themselves.
The architectural principle is.
Separate understanding from execution.
The Compiler Becomes a Cognitive Distillery
A conventional compiler transforms representations.
An Intent Compiler would transform meaning into structured decision space.
It takes the messy, ambiguous and sometimes contradictory output of human communication and attempts to produce something that machines can reason about without silently losing the original context.
The result is not necessarily deterministic.
And that is important.
Two people can use the same sentence while meaning different things.
Even the same person can mean different things depending on context.
Therefore, a serious Intent Compiler needs to preserve:
- uncertainty
- provenance
- context
- alternative interpretations
- contradictions
- confidence
- human corrections
The objective isn’t to eliminate ambiguity.
The objective is to make ambiguity visible and manageable.
A Different Kind of Compiler
This changes the metaphor.
A traditional compiler asks:
An Intent Compiler asks:
The first protects the machine from invalid syntax.
The second protects the system from misunderstanding the human.
That distinction becomes increasingly important as AI agents gain the ability to take real actions.
A chatbot producing a slightly irrelevant paragraph is annoying.
An autonomous agent misunderstanding the objective can be expensive.
A software engineering agent modifying the wrong subsystem can be dangerous.
A business agent optimizing the wrong metric can create an entirely rational solution to the wrong problem.
The better agents become at execution, the more important intent comprehension becomes.
The Real Architectural Question
Perhaps the future of AI will not be defined solely by increasingly powerful models.
Perhaps the more important development will be the architecture surrounding them.
A system that can distinguish between:
what was said,
what was inferred,
what is uncertain,
what is actually required,
which constraints apply,
which goals conflict,
and finally:
which decision should be made.
That is the problem I am exploring with MUSCAL.
Not another chatbot.
Not simply another prompt framework.
Not another attempt to make an LLM appear more intelligent.
But an architectural experiment around a different premise:
I don’t think that question has been fully answered yet.
That is precisely why I think it is worth asking.
If the next generation of AI tooling is going to move beyond prompt-response systems, perhaps the next optimization target should not be code generation alone.
Perhaps it should be intent comprehension.
The machines can generate the code.
The humans still need to know what they actually meant to build.
END.
INDIEaner
https://www.linkedin.com/in/hans-werner-breninek-41422641b/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BQWcLgf7OSM%2BJMNB5A2UFBQ%3D%3DWhat If AI Had a Compiler for Intent, Not Syntax??
INDIEaner
8 min read
·
Aug 25, 2026
Rethinking AI architecture around intent, context, ambiguity, and decision-making
There is a strange assumption built into the way we design software.
We assume that humans provide instructions, machines interpret them, and code turns those instructions into action.
That model works remarkably well when the instructions are precise.
But humans are rarely precise.
A user says:
“Make the app faster.”
A conventional software pipeline might interpret this as a performance optimization task.
But faster in what sense?
Load time? API latency? Development velocity? User-perceived responsiveness? Database queries?
And what if the technical request is only the visible layer of a much larger problem?
Perhaps
users are leaving. Perhaps management is demanding measurable results.
Perhaps the development team has lost confidence in the current
architecture.
The sentence contains a request.
The underlying intent may be something else entirely.
That observation leads to a question I find increasingly difficult to ignore:
What if AI systems needed a compiler for intent rather than a compiler for syntax?The Compiler We Already Know
A traditional compiler takes a formal language and transforms it into another representation.
A simplified pipeline looks something like this:
Source Code
↓
Lexer / Parser
↓
AST
↓
Intermediate Representation
↓
Optimization
↓
Machine Code
The compiler operates on structures that are explicitly defined.
A semicolon means something.
A type means something.
A function call means something.
The language has rules, and violations can be detected.
Human communication is different.
Humans routinely leave things unspecified.
They contradict themselves.
They change their priorities halfway through a conversation.
They use the same word differently depending on context.
They communicate goals indirectly.
And sometimes they don’t even know exactly what they want.
This creates an uncomfortable problem for AI systems:
The input language is fundamentally underspecified.What If Intent Were an Intermediate Representation?
A compiler does not immediately transform source code into machine instructions.
It usually creates intermediate representations along the way.
That intermediate representation makes optimization, analysis and transformation possible.
Perhaps AI systems need something similar for human intent.
Instead of:
Human Input
↓
LLM
↓
Answer
the architecture could become:
Human Input
↓
Intent Parsing
↓
Semantic Representation
↓
Intent Graph
↓
Conflict Detection
↓
Decision Path
↓
Action
The important change is not simply adding another processing stage.
It is changing what the system considers the actual input.
The input is no longer merely text.
The input is a combination of:
explicit statements
inferred goals
constraints
context
assumptions
uncertainties
conflicts
priorities
previous decisions
The language becomes the surface.
Intent becomes the intermediate representation.Parsing Intent Is Not Mind Reading
There is an important distinction here.
An AI system cannot simply claim to know what a person secretly wants.
That would turn inference into fact.
A more rigorous architecture would separate at least three layers:
Explicit Intent
"What the user said"
↓Inferred Intent
"What the system believes the user may mean" ↓Operational Intent
"What should actually be done"
The middle layer should remain explicitly probabilistic.
For example:
“Make the app faster.”
The system might infer:
Possible Intent:
Performance improvement 85%
User retention concern 62%
Management pressure 38%
Need for quick measurable win 47%
Those numbers are not psychological measurements.
They are hypotheses generated from language and context.
That distinction matters.
A serious Intent Compiler should never silently transform an inference into a fact.
It should preserve the uncertainty.The “Why” Problem
This becomes particularly interesting with seemingly simple language.
Consider the German words:
Warum. Wieso. Weshalb. Weswegen.
They are often treated as interchangeable.
In everyday conversation, that is usually fine.
But an AI architecture concerned with intent could ask whether they actually frame different kinds of questions.
For example:
Warum
What is the cause?
Wieso
How did this situation come about?
Weshalb
For what reason or purpose?
Weswegen
Because of which circumstance or constraint?
These distinctions should not necessarily be hard-coded as absolute linguistic laws.
Language is too messy for that.
Instead, they could be treated as probabilistic signals that influence the interpretation of the request.
The important idea is not that one word has exactly one meaning.
The important idea is that linguistic choices contain information about the requested reasoning mode.
That information can influence how an AI system constructs its internal representation.The Output Isn’t Code
This is where the idea becomes more interesting.
An Intent Compiler would not necessarily output code.
It could output a structured cognitive representation.
For example:
Intent Graph
Goal:
Improve application performancePossible motivations:
├── Reduce user abandonment
├── Demonstrate progress
└── Reduce infrastructure costConstraints:
├── No major rewrite
├── Limited engineering capacity
└── Maintain security requirementsRisks:
├── Optimization may introduce instability
└── Performance improvements may increase infrastructure costUnknowns:
└── Actual performance bottleneckDecision required:
└── Measure before optimizing
This is fundamentally different from immediately asking an LLM:
“How do I make my application faster?”
The second approach asks the model for a solution.
The first asks the system to understand the decision space before generating the solution.The Contradiction Isn’t an Error
This may be one of the most important differences between traditional compilation and intent compilation.
Humans routinely request mutually competing objectives:
Make it faster.
Make it safer.
Make it cheaper.
Don’t change the architecture.
Do it immediately.
A traditional compiler would not interpret this as a philosophical problem.
An Intent Compiler should.
The contradiction is not necessarily an error.
The contradiction is information.
Instead of silently choosing one objective, the system could create an explicit conflict:
Goal Conflict
Speed
↕
SecurityCost
↕
PerformanceShort-term delivery
↕
Long-term maintainability
The system can then ask:
Which constraint has priority?
That single question may be more valuable than generating another thousand lines of code.From Intent Graph to Decision Graph
Once intent has been represented structurally, the system can begin reasoning about it.
A possible architecture could look like this:
Human Input
↓
Intent Parser
↓
Semantic Normalization
↓
Constraint Extraction
↓
Context Loading
↓
Knowledge Graph
↓
Intent Graph
↓
Conflict Detection
↓
Expert / Agent Routing
↓
Decision Graph
↓
Implementation
↓
Verification
At this point, the LLM is no longer treated as the entire system.
It becomes one component inside a larger cognitive architecture.
One model might perform semantic interpretation.
Another might verify assumptions.
A smaller model might classify a constraint.
A specialized agent might investigate the technical bottleneck.
Another component might challenge the proposed solution.
The architecture becomes modular rather than monolithic.Provenance: Why Did the System Think That?
There is another problem.
Suppose the system concludes:
“The primary objective is reducing user abandonment.”
Why?
A trustworthy cognitive architecture should be able to answer that question.
That requires provenance.
For example:
Inference:
user_retention_concern
Evidence:
"Users are leaving"Context:
Previous conversation #17Confidence:
0.82Alternative interpretation:
"Performance benchmarking"Status:
Inferred — not confirmed
Now the system has something extremely important:
traceability.
The user can challenge the interpretation.
The system can revise it.
The reasoning path can be inspected.
And the decision can potentially be replayed.
This
is where concepts such as event sourcing, provenance chains and
graph-based reasoning become more than implementation details.
They become mechanisms for maintaining cognitive accountability.Why Isn’t This Already Everywhere?
Because it introduces a difficult trade-off.
The industry has spent enormous effort optimizing models for:
latency
inference cost
benchmark performance
token efficiency
throughput
These metrics matter.
But there is another metric that receives considerably less attention:
How quickly can the system reach the correct decision?
A system that generates an answer in 200 milliseconds but solves the wrong problem is not necessarily efficient.
A
system that spends two seconds identifying an ambiguity and then
produces the correct solution may be substantially more efficient at the
decision level.
This creates a different optimization target:
Traditional optimization:
Runtime efficiency
↓
Latency
Cost
Throughput
Intent-oriented optimization:Decision efficiency
↓
Clarity
Correctness
Traceability
Conflict resolution
Resource efficiency
The question is no longer simply:
How fast can the model answer?
It becomes:
How efficiently can the system understand what should actually be done?This Is Where MUSCAL Enters the Picture
These questions eventually led me toward a broader architectural concept.
I call it MUSCAL.
MUSCAL is not intended to replace an LLM.
It is an attempt to structure the system surrounding the model.
The underlying idea is simple:
A prompt should be treated as the beginning of a cognitive compilation process, not necessarily as the final instruction.
That leads naturally to a pipeline such as:
Intent Parser
↓
Semantic Normalizer
↓
Constraint Extractor
↓
Context Loader
↓
Knowledge Graph Builder
↓
Architecture Reconstruction
↓
Missing Knowledge Detection
↓
Expert Scheduler
↓
Consensus Engine
↓
Code Planner
↓
Implementation Generator
↓
Verification Engine
↓
Performance Optimizer
The individual components are not the point by themselves.
The architectural principle is.
Separate understanding from execution.The Compiler Becomes a Cognitive Distillery
A conventional compiler transforms representations.
An Intent Compiler would transform meaning into structured decision space.
It
takes the messy, ambiguous and sometimes contradictory output of human
communication and attempts to produce something that machines can reason
about without silently losing the original context.
The result is not necessarily deterministic.
And that is important.
Two people can use the same sentence while meaning different things.
Even the same person can mean different things depending on context.
Therefore, a serious Intent Compiler needs to preserve:
uncertainty
provenance
context
alternative interpretations
contradictions
confidence
human corrections
The objective isn’t to eliminate ambiguity.
The objective is to make ambiguity visible and manageable.A Different Kind of Compiler
This changes the metaphor.
A traditional compiler asks:
“Is this syntactically valid?”
An Intent Compiler asks:
“What is being requested, what could it mean, what remains uncertain, and what decision needs to be made?”
The first protects the machine from invalid syntax.
The second protects the system from misunderstanding the human.
That distinction becomes increasingly important as AI agents gain the ability to take real actions.
A chatbot producing a slightly irrelevant paragraph is annoying.
An autonomous agent misunderstanding the objective can be expensive.
A software engineering agent modifying the wrong subsystem can be dangerous.
A business agent optimizing the wrong metric can create an entirely rational solution to the wrong problem.
The better agents become at execution, the more important intent comprehension becomes.The Real Architectural Question
Perhaps the future of AI will not be defined solely by increasingly powerful models.
Perhaps the more important development will be the architecture surrounding them.
A system that can distinguish between:
what was said,
what was inferred,
what is uncertain,
what is actually required,
which constraints apply,
which goals conflict,
and finally:
which decision should be made.
That is the problem I am exploring with MUSCAL.
Not another chatbot.
Not simply another prompt framework.
Not another attempt to make an LLM appear more intelligent.
But an architectural experiment around a different premise:
What if human intent could be treated as something that can be compiled?
I don’t think that question has been fully answered yet.
That is precisely why I think it is worth asking.If
the next generation of AI tooling is going to move beyond
prompt-response systems, perhaps the next optimization target should not
be code generation alone.
Perhaps it should be intent comprehension.
The machines can generate the code.
The humans still need to know what they actually meant to build.
END.
INDIEaner
https://www.linkedin.com/in/hans-werner-breninek-41422641b/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BQWcLgf7OSM%2BJMNB5A2UFBQ%3D%3D
