AI & Software · Software
Elmes DM
Manage your agents' work, memory and acceptance gates in one place — records, not files.
Overview
The problem. In a team building software with LLM agents, three things fall apart: (1) work tracking — which task belongs to which spec, and have the acceptance criteria been met; (2) agent memory — every repository carries its own agent instruction files and notes, and cross-project knowledge (technology lessons, rules) is copied around and goes stale; (3) agent configuration — bootstrap files, agent definitions and skills are updated by hand in every repository. The "Review → Done" transition depends on human memory, and no token or cost telemetry is collected.
The solution. Elmes DM combines four functions in a single PostgreSQL-based system: hierarchical work tracking (the DM_Item model: project → epic → item → sub-item; ltree taxonomy), a central agent memory store (module → project → technology node → global scope; promotion to a higher scope requires approval), the Environment Registry (agent files are generated from the Registry with dm env sync; knowledge is injected, never written to disk) and a spec/AC-gated workflow engine (acceptance criteria in a separate table; moving from Review to Done requires all acceptance criteria to be satisfied and no open blockers).
Agents and interface. Agents connect over MCP: remote SSE, a local stdio binary or the CLI, all derived from the same Zod contract, with policy enforced on the server. The web UI shows work in Tree-Table and swimlane Board views with Pane Stack, hovercards and an Inspector; drop targets are derived from the state machine. Partition-ready telemetry events and a model price table provide the groundwork for cost tracking.
This product is in development or field testing. Contact us for technical information, pilot use and a preliminary quotation.
Features
- Files are build output: agent configuration files (.claude) are generated from the Registry; knowledge (briefs, instructions) is injected, never written to disk.
- Scoped memory + approved promotion: module → project → technology → global; agents cannot write directly to the technology or global scope.
- Atomic AC gate: acceptance criteria live in a separate table; the status transition is validated in a single transaction.
- State machine as data: Board drop targets are derived from the state machine, with no hard-coded list; dragging writes only the status and leaves the lane value unchanged.
- MCP connectivity: remote SSE, a local stdio binary and the CLI all derive from the same Zod contract; policy is enforced on the server.
- RLS leak test: runs in every test run and catches incorrect role usage.
- Transport parity test: SSE and stdio responses are bit-identical.
- Taxonomy alias resolution with a rejection log.
- Partition-ready telemetry: an event table keyed on (id, ts); cost calculation through a model price table.
- Web UI: Pane Stack, hovercards, Inspector and URL state; Tree-Table with accordions; Board with swimlanes.
Specifications
Values marked “Target” are design targets, next-generation values or chip-vendor data; they are updated as measurement and certification are completed.
| Deployment model | Self-hosted: docker-compose (PostgreSQL 17, loopback only) + web application |
|---|---|
| Production deployment | Docker image / compose production profile; cloud optionTarget |
| Database | PostgreSQL 17 only (ltree, JSONB, full-text search); no SQLite option |
| Vector search | Hybrid search with pgvectorTarget |
| Job queue | pg-boss (no Redis/BullMQ required) |
| Updates | Database migrations with Drizzle (pnpm db:migrate) |
| CI/CD | Automated build and deployment pipelineTarget |
| Server | Node.js (ESM, TypeScript strict), pnpm, Docker; ~2 vCPU / 2 GB RAM (estimate) |
| Client | Current desktop browser (UI); Claude Code or an MCP-compatible agent client |
| Software stack | pnpm monorepo: db / contract / domain / server / mcp-local / cli packages + React web app |
|---|---|
| Data model | DM_Item hierarchy (self-referencing parent), acceptance-criteria table, scoped memory (module → project → technology → global), Environment Registry, telemetry events, model prices, ltree taxonomy + aliases |
| Workflow | State machines as data; guard registry on the server; Review → Done requires all acceptance criteria satisfied and no open blockers (project policy, on by default) |
| Test gate | Core test suite against a real PostgreSQL: RLS cross-project leakage, AC gate, SSE/stdio transport parity, taxonomy aliases, approved promotion — all green |
| MCP | Remote SSE and local stdio binary; bit-identical contract |
|---|---|
| HTTP / WebSocket | HTTP API + WebSocket (live UI updates) |
| CLI | dm env sync / verify, dm pending / approve / reject, dm token |
| Agent clients | Claude Code (.claude files generated from the Registry) |
| Other MCP clients | Compatibility validationTarget |
| Authentication | Token (dm token) |
|---|---|
| Single sign-on | SSO / OIDCTarget |
| Authorization | Project scoping with PostgreSQL RLS; separate application and service roles; approved promotion |
| Data residency | On the customer's server when self-hosted; the system itself makes no LLM calls (the agent runs on the client side) |
| Secrets | Environment files are never committed to the repository |
| KVKK documents | Together with the cloud editionTarget |
| Source license | Not yet determined |
|---|---|
| Commercial model | Self-hosted license / team subscription / hosted editionTarget |
| Support | Email, response within 2 business daysTarget |
| Completed | Core system and core test suite; the first three stages of the web UI (Pane Stack, Tree-Table, Board) |
|---|---|
| Next | Workspace view (dockview), pgvector hybrid search, graph layer, production deployment and managed PostgreSQL evaluation, full taxonomy tree, telemetry/cost dashboardTarget |
Applications
- Agent-assisted software teams
- Multi-project development
- Spec- and AC-gated delivery
- Agent memory management
- Agent configuration management
- OT and field integration projects
At Elmes. Work, memory and configuration management for agent-assisted projects such as AutoPCB, DiscOS, VibroBal and the module SDK.
In agent projects. Within the AI Agent Development & Integration service, it provides the discipline for moving agent workflows from pilot to production: work queue and acceptance-criteria gates.
Multi-project teams. A team subscription and a hosted edition are planned for software teams that want spec- and acceptance-criteria-gated delivery.
Industrial projects. In OT/field integration projects such as SCADA & Industrial Automation and AI Integration Consulting, the goal is for agents to keep PLC/SCADA documentation and decision memory in one central place.
Compliance & documentation
Elmes DM is a software product and requires no mandatory product certification. A normative requirements specification and setup documentation are available; user-facing documentation is being prepared according to the plan below.
- AvailableSoftware requirements specification (SRS v2)
- AvailableSetup guideCloud development environment setup
- TargetUser / operator guide
- TargetMCP tool referenceTo be generated automatically from the Zod contract
- TargetLicense terms
- TargetKVKK and data processing documents
- Out of scopeMandatory product certificationSoftware product; no mandatory certificate
Frequently asked questions
Which agent clients does it work with?
Any client that speaks MCP, via remote SSE or the local stdio binary. It was designed with Claude Code; validation for other clients is planned.
What happens to our existing agent configuration files (.claude folder, instruction files)?
The content moves into the Registry, and the files are generated with dm env sync. Manual edits are detected with dm env verify.
Does it replace Jira or Linear?
For agent-driven work, yes. It does not claim to replace general project management for human teams; integration is planned.
Where is the data stored?
In your own PostgreSQL database with a self-hosted installation. The system makes no LLM calls; the agent talks to its own provider.
Can projects see each other's data?
No. Projects are isolated with PostgreSQL RLS, and the leak test runs in every test run. The application must not connect to the database as a superuser.
Why won't an item move to Done?
Because of the gate rule: all acceptance criteria must be satisfied and there must be no open blockers. The response returns a gate_blocked code together with the IDs of the blocking records.
Is there a lightweight SQLite setup?
No. Because ltree, RLS and full-text search are required, only PostgreSQL is supported; it comes up with a single Docker command.
What about pricing and licensing?
Not determined yet. Self-hosted license, team subscription and hosted edition options are planned.
Get information about this product
Our engineering team replies within 24 hours.
Related products
Coming soonAI & SoftwareAutoPCB
From natural-language requirements to a Gerber package: schematic, placement, autorouting and DRC in one browser.
View details: AutoPCB
Coming soonHMI & Embedded PlatformDiscOS — Embedded HMI Operating System
A ready-made OS for your touchscreen device: bootloader, updates, app model and a shell that machines can talk to.
View details: DiscOS — Embedded HMI Operating System
Coming soonMeasurement & BalancingVibroBal — Portable Vibration Analyzer & Field Balancer
Measure the rotor in place, balance it in place.
In field testing
View details: VibroBal — Portable Vibration Analyzer & Field Balancer