DGUI HUB NET: A Governed Human-to-Enterprise Agentic Workforce Architecture

DGUI HUB NET: A Governed Human-to-Enterprise Agentic Workforce Architecture

DGUI PERSONA, DGUI EMITTER, DGUI DOCKING STATION, DGUI TUFTY DEVICE, and DeckerGUI OS

Author: Wan Mohd Azizi Bin Wan Hosen (WMAi)
Role: Founder, Researcher and Developments — DeckerGUI Project
Date: 11 September 2026

Abstract

We present DGUI HUB NET, a proposed networking and deployment architecture within the DeckerGUI Unified Agentic AI Integration Ecosystem for connecting individual digital capabilities to enterprise work. The architecture begins with an Individual represented through DGUI PERSONA, a structured capability layer that combines DGUI DSYNC/DGM, DGUI Emitter, and DGUI DSYNC/KPI Tokenizer functions. The Persona initializes a cooperating DGUI Agent Swarm and exposes eligible individual AI agents to DGUI HUB NET for enterprise assignment or work requests.

DGUI HUB NET provides the coordination layer between individuals and companies. After an assignment is established, DGUI Emitter performs a proposed three-layer validation covering agent structure, governance, and operational/KPI prerequisites before minting a deployable DGUI Docking Agent. Docking Agent implementations may include Claw Agents, Hermes Agents, or customised agents such as LangChain-based runtimes. The resulting deployment instruction package, INSTRUCT.zip, is delivered to a company Docking Station, where the assigned agent is instantiated as a 1:1 operational agent instance.

The architecture further integrates the DeckerGUI Tufty Device and Docking Station as physical interfaces to DeckerGUI OS. The Docking Station supports Work, CICO, and Idle modes in the current Phase 3 design, while the Tufty/Decker device provides local AI computation, enterprise connectivity, encrypted local storage, and docking-based model or session updates. The proposed end-to-end lifecycle records assignment, work sessions, user/company associations, KPI events, and completion state. Following successful work, DGUI Emitter Studio can be used by a company to issue a Reward Key, defined in this architecture as an exclusive AI tooling or computational benefit sponsored by the issuing company.

This whitepaper is an architectural proposal and system specification, not a report of completed experimental validation. Quantitative performance, security, interoperability, and economic outcomes remain subjects for implementation and evaluation.

Keywords: DGUI HUB NET, DGUI PERSONA, DGUI Emitter, DGUI Docking Agent, DGUI Docking Station, DGUI Tufty, DeckerGUI OS, agentic AI, digital workforce, enterprise AI, KPI, agent deployment

**1. Introduction

1.1 Motivation**

Current AI systems are commonly organized around models, APIs, applications, or isolated agents. DeckerGUI approaches the problem from a workforce and infrastructure perspective: how can a person's validated capabilities be represented as a governed digital capability, organized into cooperating agents, connected to an enterprise, deployed through controlled infrastructure, and recorded throughout its working lifecycle?

The proposed DGUI HUB NET architecture addresses this gap. It treats the individual, the agentic runtime, the enterprise, the physical device, and the inference provider as distinct but interoperable layers. The central design principle is that the individual is not replaced by an AI clone. Instead, selected and authorized capabilities are structured into DGUI PERSONA and operationalized as an agent swarm.

The source architecture for DeckerGUI already defines Cloud, Local, and Enterprise operating modes, JSON-based configuration, workflow integration, KPI logging, task tracking, token-based access control, encrypted configurations, and SSL/TLS-secured communication. [1] Phase 2 extends this software foundation into a portable hardware device capable of local inference, enterprise connectivity, docking, model refresh, and encrypted local storage. [2] Phase 3 extends the hardware into a multi-purpose Docking Station with Work, CICO, and Idle modes. [3]

1.2 Contributions

We propose the following architectural contributions:

A DGUI PERSONA abstraction for representing an individual's selected and authorized capabilities.

A DGUI Agent Swarm model in which a Persona initializes a predefined set of cooperating AI agents rather than a single undifferentiated assistant.

DGUI HUB NET as a two-sided coordination layer for individual-to-company agent assignment and work requests.

DGUI Emitter as a proposed validation and minting authority for deployable DGUI Docking Agents.

DGUI Docking Agents as enterprise-side deployment/control agents supporting multiple runtime families, including Claw, Hermes, and customised agent implementations.

INSTRUCT.zip as a deployment instruction package for reconstructing the assigned agentic workload at the enterprise Docking Station.

A lifecycle model linking assignment, deployment, work telemetry, user/company records, completion, and Reward Keys.

A physical-software integration model connecting DGUI HUB NET with the DeckerGUI OS, Tufty Device, and Docking Station.

1. Related Work and Conceptual Positioning

2.1 AI Models and Agent Frameworks

Large language models and agent frameworks provide inference and execution capabilities, but they do not by themselves define a complete workforce lifecycle. DeckerGUI's proposed architecture therefore treats model providers and agent runtimes as replaceable implementation components. The governance, identity, assignment, deployment, and audit layers remain external to any single inference provider.

The existing DeckerGUI Agentic Market concept similarly moves from conventional model/application distribution toward certified Digital Jobs implemented as governed Agentic Containers. [4]

2.2 Digital Workforce Architecture

The DGUI Market material defines an Agentic Container containing a Primary Agent and appointed specialist agents such as Seed, Compliance, Runtime, Tool, Skill, Security, Audit, and Update agents. Execution is constrained by DGM governance and approved MCPs, tools, and skills. [4]

DGUI HUB NET extends this concept from the container level to the workforce-network level: it provides a path for an individual's agentic capability to be matched to an enterprise requirement, validated, deployed, monitored, and eventually rewarded.

2.3 Hardware-Software Integration

Phase 2 describes the Decker device as a portable personal AI interface supporting local inference, enterprise connectivity, encrypted storage, docking, and synchronization. [2] Phase 3 defines the Docking Station as a multi-purpose hub for enterprise and individual devices and specifies Work, CICO, and Idle operating modes. [3]

These capabilities provide the physical control plane for the proposed DGUI HUB NET deployment lifecycle.

1. Background and System Model

3.1 DeckerGUI OS

DeckerGUI OS is treated in this whitepaper as the software foundation through which Cloud, Local, and Enterprise inference environments can be routed. The Phase 1 design specifies a Mode Router for Cloud ↔ Local ↔ Enterprise routing, a DeckerConfig.json configuration mechanism, CLI and GUI interfaces, workflow-tool integration, KPI logging, task tracking, and token-based enterprise access. [1]

The proposed HUB NET architecture does not replace these mechanisms. It adds a workforce-network layer above them.

3.2 DGUI PERSONA

DGUI PERSONA is the proposed digital capability representation of an individual. It should contain only information that is authorized for digital representation and deployment. A Persona can include validated skills, experience-derived knowledge structures, workflow preferences, permissions, approved tools, KPI definitions, and an agent blueprint.

The distinction is fundamental:

Individual ≠ Persona ≠ Agent Swarm ≠ Docking Agent.

The Individual remains the human owner/participant. The Persona is a structured capability representation. The Swarm is the cooperating set of AI agents instantiated from that representation. The Docking Agent is the enterprise-side deployment and control component.

3.3 DGUI Agent Swarm

The DGUI Agent Swarm is a predefined multi-agent topology derived from the Persona. A typical structure can include a Primary Agent and appointed Knowledge, Skill, Workflow, Tool, Runtime, Compliance, Security, and Audit agents. The exact set is capability-dependent.

The swarm is structurally defined before enterprise deployment. This allows the system to validate the existence of required components and dependencies instead of relying on unrestricted runtime agent generation.

3.4 Inference Providers

Inference Model A and Inference Model B are treated as interchangeable inference providers in this architecture. The Persona and governance layers should remain logically independent of the selected model provider. A provider may execute inference locally, through an enterprise GPU server, or through an approved cloud service, subject to the configured operating mode and policy.

1. Proposed DGUI HUB NET Architecture

4.1 End-to-End Architecture

The proposed lifecycle is:

Individual → DGUI PERSONA → DGUI Agent Swarm → DGUI HUB NET → Enterprise Assignment → DGUI Emitter → Three-Layer Validation → Mint → DGUI Docking Agent → INSTRUCT.zip → Company Docking Station → 1:1 Agentic Deployment → Work → KPI/Audit → Reward Key.

DGUI HUB NET is therefore not the inference engine and not the enterprise runtime. It is the coordination and networking layer that connects individual digital workforce representations with enterprise work opportunities and deployment infrastructure.

4.2 HUB NET Core Functions

DGUI HUB NET is proposed to maintain or coordinate:

• Individual Persona availability and capability metadata.
• Enterprise work requests.
• Agent-to-company matching or assignment.
• Assignment identifiers and lifecycle state.
• Deployment notifications.
• User/company association records.
• Runtime status and completion events.
• Connectivity coordination.
• References required for gRPC and WebRTC-compatible communication.
• Centralized operational records required for audit and transparency.

The exact database schema, retention policy, transport security, and failure-handling behavior require implementation specification and testing.

4.3 Request and Assignment Model

The architecture supports two directions.

Individual-initiated request:
Individual → Persona → Swarm → HUB NET → suitable company/work opportunity.

Company-initiated request:
Company → HUB NET → capability requirement → matching → Individual Persona/Swarm → assignment.

The assignment should produce a stable Assignment ID that links the user, company, Persona, agent instance, work period, and deployment lifecycle.

1. DGUI Emitter and Agent Minting

5.1 Emitter Role

DGUI Emitter is proposed as the validation, packaging, and minting authority. Its purpose is to convert an eligible agentic workload into a recognized DGUI-deployable object while preserving the governance and operational metadata required by the receiving enterprise.

The Emitter should not be interpreted as minting the human or copying a person's identity. It mints a deployable AI-agent object derived from an authorized Persona and assignment.

5.2 Three-Layer Validation

The proposed validation pipeline contains three gates:

Layer 1 — Structural Validation:
Checks the Primary Agent, required sub-agents, dependencies, manifests, runtime requirements, tools, and skills.

Layer 2 — Governance and Security Validation:
Checks DGM policy, permissions, approved tools, approved MCPs, security restrictions, and execution boundaries.

Layer 3 — DSYNC/KPI Operational Validation:
Checks user association, company association, Assignment ID, session identity, KPI schema, telemetry requirements, and audit requirements.

Only a package that passes all required gates proceeds to minting.

5.3 DGUI Docking Agent Types

A minted DGUI Docking Agent is an enterprise-side deployment/control agent. Its implementation type may vary:

• Claw Agent.
• Hermes Agent.
• Customised Agent.
• LangChain-based customised implementation, where appropriate.

The runtime framework is therefore an implementation choice; the DGUI contract defines the surrounding identity, validation, assignment, governance, telemetry, and deployment requirements.

5.4 INSTRUCT.zip

INSTRUCT.zip is proposed as the deployment instruction package generated after validation and minting. It may contain a Persona reference, Agent Manifest, agent configuration, runtime requirements, policy references, tool/skill references, KPI configuration, assignment metadata, and integrity information.

INSTRUCT.zip should be treated as a deployment package rather than as a copy of a human or a generic model archive.

1. DGUI Docking Station and DGUI Tufty Device

6.1 Tufty Device

The Phase 2 Decker hardware is described as a mini portable device that provides local AI computation, automated synchronization, a personal workspace, enterprise Work Mode, docking support, hybrid local/enterprise/cloud AI functionality, encrypted storage, token-based authentication, audit logs, and KPI tracking. [2]

Within the proposed HUB NET architecture, the Tufty/Decker device acts as a personal endpoint for the individual's DeckerGUI environment and can provide the local execution or control surface for a Persona and its associated agents.

6.2 Docking Station

The Phase 3 Docking Station is defined as a multi-purpose hub with single, double, or triple docking slots. It supports three modes:

Work Mode: connects to the enterprise LLM server and requires staff authentication; removal of the device terminates the work connection.

CICO Mode: records work hours and updates enterprise KPI and timesheet systems.

Idle Mode: supports maintenance, updates, synchronization, offline model updates, security patches, and requested fine-tuning. [3]

The proposed DGUI HUB NET deployment model uses the Docking Station as the physical enterprise boundary at which a deployed agentic workload can be received and instantiated.

6.3 Enterprise Deployment

A company receives INSTRUCT.zip at its Docking Station. DGUI Docking Agents validate the package locally, establish the approved runtime, and instantiate the assigned Individual AI Agent as a 1:1 operational agent instance.

The term 1:1 refers to equivalence of the validated agent structure/configuration for the assignment. It does not imply a copy of the person's consciousness, unrestricted identity, or private information.

1. Runtime, Networking, and Telemetry

7.1 Centralized HUB NET Database

The proposed centralized database records the coordination state of DGUI HUB NET. A deployment event can include Agent ID, Persona ID, User ID, Company ID, Assignment ID, deployment status, start time, runtime status, and completion state.

This produces a chain of custody for the digital worker from assignment through completion.

7.2 gRPC and WebRTC Compatibility

The architecture proposes gRPC and WebRTC compatibility as connectivity mechanisms. gRPC can support structured service-to-service communication between DGUI components, while WebRTC can support appropriate real-time peer/session communication.

These technologies are transport mechanisms, not definitions of the Persona or agent identity. The final protocol selection, authentication, encryption, NAT traversal, service discovery, and observability mechanisms remain implementation work.

7.3 User and Company Transparency

Each work session should be associated with both the Individual/User and the Company. A conceptual event chain is:

User → Persona → Agent → Assignment → Company → Session → Query/Tool Event → KPI Event → Completion.

The design goal is bilateral transparency and record keeping. Exact query retention, privacy controls, redaction, access permissions, and legal retention periods must be defined before production deployment.

1. Digital Workforce Lifecycle

8.1 Lifecycle State Machine

The proposed lifecycle is:

REQUESTED → MATCHED → VALIDATING → MINTED → DEPLOYED → ACTIVE → COMPLETED → REWARDED → ARCHIVED/AVAILABLE.

Each transition should generate a machine-readable event. Failed validation should terminate or return the assignment to an appropriate pre-deployment state.

8.2 Example: Individual-to-Company Deployment

An individual first develops or receives a DGUI PERSONA. The Persona initializes an agent swarm appropriate to the individual's authorized capabilities. The swarm becomes eligible for DGUI HUB NET. A company either requests a capability or accepts a suitable assignment. DGUI Emitter validates the agent package, mints the Docking Agent, and produces INSTRUCT.zip. The company Docking Station receives the package and instantiates the 1:1 agent instance. During the work period, events and KPI records are associated with both the user and company. On completion, the company can issue a Reward Key through DGUI Emitter Studio.

8.3 Reward Key

A Reward Key is defined in this architecture as an exclusive AI tooling or computational benefit issued by the company that sponsored the work. The key may provide access to company-sponsored cloud computing, inference capacity, AI tools, or other defined benefits.

The Reward Key is therefore part of the proposed digital workforce incentive loop, not a replacement definition for salary, employment compensation, or legal remuneration.

1. Security, Governance, and Trust Model

9.1 Governance Before Execution

The DeckerGUI Agentic Market architecture places DGM governance, approved MCPs, approved tools, and approved skills before secure execution. [4] DGUI HUB NET should preserve the same principle: an agent should not gain enterprise authority merely because it can connect to a company.

Enterprise authority must be assigned explicitly and constrained by the deployment contract.

9.2 Identity and Authorization

The architecture should separate User Identity, Persona Identity, Agent Identity, Assignment Identity, Company Identity, and Session Identity. This separation prevents a runtime agent from being treated as the human owner and makes lifecycle auditing possible.

9.3 Credential Handling

The existing Agentic Market material defines a Seed Agent for credential governance, including API seed management, provider validation, credential rotation, temporary runtime tokens, and prevention of direct API-key exposure. [4] This mechanism can be integrated with the proposed Docking Agent lifecycle, subject to implementation validation.

9.4 Privacy and Data Boundaries

Because work queries may be associated with both users and companies, privacy-by-design is required. The architecture should support data minimization, explicit access controls, audit trails, retention rules, redaction where required, and separation of personal Persona data from enterprise work data.

The architecture described here does not establish legal compliance by itself; production deployment requires jurisdiction-specific review and organizational policy.

1. Application Scenarios

10.1 Individual Workforce Participation

A normal individual can maintain a DGUI Persona and make an eligible agent swarm available for suitable Digital Jobs. The same infrastructure can support different levels of capability as the Persona evolves.

10.2 Accessibility

The architecture separates physical circumstances from digital capability. For example, a person with a mobility disability may use an accessible DGUI interface while participating in software engineering or other digital work. The system should evaluate capability and authorization rather than physical mobility as a proxy for digital competence.

10.3 Experienced Retiree

An experienced professional can contribute selected, validated knowledge through a Persona. For example, maintenance expertise may be structured into knowledge, inspection, troubleshooting, documentation, compliance, and audit agents. Human validation remains essential for safety-critical industrial knowledge.

10.4 Enterprise Use

An enterprise can request a Digital Job, receive an eligible agentic workforce package, deploy it through the Docking Station, and track the assignment lifecycle. The architecture is intended to support both enterprise-controlled inference and approved external inference providers.

1. Evaluation Plan

11.1 System Evaluation

The source hardware specifications identify setup/connection time, offline inference latency and reliability, docking synchronization success, security compliance, unauthorized-access prevention, and user satisfaction as evaluation metrics. [2] The proposed HUB NET layer adds:

• Assignment matching latency.
• Emitter validation success/failure rate.
• INSTRUCT.zip deployment success rate.
• 1:1 instantiation integrity.
• gRPC/WebRTC session reliability.
• Event delivery latency.
• KPI record completeness.
• Work-session reconciliation accuracy.
• Reward issuance success rate.
• Recovery from disconnected or failed Docking Stations.

11.2 No Experimental Claims

No experimental measurements are claimed in this whitepaper. The architecture is a proposed technical design assembled from the supplied DeckerGUI Phase 1–3 material and the DGUI Agentic Market concept. Benchmarking and production validation remain future work.

1. Analysis and Discussion

12.1 Why the Architecture Matters

The principal architectural shift is from an AI assistant model to a digital workforce lifecycle. The model provider becomes one replaceable component. The agent framework becomes another implementation layer. DeckerGUI's value is concentrated in the coordination, governance, deployment, hardware integration, telemetry, and workforce lifecycle around those components.

12.2 Strengths

The proposed architecture provides clear separation between human identity and AI execution, supports multiple inference providers, supports multiple agent runtime families, introduces an explicit enterprise deployment boundary, creates traceable assignment state, and links work completion to a defined reward mechanism.

12.3 Limitations

The design remains conceptual in several areas. DGUI HUB NET's database schema and discovery mechanisms are not specified in the supplied material. gRPC/WebRTC interoperability is proposed but not experimentally demonstrated. The three-layer Emitter validation pipeline is a proposed design based on the requested architecture rather than a validated implementation. Reward Key economics, rights, expiry, transferability, and accounting treatment also require specification.

1. Conclusion and Future Work

13.1 Conclusion

We presented DGUI HUB NET as a proposed architecture for connecting individual human capabilities to enterprise digital work through DGUI PERSONA, DGUI Agent Swarm, DGUI Emitter, DGUI Docking Agents, INSTRUCT.zip, the Docking Station, the Tufty/Decker device, and DeckerGUI OS.

The central lifecycle is:

Individual → Persona → Swarm → HUB NET → Assignment → Emitter Validation → Mint → Docking Agent → Enterprise Dock → Work → KPI/Audit → Reward Key.

This architecture positions DeckerGUI as an integration and governance system around agentic work rather than as a single AI model. It preserves the distinction between the person, the person's digital capability representation, the deployed AI agents, the enterprise runtime, and the inference provider.

13.2 Future Work

An interesting direction for future work would be to implement the HUB NET data model and service interfaces, formalize the Emitter validation specification, define the DGUI Docking Agent contract, implement secure package signing and verification, test Claw/Hermes/custom runtime adapters, validate gRPC and WebRTC communication paths, develop Persona versioning, evaluate KPI and telemetry integrity, and experimentally study the Reward Key mechanism.

References

[1] DeckerGUI Project, “Phase 1 Overview – DeckerGUI Project,” supplied project specification, 2025.
[2] DeckerGUI Project, “Phase 2 Overview — Decker Hardware Integration,” supplied project specification, 2025.
[3] DeckerGUI Project, “DeckerGUI Docking Station (Phase 3) Overview,” supplied project specification, 2025.
[4] Wan Mohd Azizi Bin Wan Hosen (WMAi), “Beyond AI Agents: Building a Digital Workforce Operating System,” DeckerGUI Agentic Market, supplied project material, 2026.

Author and Project

Project: DeckerGUI OS Ecosystem
Author: Wan Mohd Azizi Bin Wan Hosen (WMAi)
Role: Founder, Researcher and Developments