NetCoreKevin is a .NET 9 agent platform, not a library

A platform aimed at enterprise knowledge base agents

The repository describes itself as an enterprise AI middle platform built on .NET 9, with a separated front end and back end. The feature list is long and worth reading as a map of what the author considered mandatory: AI knowledge base agents, multi-agent collaboration, a chat log compression strategy, skill management, local offline model calls, controllable loading of agent skills, AI web search, agent permission control, single database multi-tenancy, and a distributed, microservice style architecture.

That is a product platform, not a library. There is no NuGet package to reference and no API to call; there is a solution, NetCoreKevin.sln, a docker-compose.yml at the root, an InitData directory, a Doc directory, a Vue project and a .NET backend that you run and administer. The people it is for are .NET teams that want an AI agent front office with a knowledge base attached, and who would rather inherit a working shape for permissions, tenants, scheduling and messaging than design one.

The stack is stated plainly in the technology highlights: .NET 9 as the long term support base, DDD layering, a microservice decomposition built on Consul, CAP and Hangfire, AgentFramework 1.9 with skill management and Ollama support, RAG retrieval augmentation over a Qdrant vector database, a Redis cache layer with a request level response cache filter, and log4net with multi level logging and a slow query alert. The description also names components the highlights table leaves out, including a voice phone mode for agents, an agent memory layer, a knowledge base reranking model, domain events, JWT authentication, SignalR, Mcp, RabbitMQ and a Log4 component.

A front end ships with it, described as a Vue 3 plus Ant Design Vue admin console with user, role, permission and system configuration screens.

The module map is the architecture

Rather than a feature list, the fastest way to understand this project is the module layout, because almost everything the platform does lives in a named module under a core framework project.

The business side is a conventional layered set under App: an application service layer, a domain layer, repository implementations and the WebApi entry point. Next to it sits the Kevin core framework project, which holds the shared kernel: core services including an AI services folder, the domain model, the EntityFrameworkCore implementation with a slow query interceptor, web basics such as controllers and global filters, shared DTOs, enums and constants, and a kevin.Module folder for pluggable features.

Inside that pluggable folder sit the parts that matter for AI work: kevin.AI.AgentFramework for the agent framework, Kevin.RAG for retrieval augmentation with Qdrant, Ollama and reranking, Kevin.Authentication.Jwt, kevin.Permission for RBAC, kevin.Cache, Kevin.Hangfire for scheduling and Kevin.SignalR for real time communication. The README notes that the module list continues with more than thirty entries, including SMS, email, snowflake ID generation and distributed locks.

Two things follow from that layout. First, replacing one infrastructure concern is a matter of swapping a module rather than rewriting an application, which is the argument for a modular monolith here. Second, the same layout means the platform ships a lot of surface you may not need, and every one of those modules is a dependency you inherit.

Tests are structured too, with a unit test project on xUnit, an integration test project and a shared testing infrastructure project.

RAG over Qdrant, with the model endpoint left configurable

The retrieval side is the part most people will evaluate first, and the design is deliberately narrow. The knowledge base module stores documents and answers questions over them, the vector store is Qdrant, and the embedding endpoint is configuration rather than code.

The settings block for a locally running model is a good illustration, because the same key serves both hosted and local providers.

{
  "OllamaApiSetting": {
    "Url": "http://localhost:11434/api/embeddings",
    "DefaultModel": "qwen3:4b"
  }
}

The Url points at a local Ollama server on port 11434 and the default model is a small local model. The hosted alternative in the README uses a different Url and a different DefaultModel under the same key, which is the entire configuration surface for swapping providers. That also means the key name is a bit of a misnomer if you run everything through a hosted API, but the effect is a single place to change the endpoint and the model name.

The requirements list Qdrant 1.7 or newer as an AI feature dependency, and the Qdrant instance is expected on its standard port.

docker run -p 6333:6333 qdrant/qdrant

The documented flow is short: register an AI account and get an API key, configure the model in the system, create a knowledge base and upload documents, configure the agent and bind its skills, then start a conversation. The tutorial also mentions a vector dimension of 2048 as the default, described as the highest accuracy option, and notes that the vector model can also be chosen when creating the knowledge base or set in the configuration file.

The reranking stage named in the project description is part of the Kevin.RAG module alongside Qdrant and Ollama, which is a detail worth confirming against your own documents: retrieval quality usually depends more on the rerank step and the chunking than on the vector store.

Multi-tenancy enforced above the data layer

The multi-tenancy claim in the highlights table is specific: one database, many tenants, data isolation, with tenant filtering forced at the interface layer. That last part is the design decision that determines whether the model is safe to use, because a tenant filter applied by convention in application code is one forgotten filter away from a data leak, while one enforced at the interface layer sits below the code that can forget it.

The default seed account gives a hint of the shape. The README lists admin with the password 123456 and tenant 1000, so tenants are numeric identifiers carried with the identity rather than separate databases or separate schemas. Global filters in the web basics project are the natural place for that enforcement, and the EntityFrameworkCore project is where an interceptor for slow queries sits, which suggests a query level hook as well as a filter level one.

The permission model is separate and explicit: menu permissions and API permissions, roles bound to permissions, and a default-deny posture. The security row in the highlights table mentions time constant key validation, password hashing with duplicate protection, and a permission default policy. Authentication is JWT, in its own module.

Caching is Redis, with several caching strategies and a request level response cache filter, which is a blunt instrument that pays off on read heavy admin screens and hurts on screens that must show fresh state after a write.

Bringing the stack up: MySQL, Redis, Qdrant and migrations

The quick start section is concrete enough to follow. The environment requirements are .NET SDK 9.0 or newer, Node.js 16 or newer for the front end, MySQL 8.0 or newer, Redis 7.0 or newer, and Qdrant 1.7 or newer for the AI features. The connection strings live in one file, App/WebApi/appsettings.json.

{
  "ConnectionStrings": {
    "dbConnection": "server=127.0.0.1;port=3306;database=kevin_app;user id=root;password=admin123",
    "redisConnection": "127.0.0.1:6379,DefaultDatabase=0,password=123456"
  }
}

The schema is created with Entity Framework Core migrations from the package manager console, against the Kevin.EntityFrameworkCore project, with an Add-Migration step followed by Update-Database. The backend then starts from the WebApi directory.

cd App/WebApi
dotnet run --environment Development

The admin console is optional and runs as a separate npm project.

cd vue/kevin.web.vue
npm install
npm run serve

The front end dev server proxies the /VarApi prefix to the backend on port 9901, which the README says removes any need for extra cross origin configuration. The service addresses are given as a table: the API on port 9901, Swagger on the same port, a Hangfire dashboard under the pchangfire path on that port, and the admin console on port 8080. A docker-compose.yml at the repository root suggests the same services can be brought up together, although the README does not spell out what that file contains.

One caution for a first run: the seed account in the README is a fixed password, and the connection strings carry example credentials, so both need replacing before this configuration faces anything but a laptop.

Recurring jobs register themselves through a module hook

Background work is handled by Hangfire, and the mechanism is a small extension point rather than a configuration file. The README says Hangfire is registered on Redis by default and that the registration can be changed in Kevin.Hangfire.ServiceCollectionExtensions.

A module implements IModuleConfigTasks, and the ConfigTasks method is called at startup, where the recurring job manager is used to register a job. The signature in the README looks like this.

        public Task<bool> ConfigTasks(IRecurringJobManager recurringJobManager)

The worked example registers a job that processes vector data for the knowledge base on a six minute schedule, with the recurrence given in cron form and the time zone set to the local one, and it notes that the identifier is the unique key used to change or remove the job later. Registering through an interface rather than through attribute scanning is a deliberate choice: it means a job can be registered against an application service interface, so the scheduled work calls the same service the rest of the system uses.

The agent features that need background processing, such as knowledge base vector processing and the chat log compression strategy the project description mentions, are the natural clients of this hook. It is also the part of the platform most likely to need adjustment in a real deployment, since a cron expression per job does not scale the way a queue with a UI does, and the dashboard path in the README is under the pchangfire route rather than the more usual one.

Swapping the vector store or the model provider

The realistic alternative to adopting this platform wholesale is to keep a couple of its ideas and replace the rest, and the module layout makes that split fairly clean.

The vector store is the easiest to change, because the Qdrant connection is configuration and the retrieval logic lives in the Kevin.RAG module rather than being spread through the agent code. A team that already runs a vector database, or that needs a store with a different filtering model, can point the RAG module at it and keep the knowledge base, document upload and agent configuration surfaces. The cost is that you own the code the module would have given you, and the rerank stage has to be re-implemented or dropped.

The model provider is the second axis, and the README documents both ends of it: a hosted API with a key, and a local Ollama server on port 11434 with a model such as qwen3:4b. The difference is not just cost. A local model keeps prompts and documents inside your network, which matters for the enterprise use case the platform targets, at the price of model quality on harder tasks and of hardware you have to supply. A hosted model gives better answers and an API key to manage, and it puts your documents on someone else's infrastructure.

What you cannot easily swap is the platform itself. The agent framework, the skill system, the multi-agent collaboration and the admin console are the reason to take this repository rather than assemble your own, and they are also the parts that tie you to the module set, the Vue console and the .NET stack.

What this codebase assumes about you

The platform is opinionated, and the opinions are visible in the requirements list rather than hidden in the code. It assumes MySQL, Redis and Qdrant are available, that a vector database is part of your infrastructure rather than something exotic, and that the team can run a .NET backend and a Vue front end side by side. It also assumes a model is reachable, either hosted or local, and that you are prepared to think about embeddings, dimensions and reranking as configuration.

The documentation is the weak point. The README is written in Chinese, so a team outside that language reads the module names, the configuration keys and the code, and little else; SYSTEM_DOCUMENTATION.md at the root may fill part of that gap, but its contents are not visible from the repository listing alone. A platform with this many modules and configuration keys is exactly the kind of project where undocumented behaviour accumulates, and this one has no visible public API contract for agents.

Scale is the other assumption. This is a monolith with a pluggable module folder, a Vue console and a seeded admin account, which is a sensible shape for a team that owns the whole platform. If several teams need to consume the agent capability with different rules, the single database multi-tenant model and the menu and API permission scheme become the constraints you design around rather than the features you enjoy.

On upkeep, the repository is not archived and the last push was on 2026-10-20, with releases 9.6.2 on 2026-10-08, 9.6.1 on 2026-09-17 and 9.5.1 on 2026-09-04. The licence is MulanPSL-2.0, a permissive licence, and the LICENSE file at the root is the text that governs your use of the code.

Editorial conclusion

NetCoreKevin fits a .NET team that wants an opinionated agent and knowledge base platform with the admin console, RBAC and multi-tenancy already assembled, and it does not fit a team that needs a small library, a different backend stack or a documented public API contract. Before adopting it, run the Qdrant container, point the OllamaApiSetting block at a local model and create one knowledge base, since that path exercises the parts most likely to need changing. The last push was on 2026-10-20 and the newest release is 9.6.2 from 2026-10-08, under the MulanPSL-2.0 licence.

Frequently asked questions

Official sources

1. Issues
2. junkai-li/NetCoreKevin on GitHub
3. License: MulanPSL-2.0
4. README
5. Releases