# Core Features of DeepSeek-Reasonix: A Modular Go-Based Coding Agent Framework

> Explore DeepSeek-Reasonix core features: a modular Go coding agent framework with interchangeable providers, tools, plugins, safety gates, and two-model coordination for efficient LLM-driven development.

- Repository: [YHH/DeepSeek-Reasonix](https://github.com/esengine/DeepSeek-Reasonix)
- Tags: deep-dive
- Published: 2026-06-26

---

**DeepSeek-Reasonix is a Go-based coding agent framework that drives LLMs through a modular architecture featuring interchangeable providers, tools, and plugins, with built-in safety gates and two-model coordination.**

DeepSeek-Reasonix (often referred to as Reasonix) is an open-source coding agent framework written in Go that enables Large Language Models (LLMs) to interact with development environments through a highly modular design. The repository at `esengine/DeepSeek-Reasonix` implements a registry-based architecture where components are self-registered via `init()` functions, allowing developers to swap models, add tools, or extend functionality without modifying core logic. Understanding the core features of DeepSeek-Reasonix reveals how it balances flexibility with safety through its provider abstraction, tool system, and permission gating.

## Provider Abstraction Layer

The **Provider** component abstracts LLM vendors through a unified interface defined in [`internal/provider/provider.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/provider/provider.go). This interface requires a `Stream` method that returns token deltas, enabling support for OpenAI-compatible APIs, Anthropic, and custom providers. Providers self-register via `provider.Register` in their `init()` functions, creating a factory pattern that the configuration system consumes at runtime.

```go
// File: internal/provider/custom/custom.go
package custom

import (
    "context"
    "github.com/esengine/DeepSeek-Reasonix/internal/provider"
)

type SimpleProvider struct{ cfg provider.Config }

func (p *SimpleProvider) Stream(ctx context.Context, req provider.Request) (<-chan provider.Chunk, error) {
    // Implementation that talks to your model
}

func init() {
    provider.Register("custom", func(cfg provider.Config) (provider.Provider, error) {
        return &SimpleProvider{cfg: cfg}, nil
    })
}

```

This registration pattern allows the framework to instantiate providers dynamically based on the TOML configuration file, without hardcoding vendor-specific logic into the agent core.

## Extensible Tool System

Tools in Reasonix encapsulate callable actions ranging from file I/O to shell execution, all implementing the `Tool` interface defined in [`internal/tool/tool.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/tool/tool.go). The interface requires four methods: `Name()`, `Description()`, `Schema()`, and `Execute()`. Built-in tools reside in `internal/tool/builtin` and register themselves via `tool.RegisterBuiltin` during initialization.

```go
// File: internal/tool/builtin/hello.go
package builtin

import (
    "encoding/json"
    "github.com/esengine/DeepSeek-Reasonix/internal/tool"
)

type helloTool struct{}

func (t *helloTool) Name() string        { return "hello" }
func (t *helloTool) Description() string { return "Greets the user." }
func (t *helloTool) Schema() json.RawMessage {
    return json.RawMessage(`{"type":"object","properties":{}}`)
}
func (t *helloTool) Execute(_ context.Context, _ json.RawMessage) (string, error) {
    return "Hello, Reasonix user!", nil
}

func init() { tool.RegisterBuiltin(&helloTool{}) }

```

The registry pattern enables the **Agent** to discover and invoke tools dynamically while maintaining strict type safety through Go interfaces.

## MCP Plugin Architecture

The **Plugin** system enables out-of-process extensions via the Model Context Protocol (MCP) using JSON-RPC. Implemented in [`internal/plugin/plugin.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/plugin.go), this feature supports multiple transport types including `stdio`, `http`, and `sse`. Plugins can expose additional tools or prompts that integrate seamlessly with the built-in tool registry, allowing the agent to leverage external capabilities without Process coupling.

This architecture decouples the core agent from external dependencies, letting developers write extensions in any language that speaks MCP while Reasonix handles the transport layer and protocol negotiation.

## Agent Session Orchestration

The **Agent** component in [`internal/agent/agent.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/agent/agent.go) orchestrates individual LLM sessions through a request-response loop. It builds a `Request` structure containing conversation messages and available tool schemas, streams the response via `Provider.Stream`, and processes incoming `Chunk` types. When the LLM emits a `ChunkToolCall`, the agent:

1. Looks up the tool in the registry
2. Validates permissions through the permission gate
3. Executes the tool via `Execute()`
4. Feeds the result back into the conversation as a new message

This loop continues until the model returns a final response or hits the configured step limit. The agent also handles **compaction**—summarizing old conversation turns when token usage approaches the provider's `context_window`—to maintain context within model limits.

## Two-Model Coordination

The **Coordinator** in [`internal/agent/coordinator.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/agent/coordinator.go) implements a sophisticated two-model collaboration strategy that separates planning from execution. When `agent.planner_model` is configured, the Coordinator spawns a read-only **planner** agent that generates a high-level plan without modifying state. This plan is then handed to an **executor** agent (a standard `Agent` instance) that implements the changes.

This design keeps each model's prompt cache stable—the planner sees a consistent read-only view while the executor handles mutations—improving performance and reducing context window consumption for complex multi-step tasks.

## Permission and Safety Controls

The **Permission** system in [`internal/permission/permission.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/permission/permission.go) implements per-tool gating through a `Gate` structure that evaluates rules before any tool execution. The system supports three policy levels:

- **Allow**: Execute the tool automatically
- **Ask**: Prompt the user for confirmation
- **Deny**: Block the tool invocation

Rules are parsed from the TOML configuration and evaluated in [`internal/permission/permission.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/permission/permission.go), ensuring that autonomous operation remains safe even when running potentially destructive tools like shell commands or file system modifications.

## Configuration and Command Interface

Reasonix uses a hierarchical TOML configuration system resolved in the order: CLI flags → project [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml) → user config → defaults. The example configuration in [`reasonix.example.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.example.toml) demonstrates how to activate providers, enable tools, load plugins, and define permission rules.

The **Command** system in [`internal/command/command.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/command/command.go) handles slash-commands within the TUI (built with Bubble Tea). Commands can be built-in (like `/new` or `/clear`), custom markdown files stored in `.reasonix/commands/`, or MCP prompts prefixed with `/mcp__`. This allows users to create reusable workflows and prompt templates that integrate directly with the agent interface.

## Summary

- **DeepSeek-Reasonix** provides a modular Go-based framework for LLM-driven coding agents with interchangeable components.
- The **Provider** interface ([`internal/provider/provider.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/provider/provider.go)) abstracts LLM vendors through a streaming protocol with self-registration.
- **Tools** follow a strict interface ([`internal/tool/tool.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/tool/tool.go)) with built-in registration via `tool.RegisterBuiltin` and schema-based validation.
- **Plugins** extend capabilities via MCP JSON-RPC ([`internal/plugin/plugin.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/plugin.go)) supporting stdio, HTTP, and SSE transports.
- The **Agent** ([`internal/agent/agent.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/agent/agent.go)) manages the request loop, tool execution, and context compaction.
- **Coordinator** enables two-model collaboration ([`internal/agent/coordinator.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/agent/coordinator.go)) separating planning from execution.
- **Permission gates** ([`internal/permission/permission.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/permission/permission.go)) enforce per-tool policies (allow/ask/deny) for safe autonomous operation.
- Configuration flows through TOML files with the CLI entry point at [`cmd/reasonix/main.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/cmd/reasonix/main.go).

## Frequently Asked Questions

### What is DeepSeek-Reasonix used for?

DeepSeek-Reasonix is a coding agent framework that enables Large Language Models to interact with development environments by reading files, executing shell commands, and modifying codebases autonomously. It serves as the infrastructure layer between LLMs and developer tools, handling streaming responses, tool orchestration, and safety permissions.

### How does DeepSeek-Reasonix handle different LLM providers?

The framework abstracts LLM vendors through the `Provider` interface in [`internal/provider/provider.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/provider/provider.go), which defines a `Stream` method for token-based responses. Providers self-register via `provider.Register` in `init()` functions, allowing the system to instantiate OpenAI-compatible, Anthropic, or custom providers based on TOML configuration without core code changes.

### What is the two-model coordination feature in DeepSeek-Reasonix?

The **Coordinator** ([`internal/agent/coordinator.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/agent/coordinator.go)) implements a dual-agent architecture where a read-only **planner** model generates execution strategies and a separate **executor** model implements them. This separation maintains stable prompt caches for each model role and reduces context window consumption during complex multi-file operations.

### How does DeepSeek-Reasonix ensure safe tool execution?

Safety is enforced through the **Permission** system ([`internal/permission/permission.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/permission/permission.go)), which evaluates per-tool policies (allow, ask, or deny) before any `Execute()` call runs. The `Gate` structure parses rules from configuration and intercepts tool invocations, ensuring destructive operations like shell commands or file deletions respect user-defined autonomy boundaries.