In the previous article, I argued that Enterprise RAG should not begin with search. If an RFP mentions AI, cloud, security, and robotics, opening all of those domains as research targets may produce more retrieval, but it can also dilute the business context. Deal Context should first decide what is eligible to be searched for this piece of work.
While designing that architecture, however, I ran into the next problem.
Bounding the search space does not tell the agent how the company interprets that space.
Suppose we have already narrowed the scope to logistics automation. The public web still contains warehouse robotics, WMS/WES/WCS, equipment vendors, AI vision, digital twins, customer investments, and competitor announcements. To decide which of those changes actually matter, the agent needs more than a scope.
It needs a Market Lens.
Scope and Lens solve different problems
Deal Context can use industry, offering, deal stage, active scope, and source authority to reduce the candidate space. But it does not automatically answer questions such as:
- What does the customer actually buy on in this market?
- Is competition driven by equipment performance, price, integration, software control, or operational certainty?
- Which competitors are strong on which dimensions?
- Where has our company repeatedly demonstrated an advantage?
- What kind of market change would weaken that advantage?
These are not questions a search engine should define for the company.
Enterprises already have ways of seeing their markets. That knowledge is scattered across strategy reports, market-intelligence material, previous proposals, win/loss reviews, customer conversations, and delivery experience.
The distinction I find useful is simple:
Scope = the boundary of the world that is eligible for search
Lens = the company’s way of interpreting that world
A useful Enterprise Web Search Agent needs both.
Re-injecting the same reports is not compounding knowledge
The simplest implementation is obvious. Whenever a new RFP arrives, attach the relevant market report, competitor report, previous proposal, and customer research to the prompt.
Conceptually:
New RFP + MI Report + Competitor Report + Previous Proposal + Customer Research → LLM
That can work well enough in a PoC. The problem is that the same knowledge is reinterpreted on every run.
A market report may have been written last year. A competitor assessment may have been updated earlier this year. A customer observation may have been added last month. If all of them are pushed into the context window together, the model has to reconstruct which one is the baseline, which one is newer evidence, and which claim has already been superseded.
Token cost is not the main issue. Consistency of perspective is.
One run may over-weight a recent article and quietly redefine a taxonomy that the company has used for years. Another may read an old proposal as if it described the current market. The agent belongs to the same company, yet its view of the market changes slightly every time the prompt is assembled.
That is less an information-retrieval problem than a knowledge-lifecycle problem.
The LLM Wiki separates raw documents from maintained knowledge
This is where Andrej Karpathy’s April 2026 LLM Wiki idea becomes useful.
Karpathy points out that a typical RAG workflow keeps rediscovering knowledge from raw documents at query time. His alternative is to place a persistent, LLM-maintained wiki between the user and the raw sources.
The pattern has three layers:
- Raw sources — curated originals that the LLM reads but does not modify
- Wiki — summaries, entity pages, concepts, comparisons, and syntheses that the LLM maintains
- Schema — the operating conventions that tell the agent how to ingest, query, and maintain the wiki
The important part is that ingestion is not merely indexing. A new source can update existing pages, add cross-references, expose contradictions, and strengthen or challenge an existing synthesis. Periodic Lint passes can identify stale claims, contradictions, missing links, and knowledge gaps.
The wiki is therefore more than a retrieval index.
Instead of reconstructing understanding from scratch, it lets the next question reuse understanding that has already been built.
For enterprise market intelligence, that opens up an interesting extension.
Treat enterprise MI as a compounding knowledge layer
A company’s view of a market is rarely contained in one perfect document.
Over time, new evidence arrives from many directions:
- Market definitions and industry / offering taxonomies
- Customer buying criteria and investment patterns
- Competitor products, references, acquisitions, and partnerships
- Internal capabilities and delivery experience
- Recurring strengths and weaknesses from win/loss reviews
- Technology and regulatory changes
- New questions discovered in live deals
Rather than pushing all of this back into every prompt, the raw evidence can remain provenance-preserving while a maintained knowledge layer represents the current corporate understanding.
Consider a simplified logistics Market Lens.
It might capture:
- Sectors — fulfillment / warehouse automation, WMS·WES·WCS, robotics, control integration, transportation, lifecycle operation
- Customer Buying Criteria — throughput, stabilization time, delivery schedule, recovery, operational reliability
- Competitive Axes — equipment performance, integration, software control, observability, lifecycle operation
- Competitor Position — who is strong on which axis
- Our Capability — repeatable strengths in areas such as integration, commissioning, or operations
- Known Gaps — strategic weaknesses that still need to be watched
- Strategic Questions — changes that would force us to reconsider our current positioning
A new RFP no longer has to make the agent relearn the market from the beginning.
RFPs change deal by deal. The company’s way of segmenting the market and understanding competition is an asset that can compound.
A Wiki and a Skill are not the same thing
There is another boundary worth making explicit.
The enterprise Wiki is a broad knowledge layer. It may contain source summaries, customer histories, competitor changes, past analyses, contradictions, and confidence notes.
A Web Search Agent should not consume all of that for every run.
Instead, the relevant part can be compiled into a bounded Market Lens Skill.
Conceptually, such a Skill may contain:
- market scope and taxonomy
- customer buying criteria
- competitive axes
- known competitor positions
- company strengths and known gaps
- strategic questions
- the baseline’s as-of date
- evidence references
- freshness and review policy
Here, “Skill” does not mean a long system prompt. I mean something closer to a domain research contract that the agent can reuse when working in that market.
The Wiki accumulates what the company knows. The Skill constrains how the agent should use that knowledge for research.
What changes when a logistics RFP arrives
Take a sanitized example.
A logistics company issues a new automation RFP. It contains terms such as sorter, conveyor, PLC, WCS, WMS, robots, AI, networks, security, cloud, monitoring, APIs, and digital twins.
Without a Lens, a Web Search Agent can easily expand into broad searches for warehouse automation trends, robotics markets, AI logistics, or digital twins.
It will find plenty of information. But whether that information strengthens, contradicts, or has no bearing on the company’s actual competitive position is a different question.
Now assume the company already maintains a segmented view of the market, with buying criteria, competitive axes, competitor positions, and its own strengths and gaps.
The starting point changes.
The agent does not have to ask, “What is logistics automation?” again. It starts from an existing view of the market and determines which part of that Lens the new work activates.
This is the practical value I see in turning enterprise MI into a Search Agent Skill.
Without a Market Lens, Web Search explains the market. With a Market Lens, Web Search can focus on what this company needs to verify about the market.
The next step would be to extract strategic signals from the RFP, form research questions, and test them against current competitor and market evidence. That is deliberately outside this article; it is the subject of the next one.
Canon is a time-bounded baseline, not eternal truth
Calling the Lens “canonical” can create the wrong impression.
Canon does not mean immutable truth.
Suppose last year’s analysis described a competitor as strong in equipment but weak in software-control integration evidence. That may have been a reasonable conclusion based on the evidence available at the time. If the competitor has since launched a new platform and secured large references, the Lens should not remain frozen.
The Lens therefore needs a time axis.
Canon at t0 → Temporal Gap → Current Evidence at t1 → Candidate Delta
This also clarifies the role of Web Search.
The agent is not being asked to define the market from scratch. It is asking:
What has changed since our last validated baseline?
Web Search can be viewed broadly as retrieval-augmented context expansion: it brings external knowledge into the current working context. But the tool is not the most important part. What matters first is which baseline the agent trusts and which changes are material enough to challenge it.
Fresh does not mean canonical
There is an equal and opposite risk.
Finding new web evidence should not automatically rewrite the Canon.
A single competitor press release, an unverified market article, or a product roadmap that has not been proven in production should not immediately replace a well-established Lens.
A safer lifecycle looks more like this:
Web Evidence → Provenance / Date Validation → Candidate Delta → LINT against Canon → Keep / Supersede / Promote / Reject
This is also where the responsibility boundary between the LLM and deterministic runtime matters.
An LLM is well suited to reading a new source, comparing claims semantically, detecting contradictions, and proposing a candidate delta.
But source identity, observation date, provenance class, current version, and the state that says which claim has actually been promoted to Canon are better kept deterministically.
The LLM may interpret the Lens and propose how it should change. The system should track what the current Canon actually is.
A Search Agent that becomes more specific to the enterprise over time
The interesting part of this architecture is that it does more than improve one search.
New market sources arrive. Customer patterns change. Competitor capabilities evolve. Internal win/loss experience accumulates. The Wiki is linted. Validated changes improve the Market Lens. The next deal starts from that stronger Lens.
Simplified:
Enterprise Evidence → Wiki → LINT / Reconcile → Market Lens Skill → New Work → New Evidence → Next LINT
Seen this way, enterprise MI material is not just another RAG corpus.
Managed well, it becomes the coordinate system through which an agent observes the external world.
And that coordinate system is not finished when a report is published. It gets its focus adjusted as new evidence and operating experience accumulate.
A strong Enterprise Research Agent does not relearn the world from scratch every time.
It is closer to an agent that remembers the company’s accumulated view of the market, while continuously questioning whether that view is still valid.
The next article will go one level deeper.
Once the Canonical Market Lens exists and a new RFP arrives, which signals should be extracted? Which research questions should be generated? And how can Web Search become a mechanism for strengthening, weakening, or invalidating an existing strategic hypothesis, rather than a generic information-gathering exercise?
At that point, the problem is no longer how to build the Lens.
It is how to use it.