Your CRM should fill itself in.

Every CRM I have ever watched a team use decayed at roughly the same rate, for the same reason. The data entry is somebody's job but nobody's priority. A customer mentions on a call that they've moved to a new company; the person who heard it doesn't own the record; nothing happens. Six months later the segment is wrong, the campaign goes to a dead address, and someone declares that the CRM needs cleaning up.

What does a self-filling CRM actually mean?

It means the record is maintained by agents reading the conversations you already had, rather than by a person retyping what a customer just told them. New contact arrives, gets enriched. A support thread reveals a job change, the record updates. Duplicates surface as proposals instead of accumulating.

The important half is the boundary: some of that applies automatically, and some of it can only be proposed. Which is which is a design decision, not a confidence threshold.

Where does the data come from if nobody types it?

From three places you already have. What customers volunteer about themselves in support threads and chats. What's publicly on their company's website. And the behavioural record — which pages they read, which threads they opened, how recently they did anything.

The reason this works in Munin and not in a typical stack is that all three live in the same database. Conversations, CRM, knowledge, content, outreach, and analytics share one Postgres schema and one contacts table, so the pass that enriches a contact and the campaign that later targets them are reading and writing the same row. No integration, no sync lag, no second version of the truth about who this person is.

Which passes do the work?

Four, each a markdown skill you can read and edit, run on a schedule or fired by an event:

• 01On signup — enrich. Lead research reads the new contact's company site and fills in role, seniority, and industry, then stamps a short summary on the record with crm_set_ai_summary. Applied directly: it's public information and it's trivially correctable.
• 02On close — identity. Contact extraction reads a finished conversation for what the customer said about themselves — name, company, phone — and writes it to the CRM. Also applied directly, because the customer said it about themselves, unprompted.
• 03Weekly — fit and intent. Lead scoring walks a segment, weighs enrichment data against conversation tone and activity recency, and stamps each contact with a score and a one-line rationale. A hint for humans, not a gate.
• 04Weekly — duplicates. Contact hygiene sweeps for likely duplicate pairs and files them as structured merge proposals with a confidence figure. You apply or dismiss. The agent never merges two customers on its own.

Why doesn't this just fill your CRM with plausible garbage?

Because the destructive verbs aren't available to the agent. Merging two contacts is a separate, narrowly-scoped, separately-audited tool that only proposes — so the worst case for a confused or prompt-injected agent is a bad row in a review queue, not two customers welded together.

That split runs on reversibility rather than confidence. Writing a job title is cheap and reversible: wrong, you fix it in a second, nothing left the building. Merging two records destroys information and can't be cleanly undone. So the cheap verb is abundant and the expensive one requires a human, regardless of how sure the model claims to be. The review queue isn't a stopgap until the automation gets good enough — it's where the judgment lives.

What does it look like after a month?

Unexciting, which is the point. Contacts have roles and companies filled in without anyone having typed them. The segment you send a campaign to is current because it was maintained continuously rather than cleaned up in a panic beforehand. There's a small queue of merge proposals waiting, which takes a few minutes to work through.

The change isn't that work disappeared. It's that the work left is the part that needed a person: deciding whether these two records really are the same customer, whether this contact should be in this campaign at all. It is the same loop that turns resolved support handovers into knowledge base articles — a by-product of work that already happened, filed where it will be useful the next time somebody needs it.

What won't this do?

It won't invent data that isn't anywhere. If a contact never said their job title and their company has no website, the field stays empty — and that's correct behaviour, not a gap.

It reads what a company publishes, not a licensed firmographic database. If you need verified firmographics at scale — headcount bands, funding history, technographics across fifty thousand accounts — buy them from a data vendor built for exactly that. That is a real product category and it does a real job.

And the scoring pass works from the signal you already hold: what the customer said, what their site says, what they did. Treat fit and intent scores as a reading order for a human, not as a decision. We say the same thing in the skill itself, so the agent doesn't oversell them either.

What you get in exchange is a record that is traceable. Every field these passes write comes from something a customer said in a thread you can open, or something published on a page you can visit — not a probability bought from a third party and refreshed on somebody else's schedule. And because it all lands in the same contacts table your inbox, knowledge base, and campaigns already read from, a correction you make once is correct everywhere the moment you make it. Buy the firmographics if you need the breadth; the passes will keep filling in around them from the conversations only you have.

Frequently asked questions

Can AI keep my CRM data up to date automatically? Yes, for anything derivable from sources you already hold — what customers say in support conversations, what's public on their company site, and their behaviour in your product. In Munin these run as scheduled or event-fired agent passes: enrichment on signup, identity extraction on conversation close, scoring and duplicate detection weekly.

Will an AI agent merge my contacts incorrectly? It can't merge them at all. Duplicate detection only files structured merge proposals with a confidence figure; a human applies or dismisses each one. The split isn't about how confident the model is — it's that merging destroys information and can't be cleanly undone, so it requires a person by design.

How does automatic enrichment handle GDPR and consent? Consent state lives on the contact record and is checked before outreach runs, so enrichment and permission to contact are separate decisions. Munin Cloud is EU-hosted. Tag bulk imports with the batch so a bad data source can be filtered back out later.

Which model does this use? Whichever you point at it. Munin exposes the work as MCP tools and markdown skills, so Claude, ChatGPT, Gemini, or a local model can run the passes. The AI cost is what your provider charges, not a per-action fee to us.

Do I have to use all four passes? No. They're independent markdown skills — run one, run all four, or edit the ones that don't match how you work. Most teams start with enrichment on signup because it's the easiest to verify.

What happens when the agent gets it wrong? Every tool call is audited, and the cheap writes are cheap to reverse — that's why they're the ones allowed to apply directly. Edit the record and the correction is logged; edit the skill and the behaviour changes next run.

Every pass is markdown you can read before you trust it. The agent recipes are the place to start, and Munin Cloud is free to try one on.

A CRM nobody maintains isn't a CRM. It's a spreadsheet with a login.