Record updatehigh-risk write
Acme Corp · industry
SoftwareB2B SaaS
whyTwo transcripts + website now describe a B2B SaaS product, not generic "Software".
Research → build plan · ac-python-api · CRM agent layer
Agentic CRM
An agentic CRM is not a chat box next to a database. It is a governed operating loop over customer context: capture interactions into memory, reason about what changed, propose or execute typed CRM actions, ask for approval when risk is high, and measure whether the action helped pipeline. AgencyCore already has the CRM, the signals and the background infra — what is missing is a thin, durable agent layer that wraps it.
Customer interactions→memory · reason · propose·human-gated tools→measured CRM action
00
What an agentic CRM is
tl;drThe market is converging on five ideas: capture everything into customer memory, put agents on the actual CRM data, give them typed actions and then govern them, make the review queue a product feature, and back it all with durable background runs. None of them is "auto-send everything". The defining choice is the same one Envoy makes — drafted by an agent, committed by a human until trust is earned.
7
Loop stages
observe → learn
4
Risk tiers
read · low · high · send
6
Tool guardrails
schema → verifier
4
MVP slices
analyst → autonomy
KEYA thin layer, not a greenfield system
The CRM already owns business logic, the database is storage only, comms and activities are first-class, signals are a live sales-intelligence layer, and Celery already runs slow background paths. The gap is a durable agent layer with runs, plans, approvals, policies, tool outcomes and evals. Build that — and only that — on top of the existing CRM domain.
01
The foundation we already have
inventoryEach existing component maps to an agentic extension. The point of the build map: the agent layer reuses what is already here, it does not replace it.
Existing componentAgentic extension
crm_communicationsinteraction memory · reply triage
crm_activitiesgenerated tasks · completion loop
crm_companies / crm_peoplerecord updates · dedupe · enrichment
crm_deals / pipeline_stagesdeal health · stage proposals
signals / company_signalssignal-to-action plays
crm_saved_filters / crm_liststarget cohorts · agent working sets
Celery + Redisdurable background agent runs
Nylasinbox events · draft & send tools
OrgScopedClient + RLSuser-parity tool permissions
02
The core operating loop
interactiveEvery agentic CRM feature fits one loop. It senses an event, resolves and plans, surfaces a proposal when risk is real, acts through typed tools, verifies the write, and learns — then the new CRM state seeds the next pass. Play the loop or click any stage to inspect it.
1sense
Observe
ingestA trigger arrives: an inbound email, a meeting transcript, a new buying signal, a CRM change, a schedule tick or a direct user prompt. Nothing is assumed — the loop starts from a concrete event.
The feedback edge is the product: Learn closes back onto Observe. Accepted, edited and rejected proposals all feed scoring features, eval fixtures and user preferences — so the loop that ran today is measurably better tomorrow, and "did the action help pipeline" is a metric, not a hope.
03
Target architecture
interactiveA gateway routes intent and checks policy, a durable runtime runs the loop, and three services hang off it — the typed tool gateway, the customer-memory retrieval service and the approval queue. Everything writes through the existing CRM services. Click any box to trace its connections.
04
The CRM tool gateway
playgroundThe first platform component. It turns CRM API capabilities into agent-safe typed tools — each tagged with a risk level that fixes its default autonomy and which guardrails apply. Pick a tool to see its tier and the rails it runs on.
Start as an internal Python registry over the existing FastAPI services; MCP for external assistants comes later, once the internal gateway is stable.
05
The review queue
interactiveWhere agent output becomes trustworthy. Each proposal shows a field-level diff and the evidence behind it. Low-risk items can auto-apply; record updates, stage changes, merges and sends wait for a human. Work the queue below.
5 awaiting review0 approved
Tasklow-risk write
Follow up with Dana Okafor
no open taskTask · due in 2 days
whyReply went quiet 6 days after a positive meeting; deal is in Negotiation.
Email draftexternal send
Re-engage Marco Reyes
no draftDraft ready to send
whyNew funding signal on Globex — timely reason to reach out.
Stage changehigh-risk write
Globex renewal → Closed won
NegotiationClosed won
whyCountersigned order form attached to the latest activity.
Mergehigh-risk write
Initech / Initech Inc
2 companies1 merged record
whySame domain, same primary contact, 94% match score.
!Approved means executed through the API
An approved proposal does not write to Supabase directly — it runs through the existing CRM services, and the execution writes an agent_runs, agent_tool_calls and agent_feedback record. The diff a reviewer saw is the diff the verifier checks after the write.
06
The four-slice MVP
interactiveBuild in four slices, each shipping a real product surface and each unlocking a little more autonomy than the last. Step through the slices to see what ships and why it comes in this order.
Slice 1
Read-only CRM analyst
Trusted answers from live CRM context.
autonomy
20%
- Natural-language questions across companies, people, deals, comms, activities and signals
- Account briefs, deal-health summaries and "what changed" answers
- Cites source records and timestamps
why this slice, hereExercises context retrieval and entity resolution with zero write risk. If the analyst cannot link the right record, nothing downstream is safe.
07
Principles & what not to build
guardrailsDo
Ground every action in evidence
Each proposal answers: what changed, which records support it, what will be changed, what is the risk, and why now. No evidence, no action card.
Do
Keep the CRM the source of truth
Agents generate summaries, plans and drafts. The CRM services stay the only path for canonical writes — agents never get a service-role shortcut to the database.
Do
Action cards over chat transcripts
Chat is good for intent; the review queue is better for work. A seller should batch-process proposed actions without reading a long agent transcript.
Do
Autonomy configurable by action class
always-ask for sends, merges and deletes; ask-first for stage changes and field overwrites; auto-apply for tasks and backfills; never-do for blocked domains.
DON'TWhat not to build first
Do not start with a swarm of autonomous agents — start with one CRM manager and a few high-quality tools. Do not let agents write directly to Supabase. Do not build free-form browser automation for actions you can expose as typed tools. Do not treat vector search as memory by itself. And do not optimize for "no human in the loop" before you have measured proposal-acceptance and edit rates.
Suggested first ticket: build
crm_agent_action_proposals plus a small internal CRM tool registry. A read-only agent loads a deal context bundle and produces proposed actions; the proposal stores entity refs, rationale, evidence, diff JSON, risk level and status; a user can approve, edit or reject; approved proposals execute through existing CRM services; every execution writes a run, tool call and feedback record. That one ticket is the foundation for every later agentic CRM feature.