Model runtime
Locally installed inference software and approved model weights. The final model schedule identifies source, version, license, permitted use, and replacement path.
The platform
One architecture. Six accountable modules.
DGM connects approved compute, local or connected AI, a configured Hermes agent, existing systems, business workflows, and enablement. Package selection determines which modules are included and how deeply they are implemented.
Module 01
Compute + data foundation
The physical and operational base for the rest of the deployment.
Physical equipment
Compute matched to the package
Focused tiers can use an approved client environment or named third-party services. The $250,000 Operating Layer uses one primary and one secondary Mac Studio reference node. Enterprise infrastructure is custom-designed. Any physical equipment is selected during design and recorded in the bill of materials before ordering.
Data readiness
Knowledge collections with permissions
DGM inventories the agreed source material, removes duplicates where practical, documents permitted use, organizes collections, and configures role-appropriate access. The client remains responsible for having the rights to provide and process its data.
Operations
Backup, restore, and configuration records
The final environment includes a configuration inventory, backup schedule, restore test, access list, and recovery notes appropriate to the approved design. High availability and disaster-recovery targets must be separately specified if required.
Module 02
Local AI + retrieval
Models are selected for the agreed workload, hardware limits, license terms, and required quality—not because one model name sounds impressive.
Retrieval layer
Business content is indexed into permission-aware collections so the system can retrieve relevant passages rather than rely only on model memory.
Evaluation set
Representative questions and expected behaviors are recorded before acceptance testing. DGM does not promise perfect accuracy or eliminate the need for human review.
Cloud escalation, if approved
Named workflows may use third-party APIs when explicitly enabled. Those data paths, vendor terms, usage allowances, and client approvals are documented.
Module 03
The custom Hermes agent
“Custom” means configured for the client’s approved instructions, tools, permissions, workflows, and knowledge—not a claim that DGM owns the underlying models or third-party frameworks.
Role + policy
Purpose, prohibited actions, escalation rules, tone, data boundaries, and human approval points defined in writing.
Tools + actions
Approved connectors for reading records, drafting content, creating tasks, or proposing updates. Production writes are limited by role and use case.
Logs + change control
Agreed activity logging, prompt and instruction versioning, test cases, and a controlled path for changes after release.
Important: Hermes is an AI-assisted software agent. It can produce incomplete or incorrect output and depends on the availability and behavior of connected systems. It does not replace legal, financial, medical, safety, or other professional judgment.
Modules 04 + 05
Systems your operating teams can use.
The precise applications and channels are selected after discovery. DGM integrates with client-owned or client-approved accounts rather than presenting third-party software as DGM property.
Customer lifecycle
Lifecycle stages, pipeline fields, ownership, task routing, notifications, interaction history, and reporting requirements.
Workflow automation
Trigger, rule, action, exception, human approval, audit record, and rollback path for each approved automation.
Marketing + sales
Research assistance, campaign drafts, lead qualification, follow-up suggestions, proposal support, and content workflows with brand and approval controls.
Customer service + content
Knowledge-assisted replies, ticket triage, draft responses, internal summaries, article creation, and escalation to a responsible person.
Module 06
Enablement is part of the system.
Training, maintenance, and support scale by package, from a focused closeout and roadmap through six months for the Operating Layer and negotiated terms for Enterprise. Exact hours, cadence, roles, and response targets are written into the final schedule.
Role-based training
Administrator, operator, reviewer, and executive sessions using the deployed workflows and agreed scenarios.
Documentation
System inventory, operating guides, workflow maps, test evidence, license schedule, and support contacts.
Support + maintenance
Issue intake, prioritization, target response windows, maintenance windows, exclusions, and change-request handling.
Module depth by package
The architecture expands with the operating problem.
These are commercial reference boundaries. The executed SOW identifies the exact modules, integrations, workflows, environments, and support obligations.
| Package | Primary module emphasis | Not automatic |
|---|---|---|
| Foundation · $25k | Readiness, one controlled prototype, risk register, training, roadmap | Production integration, hardware, ongoing support SLA |
| Workflow Launch · $75k | Hermes role, one core integration, up to three workflows, controls, training | Local hardware, multi-system program, six-month support |
| AI Operations · $100k | Knowledge retrieval, Hermes, up to two integrations, up to five workflows, enablement | Two-node infrastructure unless separately scheduled |
| Operating Layer · $250k | All six modules, two-node reference, six-month rollout, training, and support | Unlisted enterprise requirements or unlimited integrations |
| Enterprise · Contact sales | Custom depth across all modules, teams, entities, sites, governance, and rollout | Any capability not accepted into the signed Enterprise SOW |
Next: delivery
See how each package moves from evidence to acceptance.
Focused packages compress the gates; the complete Operating Layer uses the six-month sequence.