DCENT_ADE — D-Central Technologies
DCENT_ADE: The Sovereign Agentic Development Environment
Traditional IDEs were built around one human editing one file. The first AI coding tools bolted a chatbot onto that editor. DCENT_ADE starts somewhere else: what does a development environment look like when AI agents are actual participants, running in real terminals, coordinated, reviewed and held to evidence? Local-first, open source, no gatekeeping, no paid tier. Alpha, and we will tell you exactly what that means.
One Developer Is Now a Small Organization
When you can run Claude Code, Codex, OpenCode, Gemini and local models at the same time, development stops looking like one person operating one editor. It starts looking like a technical organization: several workers, different roles, parallel tasks, shared context, review gates, coordination, persistent memory and specialised tools. The editor was never designed for that. DCENT_ADE is.
The Editor Era
Every tool in the lineage that runs from vi to VS Code optimises the same thing: one human, one buffer, one cursor. That is a beautiful piece of engineering and it is not going away. It simply has nothing to say about what four agents should do while you are reading a diff.
The Sidebar Era
The first generation of AI coding tools put a chat panel beside the editor. It helped, genuinely. But the shape of the workspace never changed, so the moment you wanted a second agent you were back to juggling terminal windows and remembering which one was doing what.
The Agentic Era
Once agents are participants rather than autocomplete, the missing layer is not a better text box. It is coordination: who is working, on what, with which files claimed, measured against what evidence, and waiting on which human decision.
Alpha. Here Is Exactly Where It Stands.
This page is an announcement, not a download. There is no public release yet and we are not going to dress up a roadmap as a product. DCENT_ADE is in heavy development, most of what follows has been exercised in live testing, and the parts that have not are labelled as such further down this page.
What You Can Do Today
Read. Nothing more, and we would rather say so than collect an email address for a launch we have not scheduled. The methods behind DCENT_ADE are published in full on this site, and every one of them works with the tools you already have. Start with the five disciplines and steal whatever is useful.
What Does Not Exist Yet
A public source release. A binary. An installer. A version number you can pin. The repository is reserved but empty, and until code is actually in it we will not link it as though it were a download. When that changes this page changes with it.
The Rule We Hold
No fake agents, no simulated activity, no fabricated telemetry, no optimistic availability lights. A beautiful button that does nothing real is not a feature. Where the current build cannot perform an operation it refuses and says so, rather than reporting a success it did not achieve.
Not an IDE With an AI Sidebar
An Agentic Development Environment collapses a stack of separate tools into one coherent workspace. Not because consolidation is fashionable, but because these things are useless in isolation: a mission board that cannot see agent state is a to-do list, and an agent that cannot reach memory rediscovers the same fact every morning.
DCENT_ADE combines a native development workspace, a multi-agent terminal environment, an AI coordination layer, a mission-control system, a local and LAN model interface, a prompt and context workspace, a persistent memory system, a task board, a code editor and diff environment, a Git workflow, an MCP and tool-server control surface, an agent monitoring and review system, a screenshot and visual-context system, a voice interface, and an automation runtime for recurring responsibilities.
The objective is not to hide complexity behind automation that only looks like it is working. It is to make complex agentic systems understandable, observable, controllable and useful. Those four words are load-bearing, and they are the reason this project has an honesty rule written into its development process rather than its marketing.
DCENT Space: One Workspace for Human and Agent
Instead of forcing every agent into a hidden background process, DCENT Space exposes real interactive sessions alongside the rest of the project. A persistent tiled layout with recursively split regions, supporting up to sixteen simultaneously visible tabbed regions with horizontal and vertical splitting, resizing, reparenting, collapsing and zooming.
In practice that means one screen can hold Claude Code working the backend, Codex investigating a performance regression, OpenCode operating on a different branch, an ordinary shell running the application, the repository editor showing the affected files, a diff of exactly what changed, Mission Control tracking the objective, Orion watching the whole situation, and the Review surface waiting for the result. That is the difference between using an AI coding tool and operating an agentic development environment.
None of this is a reinvention of the terminal multiplexer, and we are not pretending otherwise. tmux and screen solved tiling and session persistence decades ago and solved them well. What they do not do is know that pane three is an agent, that it is waiting on your approval, and that it has claimed four files another agent is about to touch.
Real Coding Agents, Not Reimplemented Ones
DCENT_ADE runs the actual harnesses through native PTYs and an integrated terminal emulator. It does not need to rebuild Claude Code or Codex. It becomes the environment around them, so your existing subscriptions, authentication and tooling keep working.
A Catalog, Not a Blank Cheque
The native host owns a catalog of supported harnesses rather than allowing arbitrary process execution requested by the interface. Current native handling covers shells plus Claude Code, Codex, Gemini and OpenCode, with the architecture built to accept more. The distinction matters: a workspace that can spawn anything on request is a remote code execution surface wearing a nice theme.
Credit Where It Is Owed
Anthropic built Claude Code. OpenAI built Codex. Google built the Gemini CLI. OpenCode is community open source. These are excellent tools built by people who solved hard problems first, and DCENT_ADE is worth less than nothing without them. We orchestrate; they do the work.
Sessions That Survive Closing the Lid
Agentic work is only useful when it is durable. Live testing has demonstrated selecting a specific historical Claude conversation and resuming it by session identity, rather than reopening whatever happens to be newest in a directory. Codex session discovery and resume are being brought into the same flow.
Orion: The Coordination Layer
A fleet of agents is only useful if something can coordinate it. Orion is the long-lived coordination layer built into DCENT_ADE. It is not another coding chatbot. Its job is to understand the surrounding environment — terminals, sessions, tasks, missions, boards, memory, agent status and project state — and to act on it.
> launch four Claude Code instances
> give two of them the frontend work
> ask Codex to investigate the failing test
> what is everyone doing?
> which agent is waiting for me?
> move that task into review
> have another agent inspect the implementation
That block is an interface sketch, not a captured session. We are labelling it because this project has a rule against fabricated telemetry and a screenshot of invented output would break it on the page that explains the rule.
DCENT_ADE already contains the architectural mechanisms for Orion-driven terminal launching and prompt delivery, including session registries and adoption across reloads. The awareness layer is designed to derive states such as busy, idle, awaiting input and finished from actual terminal behaviour rather than from an agent asserting that it is done, then expose those states to both the coordinator and the human. Coordination primitives include boards, missions, mailbox-style communication, claims and memory.
The point is not to remove the human. It is to change what the human spends attention on. Instead of babysitting every agent terminal, you set direction, approve the decisions that carry consequences, review outcomes, and intervene where judgement actually matters.
Mission Control: Roles, Claims and Gates
Opening several terminals is useful. Giving them a shared mission is what makes a fleet worth having. The lifecycle is explicit and inspectable: Coordinator, then Scouts, then Builders, then Reviewers, then human approval, then integration and delivery.
A Coordinator breaks down an objective. Scouts investigate. Builders own implementation. Reviewers inspect the result independently. Human approval sits at the gates that matter. The architecture is built on claims, isolated work, review packets, quality gates, durable state, recovery and explicit approval — not a swarm of agents all editing the same files and hoping.
Gauntlet testing has live-proven substantial parts of this lifecycle. Starting a mission creates Coordinator, Scout, Builder and Reviewer workers. Approving the plan moves execution into review. Reviewer approval plus human co-signing reaches an approved merge state. The Monitor, Review and Delivery surfaces consume the same persisted mission telemetry, and that telemetry survives a reload.
It also does not pretend. The current catalog execution layer does not perform a Git merge, so it refuses the operation instead of claiming success. That refusal is the feature. Agentic development needs more automation, and it needs more truth, and the second one is what makes the first one safe to want.
These are not marketing categories. They are the five disciplines DCENT_ADE is designed around, plus the two loop patterns we run daily. Each has a full reference page: prompt engineering, context engineering, harness engineering, loop engineering, graph engineering, RALPH loops and Gauntlet loops. Start at the hub.
Local First. Cloud When You Want It.
Your development environment should not require surrendering your development environment. Local inference is a first-class path, not a consolation prize.
Your Machines, Your Models
Native discovery and management for local engines including Ollama and LM Studio, with model-role assignment so different jobs draw on different models. LAN inference is part of the architecture: a strong workstation can serve models to every other machine in the house, and a homelab becomes a private inference cluster.
Cheap Work Stays Cheap
Smaller local models are perfectly capable of frequent coordination and classification work. Reserving expensive models for the jobs that genuinely need them is not a compromise, it is the correct engineering decision, and it also means development does not stop because an API is having a bad afternoon.
A Visible Boundary
Sovereignty does not mean pretending cloud models are useless. Claude, OpenAI models and OpenRouter offer real capability. The answer is not prohibition, it is a visible boundary: local work stays local by default, LAN and cloud routes are explicit, and cloud actions pass through native-owned egress controls. Local when possible, cloud when valuable, consent when crossing.
A Control Plane Between Intention and Authority
Security in an agentic environment is a different problem from security in a text editor. An agent may want to read files, write files, execute commands, launch processes, reach credentials, contact a remote model, activate an MCP server, capture the screen, touch Git, or perform something with external side effects. Those are serious capabilities and they deserve a serious boundary.
DCENT_ADE keeps sensitive authority in its native Tauri and Rust host. The interface layer does not receive unrestricted process, filesystem or network access. New capabilities arrive through narrow, validated native commands, and the rule is preserved deliberately: the WebView does not gain general spawn, SQL or fetch authority for convenience. The native connection layer owns the network policy itself — operation definitions, destinations, redirect behaviour, credential handling, response ceilings and classifications.
MCP and external tool servers are treated the same way: a native registration catalog with approval-bound activation, where the registered executable and argument vector belong to the native layer, under working-directory and environment restrictions rather than arbitrary process creation. Where a restriction is not yet enforceable, it is surfaced honestly instead of being described as a security guarantee. Installing a tool should not silently mean handing an opaque process the keys to the machine.
Ordinary local work carries a zero-telemetry policy. No remote fonts, no analytics, no hidden network dependencies. The Data Map exists to surface real network behaviour rather than hide it behind the word privacy. A development tool should not quietly turn your entire source repository into a telemetry feed because you switched on an AI feature. If you want the wider argument, we keep it at the sovereignty hub.
Memory, Review and Delivery
Agentic development has a memory problem and a truth problem. Agents rediscover the same facts, repeat investigations, lose architectural decisions between sessions, and then report success with total confidence. Both problems need structure, not a bigger model.
Memory That Lives With the Project
Workspace-scoped memory in native-scoped local Markdown, with bounded read, write, append, list and search operations that reject unsafe roots, traversal, unsupported file types, oversized documents and stale writes. Human-readable, inspectable, editable, portable. Your project knowledge belongs beside your project, not inside one vendor conversation database you cannot grep.
Still a Real Code Environment
Agentic development still ends in code. A CodeMirror-based repository editor with syntax support, search and replace, folding, bracket matching, multiple files and conflict-aware saving. A diff surface for direct inspection. Git tooling in the same workspace. Agents can propose, execute and test, but humans need a fast way to see what actually changed.
Completion Backed by Evidence
Three separate questions deserve three separate surfaces. Monitor shows what agents are doing. Review turns an implementation into something judgeable, with review packets and MergeGate state drawing a hard line between produced and approved. Delivery handles what happens next, and distinguishes what it can genuinely do locally from what needs further authority.
Add DCENT Shot for the visual half of the job. Software development is not only text: UI defects, layout problems and rendered regressions cannot be understood from source alone. Native Windows testing has demonstrated application-window capture, immutable original image artifacts, sidecar-based editing state, destructive redaction on export, local Windows OCR and clipboard integration — so an agent can be handed a picture of the actual defect rather than a description of it.
| Subsystem | Status | What That Means |
|---|---|---|
| Tiled PTY workspace | Live-proven | Native PTYs and an integrated terminal emulator, recursive splits, persistent layout. |
| Harness catalog | Live-proven | Native handling for shells plus Claude Code, Codex, Gemini and OpenCode. |
| Session discovery and resume | Live-proven | Resuming a specific historical Claude conversation by session identity. Codex is being integrated. |
| Mission lifecycle | Live-proven in part | Roles, plan approval, reviewer approval, human co-signing, approved merge state, telemetry surviving reload. |
| Catalog Git merge | Refused by design | The execution layer does not perform the merge, so it declines rather than reporting a success. |
| Orion coordination | Architecture in place | Terminal launching, prompt delivery, session registries and adoption across reloads. |
| Agent state awareness | Architecture in place | Busy, idle, awaiting input and finished, derived from real terminal behaviour. |
| Workspace memory | Implemented | Bounded Markdown operations with unsafe-root, traversal, size and stale-write rejection. |
| MCP tool servers | Implemented | Native registration catalog, approval-bound activation, native-owned executable and argv. |
| Local and LAN inference | Implemented | Ollama and LM Studio discovery and management, model-role assignment. |
| Editor, diff and Git | Implemented | CodeMirror editing, diff surface, repository operations in-workspace. |
| DCENT Shot | Implemented on Windows | Window capture, immutable originals, redaction on export, local OCR. |
| Gauntlet Graph Loop | Stated direction | Coordinated graphs of specialised agents and evaluators. Not built yet. |
| Public source release | Not yet published | The repository is reserved and empty. There is nothing to download today. |
Free, Open, As-Is
Other environments in this category ship a fraction of this feature set and charge premium prices for it. We are not planning any form of gatekeeping. No paid tier, no seat licence, no feature held back for a pro plan, no telemetry sold on the side.
DCENT_ADE is the result of months of testing agentic workflows and building the tooling to operate them. It is offered free and as-is. If you use it commercially, or if you benefit from it in any way at all, we expect a voluntary subscription or donation — expected, never enforced, never checked, never a condition of use. That arrangement only works if people honour it, and it is the same arrangement that keeps the rest of the DCENT suite open.
We also stand on a very large pile of other people shoulders here. The harnesses, the terminal emulators, the model runners, the editor components, the protocol work, the multiplexers that solved tiling long before us. Open source built the foundation this sits on and the only honest way to use it is to give the same thing back.
Related products, repair, and setup paths
- how D-Central diagnoses ASIC repairs
- ASIC troubleshooting library
- ASIC manuals and repair guides
- replacement hashboards
- ASIC control boards
- ASIC power supplies
- S19 family replacement hashboard
- C52 replacement control board
- APW12 S19 power supply
- compare specs in the ASIC miner database
- compare ASIC miner specs
- ASIC miner database
- ASIC repair services
- Antminer S19 specs and profitability
- buy a tested Antminer S19
- Antminer S19 maintenance guide
- Antminer S19 repair service
- Antminer S21 specs
- Bitmain Antminer S21
- Antminer S21 maintenance guide
- BM1370BC S21 Pro chip
Last reviewed August 13, 2026.
