Launched this week
Relaticle
Open-source CRM with approval-gated AI writes
274 followers
Open-source CRM with approval-gated AI writes
274 followers
Most CRMs bolt AI on. Relaticle is built agent-first: any MCP client gets 37 first-party tools over OAuth, with workspace custom fields in each agent's schema automatically. The in-app assistant is stricter: every write is a proposal showing the exact change, approved record by record. Self-host everything under AGPL, including local inference with Ollama. Free forever self-hosted; Cloud is flat per-workspace pricing, not per-seat.
Flat per-workspace pricing on the cloud tier is the right call for a CRM: per-seat is how you get three people sharing one login.
How do you stop the flat price from being a bad deal for a solo founder and a steal for a 30-person team? Usage caps, or you just accept the spread?
Relaticle
@lmfresneda The cap sits on the part that actually scales with use: 2,000 AI credits a month per workspace, with prepaid top-ups if you burn through them. Users and records stay unlimited, because a seat costs me almost nothing to serve while the assistant costs me per token. So a 30-person team pays more when it works the assistant harder, and I take the spread everywhere else.
Approval gated writes is the piece I keep rewriting in my own tooling. Where did you land on the granularity, one approval per write or one per session?
Relaticle
@tomveber Per plan, not per session. One turn produces one proposal card even when the assistant chains several writes, and you approve that once. If the proposal covers multiple records, you approve or reject them one at a time inside the card. No session-wide trust switch, that seemed like the kind of thing that goes wrong quietly.
@manukminasyan the two trust levels for ai writes is an interesting decision. i can see why silent changes to crm data would make people nervous. curious if you have found users prefer approving every change or if they’re already asking for some writes to be automated?
Relaticle
@sagar_deore Too early for me to claim a real pattern, we are early in paid usage and I would rather not invent one. My bet is the ask lands on faster approval rather than no approval, and that is where the work went: one card for a whole multi-step plan instead of five separate prompts, plus per-record approve or reject in a batch. Silent writes to CRM data feel like the last thing to add, not the first.
37 tools over oauth for any mcp client, and the workspace custom fields land in each agent's schema on their own. do they refresh live or only on reconnect?
Relaticle
@niveditha_patluri1 No reconnect needed, Nivy. Field changes show up the next time the agent fetches the workspace schema.
Softorino 💻📲
Really like the approach here! Letting AI do the heavy lifting while keeping users in control of every change feels like the right balance. Have you considered adding customizable approval rules for low-risk updates?
Relaticle
@yelyzaveta_kibets Thanks, Lisa! A few people have asked about this today. I’m considering it, though deciding what counts as low risk is tricky. Which updates would you want to skip approval for?
Softorino 💻📲
@manukminasyan I would draw it at additive. Let it add a note or a field on its own, and require approval when it overwrites or deletes anything already there.
Dial
On the auto-approval question, I'd be wary of it even with policy rules. The whole pitch here is that the assistant's writes are legible to a human before they land, and policy-based auto-approval is basically a slow reintroduction of silent writes once someone gets tired of clicking approve. If anything I'd want auto-approval scoped to read-adjacent stuff like tagging or dedup, never to fields that touch pipeline value or contact ownership. That said, 37 tools over MCP with OAuth is a lot of surface area for a two-year solo project, curious how much of that is generated vs hand-written.
Relaticle
@galdayan @galdayan Fair concern. I’d be cautious with dedup too. One clarification: approval applies to in-app chat; MCP writes execute directly within granted permissions.
I wrote the code by hand before Opus. Since then, I’ve used it to help write code, reviewed every line, and made the architecture decisions myself.
Dial
@manukminasyan that clarification is actually the part that would make me pause before connecting a real MCP client - "approval-gated" only describing the in-app chat path, while any MCP client with OAuth access writes directly, means the safety property lives in the UI, not in the CRM itself. worth being upfront about that distinction on the landing page, since someone skimming would assume approval-gating covers both. good to hear the code is hand-written and reviewed though, that answers my other question.
I like the smaller recovery details here too. Keeping failed sends visibla and drafts intact after a reload sounds minor, until an assistant is working with actual CRM records.
Relaticle
@znu Those details decide whether people leave the assistant switched on. A send that fails quietly, or a draft lost to a reload, costs more trust than a missing feature does. Cheap to build too, which is why it is easy to skip.