Understanding LLM Wikis, FDEs and Other Terms Shaping the AI Era

Artificial intelligence has introduced an entirely new vocabulary into business and technology conversations.

Companies are now being told that they need AI agents, Retrieval-Augmented Generation, context engineering, LLM wikis, MCP integrations and Forward Deployed Engineers.

The problem is that these terms are often used before their practical meaning is properly explained.

Some describe technologies. Others describe architectural approaches, engineering roles or methods for implementing AI inside an organisation.

Understanding the difference matters.

A business does not necessarily need every new AI concept. It needs to identify which combination of models, data, software and people can solve a specific operational problem.

This guide explains some of the most important terms shaping the current AI market—and what they mean for companies considering a real implementation.

1. What is an LLM?

An LLM, or Large Language Model, is an artificial intelligence model trained to understand and generate language.

LLMs power many modern AI assistants and can perform tasks such as:

• Answering questions;
• Summarising documents;
• Extracting information;
• Classifying text;
• Generating reports;
• Writing software code;
• Translating content;
• Supporting business workflows.

An LLM is the intelligence component of an AI solution, but it is rarely the complete solution.

A production system also needs interfaces, data connections, user permissions, business rules, monitoring and mechanisms to verify the model’s output.

This distinction is important because giving employees access to a general-purpose AI assistant is not the same as implementing AI within a business process.

2. What is RAG?

RAG stands for Retrieval-Augmented Generation.

It is an architecture that allows an AI model to consult external information before producing an answer.

Without RAG, an LLM primarily relies on the information learned during its training and the content included directly in the conversation.

With RAG, the application can search a defined collection of documents or records, retrieve relevant passages and give them to the model as additional context.

For example, a RAG system could allow an employee to ask:

• What does our internal travel policy say?
• Which support procedure applies to this customer?
• What are the conditions in this contract?
• How should this machine be maintained?
• Which regulations apply to this product?

A conventional RAG pipeline usually divides documents into smaller pieces, often called chunks. When a question is submitted, the system searches for the chunks most likely to contain the answer.

RAG is useful when the information changes frequently, is specific to the company or should not be permanently embedded in the model.

However, retrieving a few relevant fragments does not always give the AI enough structure to understand relationships across multiple documents.

That is one of the problems that LLM wikis attempt to address.

3. What is an LLM wiki?

An LLM wiki is a structured knowledge base designed to be searched, read and, in some cases, maintained by AI agents.

Instead of storing company knowledge only as independent document fragments, an LLM wiki organises information into connected pages.

A page might describe:

• A customer;
• A product;
• A business process;
• A technical system;
• An internal policy;
• A contract;
• A recurring support problem;
• A decision made during a project.

These pages can contain links to related concepts and references to the original sources.

Recent research describes the LLM wiki model as an agent-native approach in which documents are transformed into structured pages with bidirectional links. The agent can search, read and follow these links while determining whether it has collected enough evidence to answer a question.

How is an LLM wiki different from traditional RAG?

Traditional RAG normally retrieves individual document fragments based on their similarity to the user’s question.

An LLM wiki attempts to give the AI a more organised representation of knowledge.

For example, when investigating a recurring customer problem, an agent might move between pages describing:

1. The customer;
2. The product being used;
3. Previous support incidents;
4. The relevant service agreement;
5. The technical component causing the problem.

The difference can be summarised as follows:

• RAG retrieves relevant pieces of information;
• An LLM wiki organises knowledge so that an agent can navigate relationships.

The two approaches are not mutually exclusive. A system may use RAG to locate source documents while also maintaining a structured wiki for frequently used knowledge.

What are the risks of an LLM wiki?

An LLM wiki is not automatically accurate.

When an AI model converts documents into summaries or structured pages, important details can be omitted or simplified incorrectly.

Research into LLM wiki compilation has identified this as a significant challenge: blindly converting raw documents into a wiki may discard critical facts unless the system includes evaluation and refinement mechanisms.

A business implementation therefore needs:

• Links to original sources;
• Version management;
• Permission controls;
• Processes for updating information;
• Automated evaluations;
• Human review for critical content;
• Clear ownership of the knowledge base.

4. What is an AI agent?

An AI agent is a software system that uses an AI model to decide which steps to take toward a goal.

A normal chatbot responds to a message.

An agent may perform a sequence of actions.

For example, an agent could:

1. Receive a customer support request;
2. Search internal documentation;
3. Look up the customer’s account;
4. Analyse previous incidents;
5. Draft a response;
6. Create a support ticket;
7. Ask an employee to approve the action.

The agent does not merely generate text. It interacts with tools and systems.

This makes AI agents potentially more useful, but also more complex and risky.

A production agent needs strict controls around:

• Which data it can access;
• Which tools it can use;
• Which actions it can execute;
• When human approval is required;
• How every action is logged;
• What happens when the model is uncertain.

The best business use cases are usually narrow and measurable. An agent designed to complete a well-defined process is easier to evaluate and control than an open-ended “AI employee”.

5. What is a Forward Deployed Engineer?

A Forward Deployed Engineer, or FDE, is an engineer who works closely with a customer to implement technology inside the customer’s real operating environment.

The role sits between software engineering, technical consulting, product discovery and implementation.

Instead of receiving a complete specification and building the system at a distance, an FDE helps investigate the problem, define the solution, integrate existing systems and support production adoption.

OpenAI describes its Forward Deployed Engineers as responsible for end-to-end model deployments, including discovery, technical scoping, system design, development and production rollout alongside customer teams.

An FDE may:

• Interview users and operational teams;
• Map existing processes;
• Examine the company’s systems and data;
• Build integrations and production software;
• Test the solution in real workflows;
• Measure adoption and business impact;
• Adjust the implementation based on feedback.

How is an FDE different from an outsourced developer?

An outsourced developer usually receives tasks within an existing project structure.

An FDE generally has broader responsibility for identifying what should be built and ensuring that it works in practice.

The difference is not only technical seniority. It is proximity to the business problem.

The FDE model is particularly relevant for AI because many requirements only become clear after the system interacts with real data, users and processes.

6. What is context engineering?

Context engineering is the practice of designing the information and tools available to an AI model while it performs a task.

A prompt is only one part of that context.

The complete context may include:

• System instructions;
• Company documents;
• User information;
• Previous interactions;
• Database records;
• Available tools;
• Examples of good answers;
• Business rules;
• Output formats;
• Security restrictions.

Consider an AI assistant that analyses contracts.

Its performance depends not only on the wording of the prompt, but also on whether it receives:

• The correct contract version;
• The company’s standard clauses;
• Applicable regulations;
• The customer’s commercial context;
• Instructions on which risks to flag;
• A structured format for its analysis.

Context engineering is therefore closer to system design than to simply writing better prompts.

7. What is MCP?

MCP stands for Model Context Protocol.

It is an open standard for connecting AI applications to external data sources, tools and workflows. Official MCP documentation compares the concept to a standardised connector through which AI applications can access systems such as databases, files, APIs and business tools.

Before protocols such as MCP, developers often created a different custom integration for every combination of AI model and external tool.

MCP provides a common structure for exposing:

• Resources the AI can read;
• Tools the AI can execute;
• Reusable prompts or workflows;
• Authentication and access mechanisms.

For example, an MCP server might allow an authorised AI application to:

• Read documentation from an internal repository;
• Search a product database;
• Query a CRM;
• Create an issue in a project management system;
• Retrieve system monitoring data.

MCP does not automatically make an integration secure or reliable. Permissions, authentication, data validation and logging still need to be designed correctly.

8. What are AI evals?

Evals, short for evaluations, are structured tests used to measure how well an AI system performs.

Traditional software can often be tested using deterministic rules: a specific input should produce a specific output.

AI systems are less predictable. Two answers can use different words while both being correct—or appear convincing while containing factual errors.

AI evaluations may measure:

• Answer accuracy;
• Completeness;
• Correct use of sources;
• Compliance with instructions;
• Classification quality;
• Tool-selection accuracy;
• The number of tasks completed successfully;
• The frequency of unsafe or unauthorised actions;
• Cost and response time.

An evaluation set should contain realistic examples from the company’s actual workflows.

Without evals, teams often judge AI systems based on a few impressive demonstrations. That is not enough to determine whether the solution is reliable in production.

9. What are guardrails and human-in-the-loop systems?

Guardrails are technical and operational controls that limit what an AI system can do.

Examples include:

• Blocking access to restricted information;
• Validating data before it is sent to a model;
• Limiting which tools an agent can use;
• Requiring confirmation before important actions;
• Checking outputs for sensitive information;
• Restricting actions based on the user’s role;
• Recording activity in an audit log.

A human-in-the-loop process requires a person to review or approve certain decisions.

For example, an AI system may prepare a payment instruction, but a finance employee must approve it before execution.

The required level of human involvement depends on the risk.

An internal document summary may need little supervision. A decision involving payments, contracts, healthcare, employment or critical infrastructure requires much stronger control.

These terms describe parts of a system—not complete solutions

LLMs, RAG, LLM wikis, MCP, agents and evals are not competing products.

They describe different layers of an AI system.

A simplified enterprise architecture might work like this:

1. An LLM provides language and reasoning capabilities;
2. RAG retrieves relevant source documents;
3. An LLM wiki organises recurring knowledge and relationships;
4. Context engineering determines which information reaches the model;
5. MCP or custom APIs connect the model to business tools;
6. An AI agent coordinates a sequence of actions;
7. Evals measure whether the system works;
8. Guardrails control risk;
9. An FDE or implementation team brings the complete solution into production.

Not every company needs every layer.

The correct architecture depends on the business process, existing systems, available data and level of risk.

Start with the business problem, not the terminology

The most common mistake in AI projects is starting with a technology because it is receiving attention.

A company hears about AI agents and decides it needs one. Only later does it try to identify what the agent should do.

A better process starts with questions such as:

• Which process is currently slow or expensive?
• Where do employees repeatedly search for information?
• Which decisions depend on fragmented data?
• Which manual steps could be automated safely?
• What would measurable improvement look like?
• What systems and data would the solution need?
• What could go wrong if the AI makes a mistake?

Only after answering these questions should the company choose the architecture.

The best solution might be an agent, but it could also be a simpler search interface, a workflow automation, a conventional software improvement or better system integration.

How Dink approaches enterprise AI

Dink approaches AI implementation as a business and software engineering challenge rather than as a standalone model experiment.

Its process begins by analysing the company’s processes, systems, data sources and technical environment. From there, the appropriate solution may involve an AI agent, workflow automation, an AI-powered application or a custom platform.

The implementation is then monitored and improved based on adoption, performance and business impact. Dink also combines tailored AI upgrades with technology assessments, custom software development and long-term maintenance of existing systems.

This is especially important for companies with legacy environments.

The organisation may not need to replace its central system. It may need to document it, create secure integrations, expose selected data and introduce AI gradually around the existing operation.

Frequently asked questions

Is an LLM wiki better than RAG?

Not universally. RAG is effective for retrieving information from large or frequently updated document collections. An LLM wiki may be useful when agents need to navigate structured relationships and repeatedly use accumulated knowledge. Some systems combine both approaches.

Does an AI agent operate without human supervision?

It can perform predefined actions autonomously, but higher-risk processes should include approvals, restrictions and audit mechanisms. Autonomy should be proportional to the consequences of an error.

Does a company need an FDE to implement AI?

Not necessarily as a formal job title. However, complex projects benefit from engineers who work closely with business users and take responsibility from discovery through production deployment.

Is MCP required for AI integrations?

No. Companies can continue using conventional APIs and custom integrations. MCP offers a standardised method that may reduce integration duplication, but it does not replace good security and architecture.

Can AI be added to a legacy system?

Yes. Secure APIs and integration layers can often introduce AI capabilities without replacing the entire system. A technical assessment should identify data quality, security, architecture and operational constraints first.

Conclusion

The vocabulary surrounding artificial intelligence will continue to evolve.

Some terms will become permanent parts of software engineering. Others may be replaced as architectures and models change.

Companies do not need to follow every new trend.

They need to understand what each concept does, which business problem it addresses and what is required to make it reliable in production.

The real competitive advantage does not come from using the newest terminology. It comes from combining the right technology, data, software architecture and implementation expertise to produce a measurable result.