DSupport
An open-source AI customer-service system built on Kotlin Multiplatform. It does not use an agent framework; RAG, MCP and multi-agent orchestration are written from scratch. Clean Architecture is adopted to strictly separate models from deterministic code.
Timeline (last 90 days)
DSupport is an AI customer service project built with Kotlin Multiplatform, created by developer Diego Ferreira Caetano, which hand-writes RAG, MCP and multi-agent orchestration from scratch without using any agent framework.
DSupport's architecture divides responsibilities as follows: the model (non-deterministic) handles understanding natural language, deciding which tool to call, drafting replies, and routing between experts; the code (deterministic) handles validating types and rules, hiding sensitive data, blocking operations that must not be allowed through, and running offline tests.
In DSupport, 5 roles use the model and 14 components are pure code; the latter include guardrails, validators, TF-IDF retrieval, tools, MCP transport, tracing, and evaluation scoring.
DSupport adopts Clean Architecture and Ports & Adapters; its modules include contract, core, adapters, mcp-orders, mcp-tickets, cli, server, app, and eval, with dependencies pointing only inward.
DSupport's core module knows the model through the LlmClient interface, which contains two methods: next (returns text or a tool-call request) and structured (forces the model to fill in a JSON form); switching to Claude only requires writing a new adapter.
DSupport has more than 380 tests, all of which run offline, and not a single test consumes API quota.
DSupport's agent loop uses repeat(maxTurns) to set a turn limit, preventing the model from calling indefinitely; when the limit is reached, the code returns an escalation-to-human message rather than letting the model decide on its own.
DSupport's tool calls are executed in parallel via async + awaitAll, with results filled back in request order because the model API requires the correspondence.
DSupport's RAG implementation splits articles by paragraph, uses TF-IDF for word-weight vectorization, optionally integrates VoyageEmbedder for semantic retrieval, and uses a relevance cutoff of minScore = 0.25 in SearchKbTool.
In DSupport, when the RAG results are empty after filtering, the tool returns nothing_relevant_found, and the knowledge expert is required to answer NO_ANSWER rather than fabricate an answer.
5 more timeline events
All Facts (15)
DSupport is an AI customer service project built with Kotlin Multiplatform, created by developer Diego Ferreira Caetano, which hand-writes RAG, MCP and multi-agent orchestration from scratch without using any agent framework.
50%UnverifiedDSupport's architecture divides responsibilities as follows: the model (non-deterministic) handles understanding natural language, deciding which tool to call, drafting replies, and routing between experts; the code (deterministic) handles validating types and rules, hiding sensitive data, blocking operations that must not be allowed through, and running offline tests.
50%UnverifiedIn DSupport, 5 roles use the model and 14 components are pure code; the latter include guardrails, validators, TF-IDF retrieval, tools, MCP transport, tracing, and evaluation scoring.
50%UnverifiedDSupport adopts Clean Architecture and Ports & Adapters; its modules include contract, core, adapters, mcp-orders, mcp-tickets, cli, server, app, and eval, with dependencies pointing only inward.
50%UnverifiedDSupport's core module knows the model through the LlmClient interface, which contains two methods: next (returns text or a tool-call request) and structured (forces the model to fill in a JSON form); switching to Claude only requires writing a new adapter.
50%UnverifiedDSupport has more than 380 tests, all of which run offline, and not a single test consumes API quota.
50%UnverifiedDSupport's agent loop uses repeat(maxTurns) to set a turn limit, preventing the model from calling indefinitely; when the limit is reached, the code returns an escalation-to-human message rather than letting the model decide on its own.
50%UnverifiedDSupport's tool calls are executed in parallel via async + awaitAll, with results filled back in request order because the model API requires the correspondence.
50%UnverifiedDSupport's RAG implementation splits articles by paragraph, uses TF-IDF for word-weight vectorization, optionally integrates VoyageEmbedder for semantic retrieval, and uses a relevance cutoff of minScore = 0.25 in SearchKbTool.
50%UnverifiedIn DSupport, when the RAG results are empty after filtering, the tool returns nothing_relevant_found, and the knowledge expert is required to answer NO_ANSWER rather than fabricate an answer.
50%UnverifiedDSupport's MCP portion is based on the official Kotlin SDK and runs over stdio; the client starts the server as a subprocess, and the session messages are initialize, tools/list, and tools/call.
50%UnverifiedIn MCP's stdio mode, stdout is the protocol channel itself, and any non-protocol content mixed in causes the peer to fail parsing, so DSupport's server redirects System.out to System.err.
50%UnverifiedDSupport's orchestrator holds no data tools and is only responsible for deciding who handles which part, always delegating to experts; if the orchestrator held tools, DSupportAssembly would fail to assemble directly, enforcing the architectural constraint through code.
50%UnverifiedIn DSupport, each expert is wrapped as a SubAgentTool, which is just an ordinary tool from the orchestrator's perspective; SubAgentTool receives an agent factory rather than an agent instance, because each agent holds its own history and parallel calls cannot share an instance.
50%UnverifiedDSupport's guardrails are deterministic code running at three fixed points in the agent loop, exposing three aspects—beforeTool, afterTool, and beforeFinal—through the Hook interface, and each aspect can allow, reject, or modify.
50%