Topics / Enterprise AI
The architecture behind AI that works.
From changing knowledge work and software development to search across company knowledge: what matters is which problem you are solving and how it turns into reliable results.
Strategy & Delivery
Enterprise AI: From Strategy to Delivery
Enterprise AI connects models with company knowledge, processes and clear accountability. A convincing demo first answers whether an approach can work in principle. A product also has to fit into existing systems and deliver measurable value in everyday work.
When the topic becomes relevant.
The entry point is a specific process or decision: which task should improve, who uses the result, and how is the impact measured? These answers define the requirements for data, architecture, team and operations – and narrow down the technical solution space.
What matters in practice.
Picking a technology too early easily leads to a system without a clear purpose. A pilot without owners for quality, adoption and further development is just as problematic. That is why the business case and the architecture should grow together.
Knowledge Architecture
Knowledge Graphs & Neo4j
A knowledge graph represents knowledge as entities and relationships. Products, versions, components, issues and responsible teams are linked explicitly. Neo4j is one possible technical building block for storing and querying such graphs.
When the topic becomes relevant.
A graph is especially useful when the relationships themselves are key to answering a question: which instructions apply to this product version? Which team owns the affected component? Combined with retrieval, this structure can help narrow down which sources are relevant.
What matters in practice.
A graph does not resolve unclear terminology on its own. Without domain modeling, provenance for each statement and rules for keeping it current, it becomes yet another data store that is hard to maintain. Not every search question needs a graph; the added value has to show in the specific use case.
Agentic Architecture
AI Agents & LangGraph
Agentic systems combine model-driven decisions with tools and defined workflows. LangGraph is one possible building block for modeling the states and transitions of such a workflow explicitly. That makes the decisions between request and result describable.
When the topic becomes relevant.
The design starts with the task: which steps are fixed, and where does a flexible decision make sense? Tools, required information and human approvals get clear boundaries. An agent is one part of the overall system – not automatically its center.
What matters in practice.
More autonomy does not automatically mean more value. Unlimited tool permissions, missing stop conditions and untested failure cases make a workflow hard to control. Evaluation and observability therefore belong in the very first architecture draft.
Work & Collaboration
Working with AI: From Tool to New Workflow
AI changes more than individual tasks. It changes how people work together: describing tasks, providing context, reviewing results and taking responsibility for them. Practical examples with Claude Code, Codex and Cowork make these shifts tangible – without turning any tool into an end in itself.
When the topic becomes relevant.
The topic matters once teams are already experimenting but have not yet found a shared way of working. The starting point is recurring work and three questions: where does support make sense, what information does it need, and who can judge the result?
What matters in practice.
A result produced quickly is not yet a reliable work product. Confidentiality, access rights and expert review have to remain part of the process. We agree on examples and available tools in advance; sensitive company data is not required.
Engineering & Delivery
Agentic Coding: From Prompt to Software Factory
Agentic coding treats AI assistance as part of a development process rather than a collection of individual prompts. A software factory is not a promise of autonomous production. It is a coordinated flow of task definition, implementation, tests, review and release.
When the topic becomes relevant.
The approach becomes relevant when a team wants to move from occasional experiments to reproducible development. A harness is the technical and organizational frame around it: work environment, instructions, tool access, checks and feedback.
What matters in practice.
More code generated in parallel does not automatically make better software. Without clear tasks, solid tests and traceable approvals, review effort and the risk of defects go up. The degree of automation has to fit the codebase, the team and the security requirements.
Search & Retrieval
Enterprise Search: BM25, Vector or Graph?
Enterprise search connects questions with the right company knowledge. BM25 weights lexical matches, vector search looks for similarity in an embedding space, and graph-based approaches use explicit relationships. Each method solves a different part of the search problem.
When the topic becomes relevant.
Choosing an approach starts with real questions and representative sample documents. Exact terms, paraphrases and relationships between products or versions place different demands on retrieval. Hybrid approaches can combine these signals; their value has to show on your own questions.
What matters in practice.
There is no universal winner between BM25, vectors and graphs. Document quality, permissions, freshness, effort and how results are judged all shape the outcome. One convincing example query is no substitute for a systematic comparison.
The tool follows your task.
These terms help describe an architecture. The decisive question remains which problem you want to solve and what your organization already brings to the table.
Explore the Architecture Assessment