From Forward Deployed Engineers to LLM Wikis: The New Demands Reshaping Software Houses

The software market is entering a new phase.

For years, companies hired software houses mainly to build websites, mobile apps, internal systems and digital platforms. Those needs continue to exist, but a new category of projects is emerging—one in which the challenge is not simply writing code.

Organizations now need technology partners that can:

• Work directly with business and operational teams;
• Understand complex internal processes;
• Connect artificial intelligence to proprietary company data;
• Modernize existing systems without interrupting operations;
• Create reliable knowledge layers for AI agents;
• Evaluate and improve AI systems after deployment;
• Turn experimental AI initiatives into production-grade software.

Concepts such as Forward Deployed Engineers, LLM wikis, AI agents, context engineering and agentic software development are becoming increasingly relevant.

Although the terminology is new, the underlying demand is familiar: companies need multidisciplinary technology teams that can combine business understanding, software engineering, data integration and continuous operation.

This places experienced software houses in a uniquely strong position.

What is a Forward Deployed Engineer?

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

Instead of receiving a fixed specification and developing the project from a distance, an FDE works alongside business, product and technology teams. The engineer helps identify the problem, design the architecture, integrate systems, write production code and adapt the solution as new information emerges.

OpenAI describes its Forward Deployed Engineers as professionals responsible for leading complex, end-to-end deployments of frontier models in production alongside strategic customers. Palantir has used a similar operating model for years, with engineers working directly on customer-specific data and integration challenges.

An FDE is therefore not simply an outsourced developer.

The role combines elements of:

• Software engineering;
• Solution architecture;
• Product discovery;
• Technical consulting;
• Data integration;
• Customer success;
• Operational problem-solving.

This model is especially relevant for AI projects because the requirements are rarely completely known at the beginning.

A company may know that it wants to use artificial intelligence to improve customer support, analyze contracts or automate internal processes. However, identifying the correct data sources, workflows, permissions, interfaces and evaluation criteria usually requires close collaboration between technical specialists and the people who run the operation.

Why software houses are well positioned to deliver FDE-style projects

The FDE model may appear to be a new category of service, but experienced software houses already possess many of the capabilities it requires.

A full-service software house typically combines:

• Business and product discovery;
• UX and interface design;
• Front-end and back-end development;
• API and system integrations;
• Cloud infrastructure;
• Quality assurance;
• Maintenance and monitoring;
• Dedicated teams and staff augmentation.

The difference is primarily in how these capabilities are organized.

Instead of following a rigid scope, an FDE-style team works continuously with the client, moving between discovery, implementation, validation and improvement.

Espresso Labs already operates across the complete software lifecycle, including discovery and design, custom software development, maintenance and hosting, staffing and outsourcing, and applied AI solutions.

This structure makes it possible to create embedded, multidisciplinary teams that understand both the technology and the business context behind the project.

What is an LLM wiki?

An LLM wiki is an emerging approach for organizing company knowledge so that it can be efficiently accessed and maintained by large language models and AI agents.

Traditional Retrieval-Augmented Generation, or RAG, commonly divides documents into smaller pieces and retrieves relevant excerpts when a user asks a question.

An LLM wiki introduces an additional structured knowledge layer.

Instead of relying only on isolated document fragments, the system can transform raw information into organized pages covering entities, concepts, processes, products, customers and internal rules. These pages can be connected through links and updated as new information becomes available.

Recent research describes LLM wikis as structured, composable and self-evolving knowledge systems designed for AI agents. Rather than treating retrieval as a single search operation, agents can search, read, follow connections and determine when they have collected enough evidence to answer a question.

For example, a company’s LLM wiki could contain interconnected pages for:

• Products and features;
• Customers and contracts;
• Internal procedures;
• Technical architecture;
• Business rules;
• Support incidents;
• Regulatory requirements;
• Decisions made during previous projects.

An AI agent could then use this structure to answer questions, support employees, prepare reports or execute authorized workflows.

LLM wikis do not eliminate the need for good engineering

An LLM wiki should not be treated as a universal replacement for RAG, databases or document management systems.

The best architecture depends on the quantity of information, frequency of updates, security requirements and types of questions the system must answer.

Research into LLM wiki architectures also identifies a “compilation gap”: when documents are summarized into a structured wiki, important facts may be lost unless the system includes evaluation and refinement mechanisms.

Building a reliable enterprise LLM wiki therefore involves much more than connecting documents to an AI model.

It may require:

• Data ingestion pipelines;
• Permission and identity management;
• Document classification;
• Entity extraction;
• Version control;
• Source references;
• Automated evaluations;
• Human approval workflows;
• Monitoring and audit trails;
• Integration with internal systems.

These are fundamentally software engineering challenges.

Context engineering: giving AI the right information

Another important trend is context engineering.

In conventional software development, engineers focus primarily on writing instructions in programming languages. In AI-native systems, they must also design the environment in which an AI model receives information and makes decisions.

Context engineering involves determining:

• Which instructions the model should receive;
• Which documents and data it can access;
• Which tools it can use;
• Which previous interactions it should remember;
• How results should be validated;
• What the model should do when information is missing;
• When a human must review or approve an action.

The growing importance of context engineering reflects a broader shift from isolated prompts to complete systems surrounding AI models. Thoughtworks has highlighted context engineering as a central discipline for building more reliable coding agents and AI-assisted development workflows.

For companies, this means that implementing AI is no longer just a matter of choosing a model.

The surrounding software—the integrations, permissions, interfaces, workflows, monitoring and evaluation mechanisms—is often what determines whether an AI initiative succeeds.

From chatbots to AI agents connected to real operations

The first generation of corporate generative AI projects focused heavily on chat interfaces.

The next generation is increasingly focused on AI agents capable of interacting with business systems.

An agent might:

• Search internal documentation;
• Read information from a CRM or ERP;
• Prepare a customer proposal;
• Update an internal record;
• Analyze a support request;
• Generate a report;
• Request approval from an employee;
• Trigger an authorized workflow.

However, moving from a chatbot to an operational agent significantly increases technical and governance requirements.

The system must control what the agent can access, which actions it can perform and how every result is reviewed or audited.

This is why AI agents should be developed as complete software products rather than isolated model integrations.

Spec-driven and AI-assisted software development

Artificial intelligence is also changing how software itself is built.

Coding assistants can generate functions, tests, documentation and initial implementations. More advanced agents can work across multiple files and execute development tasks with increasing autonomy.

This has created interest in practices such as spec-driven development, in which requirements, architecture decisions, expected behaviors and constraints are documented in a format that both human developers and AI agents can interpret.

The objective is not to remove engineers from the process.

It is to provide enough structure for AI tools to accelerate implementation without sacrificing maintainability, security or architectural coherence. Current discussions around AI-assisted development emphasize that strong specifications, context and engineering controls become more important—not less—as coding agents become more capable.

At Espresso Labs, AI is used as an acceleration tool while human professionals remain responsible for architecture, quality, security and the final result. The company’s approach combines applied AI with human review and customer control over data.

Legacy system modernization for the AI era

Many companies want to implement AI but first encounter a more fundamental problem: their data and workflows are trapped inside legacy systems.

The system may lack APIs, documentation, automated tests or a modern permission structure. In other cases, business rules exist only in source code, spreadsheets or the knowledge of a few employees.

Before introducing AI agents or an LLM wiki, the company may need to:

• Map existing systems and data sources;
• Create secure APIs;
• Improve identity and access controls;
• Document business rules;
• Separate parts of a monolithic architecture;
• Introduce monitoring and automated testing;
• Establish a reliable data layer.

Modernizing a legacy system does not necessarily require replacing everything.

A gradual strategy can expose specific capabilities through APIs, migrate individual modules and introduce new interfaces while the core operation continues running.

This combination of modernization, integration and applied AI is likely to become one of the most important areas for software houses over the next few years.

The software house is becoming an implementation partner

The market is moving away from a simple distinction between software vendors and consulting firms.

The new demand is for implementation partners: teams that can understand the business problem, recommend an architecture, build the solution and remain involved while it evolves in production.

This includes:

• FDE-style embedded engineering;
• LLM wikis and enterprise knowledge systems;
• AI agents connected to internal tools;
• Custom RAG architectures;
• Context engineering;
• AI evaluation and observability;
• Legacy system modernization;
• AI-assisted software development;
• Continuous maintenance and improvement.

These projects require more than a model API and a prototype.

They require the same disciplines that have always defined reliable software: good architecture, secure integrations, understandable code, quality assurance, monitoring and close collaboration with users.

The names of the services may be changing. The need for responsible engineering is not.

How Espresso Labs supports this new generation of projects

Espresso Labs combines the capabilities required to take AI initiatives from initial idea to production:

Discovery and technical assessment

The team maps the business problem, users, existing systems, available data and technical constraints before defining the solution.

Custom software and AI development

Espresso Labs develops web and mobile applications, internal platforms, APIs, integrations, AI assistants, knowledge systems and automation tools.

Embedded engineers and dedicated teams

Companies can reinforce their internal structure with individual specialists or multidisciplinary squads working closely with their teams.

Legacy modernization and integration

Existing systems can be modernized gradually, with new APIs, modules and interfaces introduced without unnecessarily disrupting critical operations.

Maintenance, monitoring and continuous improvement

After deployment, systems can continue to be monitored, corrected and expanded as business requirements and AI models evolve.

Frequently asked questions

What is a Forward Deployed Engineer?

A Forward Deployed Engineer is a technical professional who works directly with a customer to understand operational challenges and implement software in the customer’s real environment. The role combines engineering, consulting, integration and product discovery.

What is the difference between an FDE and an outsourced developer?

An outsourced developer generally joins an existing development process and receives defined tasks. An FDE typically takes broader responsibility for understanding the problem, designing the solution, integrating systems and adapting the implementation based on real operational feedback.

What is an LLM wiki?

An LLM wiki is a structured knowledge layer created for large language models and AI agents. It transforms documents and data into organized, interconnected pages that can be searched, read and updated by AI systems.

Is an LLM wiki the same as RAG?

No. Traditional RAG retrieves relevant fragments from documents. An LLM wiki organizes knowledge into structured and connected pages. The two approaches can also be combined within the same architecture.

Can AI agents be connected to legacy systems?

Yes, but secure APIs, access controls, monitoring and clear business rules are usually required. In many cases, part of the legacy environment must be documented or modernized before agents can interact with it safely.

Why hire a software house for an AI project?

A software house can manage the complete implementation around the AI model, including discovery, interface design, software development, integrations, cloud infrastructure, security, testing, monitoring and ongoing maintenance.

Conclusion

Forward Deployed Engineers, LLM wikis, context engineering and AI agents are not isolated trends.

Together, they represent a broader transformation in how companies adopt technology.

The most valuable technology partners will not simply deliver code or provide access to an AI model. They will work alongside the organization, understand its operation, connect systems and data, and remain responsible for making the solution work in practice.

That is the opportunity for the next generation of software houses—and it is already part of how Espresso Labs approaches complex technology projects.