Kristof Van Tomme

The through-line

Everything here circles one question: how does an organisation make its capabilities understandable and findable by the people who need them, and who is responsible when that fails. The starting point was technical documentation, specifically the problem of reuse and delivery across different channels, which led on to graph databases as a way of serving people the right information based on who they are [14][15]. That same concern later hardened into a business practice, developer portal consulting and implementation approached as a single domain to be studied deeply through research, community engagement and industry events [13]. The most recent thinking extends the line to machine consumers: MCP servers, AI-mediated discovery, and AI-native documentation workflows [1][3][12].

The constant across all of it is a refusal to let internal structure dictate external interface. Documentation should be assembled around the reader rather than around where it was authored [14][15]; APIs and MCP servers should be bundled around what customers need rather than around the organisation's historical domain model [1]; and the business meaning of a capability is not the property of whoever happens to have built it [5].

On deliberate boundaries and the MCP moment

The case against letting your organisation's historical domain model define your interface architecture is that it exposes your customers to your internal complexity and produces a suboptimal Developer eXperience [1]. This is the frame applied to MCP: roughly three architectures exist depending on how you package capabilities, and translating an existing API landscape one-to-one into MCP servers is the easy choice rather than the right one [1]. The framing is that "MCP gives you another chance to rethink your capability bundles" [1], a second opportunity to make a deliberate boundary choice rather than inheriting one. The fact that hosts can compose capabilities as needed does not remove the obligation to package them well in the first place [1].

On who owns the business meaning of APIs

The ownership question is posed deliberately as uncomfortable, because the answer is not a single role and the work will remain collaborative, with no single team seeing the whole situation from a neutral position [5]. What resolves it is consequence rather than org chart: "if a business line depends on digital capabilities being understood and adopted, then business leadership owns the consequence of whether this system works" [5]. That does not mean business leadership should own the portal. It means they need a clear enough view of the relationships between the API program, the developer portal, the solution content, competitor positioning, and AI-mediated discovery to decide what should happen next [5].

On AI-mediated discovery and share of voice

AI-mediated discovery is treated as one of the relationships business leadership has to hold in view alongside the portal and competitor positioning [5], and it has a measurable surface. The relevant question for an API program is what its brand's share of voice is for the program's core capabilities, an input into an AI visibility strategy rather than a vanity metric [3]. The reporting exists to help customers decide whether to work with Pronovix in the first place [3].

On AI-native documentation workflows

The open problem in AI-native work is not generation, it is coordination. The specific gap is how to coordinate between roles to create effective business docs that complement API descriptions [12], which places the difficulty in the seam between the reference material a machine can emit and the explanatory material that makes a capability adoptable. The Workflow Lab is framed as an invitation to people already working on AI-native workflows for their API documentation rather than as a finished method [12]. Context-aware engineering agents, and the move beyond code generation, sit in the same territory [8].

On Drupal, context engineering and human review

There is an emerging idea of a role for Drupal in an open source context engineering stack, where Drupal's value is that it would allow non technical users to review generated entities before they are added to a graph database such as Neo4j [6]. The economics are acknowledged rather than assumed away: this only makes sense for key entities where the review costs and efforts make business sense [6]. The engineering status is honest about its own limits. A proof of concept exists for content augmentation, adding AI generated fields to an entity with a markdown body, but a one-to-many generated entities proof of concept has not been done, though ECA looks like a plausible route [6]. The open call is for anyone who has built an entity extraction pipeline in Drupal for a similar purpose [6]. The same curiosity about the Drupal and AI intersection runs both directions, in Drupal applications that leverage AI and AI applications that leverage Drupal [2].

On personalised documentation and the Clippy problem

The interest in graph databases came directly out of documentation, from the problem of reuse and delivery across different channels [14][15]. What a graph makes possible is personalised, context-aware delivery, a system that serves users the right information based on who they are [14][15]. The reference point is Clippy: the ambition was right and the execution failed, and the technology may now be able to realise what Microsoft's assistant was reaching for [14][15]. The path into this work ran from bioengineering into IT through a biotech startup and then into the Drupal open source community [14][15].

On specialisation and digital proximity

The strategic position is deliberate narrowness. Pronovix specialises exclusively in developer portal consulting and implementation, and the differentiation comes from going deep into that single domain via research, community engagement and industry events [13]. The demand for that depth has a stated cause: COVID-19 acted as a catalyst that accelerated the shift from physical proximity to "digital proximity" [13]. Companies had to transform their digital interactions and their business models, and developer portals and APIs were the mechanism that made the transition possible [13].

On building the field in public

The community work is not separate from the consulting; it is the research method [13]. That shows up as MC-ing conference rooms and programming sessions on self-service integration platforms and context-aware engineering agents [8][10][11], as running the annual call for developer portal nominations [9], as opening calls for speakers on Drupal and AI [2], and as amplifying colleagues' and peers' writing rather than only one's own [3][5][7]. The MCP boundary argument itself is built by combining a colleague's article on publishing MCP servers on developer portals with Daniel Kocot's article on deliberate versus natural DDD boundary choice [1], and the context engineering stack idea came out of interviewing Daniel Kocot for the API Resilience podcast and then being pushed on it by Michael Hunger [6].

Takeaways

• Do not translate an existing API landscape one-to-one into MCP servers; treat MCP as another chance to rethink your capability bundles, since roughly three architectures exist depending on how you package capabilities [1].
• An interface built on your historical domain model exposes customers to your internal complexity and degrades Developer eXperience [1].
• Nobody owns the business meaning of APIs alone, but business leadership owns the consequence, and needs a view across the API program, the developer portal, the solution content, competitor positioning, and AI-mediated discovery [5].
• Measure share of voice for your API program's core capabilities as the concrete entry point to an AI visibility strategy [3].
• The hard part of AI-native documentation is coordinating between roles to produce business docs that complement API descriptions, not generating reference material [12].
• Human review of AI generated entities before they enter a graph database is worth building only for key entities where the review cost makes business sense [6].
• Graph databases make context-aware documentation possible, serving people the right information based on who they are, which is what Clippy was reaching for and failed to deliver [14][15].
• COVID-19 accelerated the shift from physical to "digital proximity", forcing changes to digital interactions and business models with portals and APIs as the enabling layer [13].