An early-stage architecture and fork foundation for agent-native marketing operations.
DMClaw asks a systems question: what would a marketing organization look like if AI capabilities were organized around context, authority, memory, and accountable approval—not a collection of disconnected agents pretending to be departments?
DMClaw is currently at Phase 0. The repository contains a one-way fork of OpenClaw v2026.3.13-1, a reduced and rebranded gateway foundation, and public design work for the marketing-specific system.
The vertical layers described below—identity cascade, operational configuration, orchestration, knowledge infrastructure, marketing capabilities, memory, and model routing—are proposed architecture. They are not yet implemented as a production-ready marketing operating system. See FORK_NOTES.md for the exact inherited/build-new boundary.
- Identity cascade: agency context → brand context → campaign context, with explicit inheritance and overrides.
- Autonomy dial: authority set per capability, client, and task type instead of one unsafe global mode.
- Capabilities, not simulated departments: composable content, SEO, paid media, creative, analytics, reporting, and strategy workflows behind common contracts.
- Quality gates: defined pass/fail criteria and feedback routes between workflow stages.
- Knowledge and memory: brand knowledge, trusted sources, decisions, campaign history, and organizational learning treated as infrastructure.
- Human accountability: consequential outputs remain reviewable, attributable, and governed by explicit approval rules.
The fork foundation retains selected OpenClaw infrastructure:
- gateway, sessions, authentication/RBAC, event and agent runtime foundations;
- selected messaging-channel adapters and plugin infrastructure;
- admin UI, build tooling, Docker setup, tests, and security policy;
- a reduced set of upstream extensions and skills.
DMClaw-specific work currently lives primarily in the architecture, requirements, fork-boundary, and engineering documents. The next meaningful milestone is implementing the identity and operational-context layer against this foundation.
- Product architecture — proposed layers, design decisions, risks, and build sequence.
- Fork notes — what was kept, removed, and explicitly left to build.
- Architecture context — interfaces and technical decisions.
- Engineering standards — rules for future implementation work.
- Security policy — supported versions and private vulnerability reporting.
DMClaw is not seeking broad feature expansion while its vertical foundation is still being established. Focused corrections to documentation, security, build reliability, and the stated fork boundary are welcome; see CONTRIBUTING.md.
Indranil “Neel” Banerjee is a builder and systems thinker with roots in information security and a second act across growth marketing, enterprise digital operations, and AI transformation. DMClaw is one public exploration within a broader interest in trustworthy AI execution and agent-native organizational infrastructure.
If this architecture or its documentation is useful, GitHub Sponsors helps fund maintenance, compatibility work, and carefully scoped experiments in the open. Sponsorship does not create a private support queue or a delivery commitment.
MIT — see LICENSE. The retained upstream code and attribution remain governed by the repository license and fork history.