I am launching Relaticle here next Tuesday. It is an open-source CRM where AI agents can do real work on your data, and I want feedback on one design decision before launch day.
Relaticle has two trust levels. External agents (Claude Desktop, Cursor, any MCP client) authenticate over OAuth and write through 37 tools directly, like an API client. The in-app assistant is stricter: every write it wants to make becomes a proposal card, and a person approves or skips it record by record before anything lands.
The question I keep going back and forth on: is per-record approval the right granularity, or does it become noise once you trust the assistant? Would you want a "trust this kind of change" switch, or does that defeat the point?
If you run a CRM with any AI in it today, I would like to hear where you draw that line. The whole thing is AGPL and self-hostable, including the model via Ollama, so you can look at how it works rather than take my word for it.
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?
@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?
@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?
@niveditha_patluri1 No reconnect needed, Nivy. Field changes show up the next time the agent fetches the workspace schema.
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?
@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?
@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.
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.
@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.
@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.
@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.