Follow Up: CRMy because my OpenClaw agent kept losing customer context. Looking for blunt feedback on latest go.

\*\*Disclosure\*\*: I’m the maintainer of CRMy. I posted an earlier version here and got useful feedback, so I wanted to come back with a more focused ask instead of just dropping a feature list. I’ve been using OpenClaw for GTM / customer workflows, and the hard part hasn’t been “can the agent write an email?” or “can it call a tool?” The hard part is: Before the agent acts, does it actually know the current customer state? Who is this person? What happened last week? What did the agent learn in a previous run? Is that context still true? Is there an open handoff or approval blocking progress? Can it update the CRM without creating duplicate, stale, or contradictory records? Most CRMs feel like they were built for humans clicking through dashboards. Then they bolted on MCP. Most agent memory tools feel too unstructured for revenue/customer work. I built \*\*CRMy\*\* as a customer context engine / operational state layer for agents. \*\*What it does:\*\* \* Runs on your own Postgres (or Neon, Supabase, whatever) \* Exposes MCP tools, REST, CLI, and a web UI \* Gives agents typed objects: contacts, companies, opportunities, use cases, activities, assignments \* Has a briefing\\\_get tool so the agent can pull the relevant customer state before acting \* Tracks context entries with staleness, confidence, and audit history \* Supports human-in-the-loop approvals and handoffs \* Has an OpenClaw plugin/skill so the agent knows how to use it The thing I’m trying to test is whether this is actually the right abstraction. I don’t want CRMy to become “yet another CRM with AI bolted on.” The belief behind it is that agents need durable, typed, auditable state before they can be trusted with real customer workflows. And because customer data is sensitive, I think that state should be self-hostable and open rather than trapped inside another SaaS layer. Where I’d love feedback from OpenClaw builders: 1. Would you trust an OpenClaw agent to mutate CRM/customer data if the writes are scoped, audited, and can require approval? 2. Would you want this as a standalone CRM, or more as a backend/memory layer that syncs with HubSpot, Salesforce, Pipedrive, etc.? 3. What would break first in a real OpenClaw workflow? 4. Is briefing\\\_get the right primitive, or should the agent reason through smaller tools? 5. What integration would make this immediately useful? Links: \* GitHub: \[https://github.com/crmy-ai/crmy\](https://github.com/codycharris/crmy) \* npm (CLI): \[https://www.npmjs.com/package/@crmy/cli\](https://www.npmjs.com/package/@crmy/cli) \* npm (OpenClaw plugin): \[https://www.npmjs.com/package/@crmy/openclaw-plugin\](https://www.npmjs.com/package/@crmy/openclaw-plugin) \* Info \\\[WiP\\\]: \[https://crmy.ai/\](https://crmy.ai/) Please tear apart the premise. I’m more interested in “this will fail because…” than stars.