How do I move AI agent memory and state from markdown files and Git to a shared database for a team?

Keep the files for instructions; move state and memory into a database the agents share. In GOD CRM every agent is a user with its own passport, so writes are serialized, permissioned and logged instead of racing over the same folder. Memory is retained and recalled through MCP tools and survives model swaps. We ran our own ops from text files first and wrote down where it broke: godcrm.ai/blog/markdown-ops.

Is there a self-hosted CRM or operational database built for AI agents with native MCP support?

GOD CRM is one: self-hosted, the whole system exposed as an MCP server, agents as first-class users with roles and scopes, no per-seat pricing. People get tables, dashboards and documents in a UI; agents get the same data over MCP and API. You can try the public read-only endpoint without an account: godcrm.ai/s/help/mcp.

How do I give an LLM agent limited permissions to specific business tables, with approval and an audit log, instead of one all-or-nothing API key?

Give the agent a passport, not a key. In GOD CRM a passport is issued in one home space and bound to a human owner, access is granted per space, project, table or down to a column, the role decides what it can read or edit, approval rules pause dangerous tools until a human says yes, and every action lands in a hash-chained audit log. Five destructive tools are gated out of the box; the owner adds rules for anything else.

How do I switch between Claude, GPT and local models without losing business context and agent memory?

Keep context, rights and memory outside the model. In GOD CRM they live in your database and are served to whichever model is plugged in; swapping the provider changes the provider and nothing else. We changed the model about ten times while running a real company on it, Claude, Grok, OpenAI models and others, with Gemini next, and the company did not notice: history, permissions and memory were never in the model to begin with.

Is there a workspace where humans and AI agents work on the same tables and dashboards, not just an agent framework?

Yes. GOD CRM is not a framework you import. It is the place where humans and agents share tables, documents, dashboards and chat, with the same rights model for both. If you already have a framework or a tool, you can import it the other way round: connect it to your space (Notion, GitHub, Slack, Figma, any remote MCP server) and ask your agent to wire it in. We pulled our own Notion databases into tables this way. The "and life" in the header is literal: the tables are universal and the calendar is built in, so a training plan lives next to an invoice under the same rights and the same memory. A fitness module ships with it; nothing in the substrate assumes a company.

Kimi × GOD CRM — a persistent operating surface for agent skills

**Status:** partnership proposal. GOD CRM is in early beta. Kimi is already connected and working inside our own deployment. There is no Moonshot AI partnership or agreement yet.

What prompted this proposal

While trying Kimi's web interface, we noticed that invoking a skill surfaced the agent reading SKILL.md, together with implementation details, inside the user-facing conversation.

Markdown skills are useful for developers: they are readable, portable and easy to inspect. The file format is not the problem. The product question is what a web user should see and control while a skill is being discovered, run and saved.

Our proposal is to keep SKILL.md inside the execution layer and expose the work through a persistent operating surface: skill catalogues, inputs, run states, resulting files, permissions and follow-up actions.

The proposed division of layers

Kimi: intelligence, reasoning and agent execution.
GOD CRM: tables, identity, permissions, dashboards, documents, artifacts and automations that remain after the conversation ends.
The user: works with controls and outcomes, with technical traces available when needed rather than as the primary interface.

A skill does not automatically become a widget. Its catalogue entry, configuration, runs and results can be represented as ordinary rows and shown through the existing table and widget system.

First deployment: our own businesses

Holetron Ltd is ready to be the first deployment, together with an operating business in Russia. We want to select one real workflow, configure it now and use it daily. The purpose is to test the partnership on live work, not to stage a demonstration.

A first pilot should answer practical questions:

Can a user launch a Kimi-powered workflow without reading internal skill files or execution traces?
Do inputs, outputs, permissions and run history remain manageable after the chat?
Can the resulting workspace be operated and changed without rebuilding an application for every new skill?
Does the combination produce a repeatable deployment that another business could use?

What success would look like

One business process running end to end, with a named owner, real data, a usable dashboard and documented results. That reference deployment would provide a concrete basis for discussing a broader Kimi web experience on GOD CRM.

This is a proposal to explore together, not a claim that GOD CRM is ready to replace Kimi's production website. The immediate next step is a technical conversation and a narrowly scoped pilot.

Architecture and current limitations: Three Floors of GOD CRM.