Agent CRM

The CRM built for AI agents to operate — not for humans to click through.

---

What's actually happening above: your agent — whatever it already is — connects over MCP or REST without any change to its own logic, and the terminal shows the same five real tool calls covered in the proof section below. If your GitHub client doesn't render inline SVG animation, the architecture diagram and proof section spell out the same flow statically.

The problem

AI sales agents are already browsing the web, calling prospects, and managing pipelines — but every CRM they touch was built for a human clicking through forms and dashboards. The agent ends up scraping a UI meant for eyes and fingers, not for a tool call.

Agent CRM flips that. The dashboard is optional. The API is the product.

What makes this different

	Traditional "AI-native" CRM	Agent CRM
Primary user	A human, assisted by AI	An autonomous AI agent
Interface	Dashboard, forms, buttons	MCP tools + REST API
Onboarding	Human signs up, invites team	Agent signs itself up, zero clicks
Data entry	AI fills the CRM for a human	Agent is the operator
Safety	—	Dry-run previews, idempotent retries, full audit trail

Architecture

flowchart LR
    Agent["AI Sales Agent"] -->|"MCP tools"| Core
    Human["Human (read-only)"] -->|"Dashboard / REST"| Core

    subgraph Core["Agent CRM"]
        Logic["Core business logic\n(single source of truth)"]
        Track["Idempotency + Audit trail\n+ Dry-run engine"]
        Logic --- Track
    end

    Core --> DB[("Multi-tenant database\nAccount-scoped")]

Loading

One shared logic layer means the MCP tools and the REST API can never drift out of sync. Every write passes through the same tracking layer, so every account gets idempotent retries, a full audit trail, and dry-run previews for free — not bolted on per-endpoint.

Zero-human onboarding

sequenceDiagram
    participant Agent
    participant Server as Agent CRM (no account configured yet)
    Agent->>Server: signup(company_name="Acme AI Sales")
    Server-->>Agent: { api_key: "acrm_..." }
    Note over Agent,Server: Agent reconnects with the key
    Agent->>Server: create_lead(), create_deal(), log_activity()...
    Server-->>Agent: full CRM, no human touched a config file

Loading

No bootstrap script. No admin approving a signup form. An agent that has never seen this system before can provision its own account and start working inside a single conversation.

Proof it works — a real autonomous run

This isn't a scripted demo. An unattended Claude Code session (claude -p, non-interactive, no step-by-step instructions) was given one goal — "manage a pipeline using your own judgment" — and left to run. This is exactly what landed in the database afterward:

Lead	Deal	Value	Stage	Why
Rachel Kim, Brightline Logistics	Fleet Tracking Rollout	$42,000	Proposal	Discovery call surfaced strong fit; proposal sent same day
Marcus Feld, Northgate Dental	Patient Scheduling Suite	$9,600	Prospecting	Interest confirmed, but no budget or next step yet — agent chose not to overstate progress
Priya Sundaram, Hearthstone Realty	CRM Expansion Pack	$18,500	Negotiation	Broker team reviewing proposal, pushing back on price

Three different stages, three different reasons, chosen by the agent — not a human, not a template. Verified directly against the database record, not the agent's self-report.

Engineering principles

• One logic layer, every interface. MCP tools and the REST API both call the same core functions — there is no second implementation to drift out of sync.
• Idempotent by construction. Every write accepts an idempotency_key; a retried call returns the original result instead of a duplicate row. Agents retry constantly — the system assumes that as normal, not exceptional.
• Dry-run as a first-class mode, not a flag bolted on later. Any write can be previewed — fully validated, nothing persisted — before an agent commits to an irreversible action.
• Multi-tenant at the schema level. Every row carries an account_id; every query is filtered by it. Isolation is enforced by the data model, not by convention.
• An audit trail that costs nothing to add later — because it was designed in from the first write, not retrofitted after a trust problem.

Data model

erDiagram
    ACCOUNT ||--o{ LEAD : owns
    ACCOUNT ||--o{ DEAL : owns
    LEAD ||--o{ DEAL : has
    DEAL ||--o{ ACTIVITY : logs
    LEAD ||--o{ ACTIVITY : logs

Loading

Stack

Python · FastAPI · SQLAlchemy · SQLite (dev) / Postgres (prod) · MCP · pytest

Plugging into your existing agent stack

Nothing about your agent's own logic has to change. It just needs one new tool it can call — over whichever protocol it already speaks:

flowchart LR
    subgraph Stack["Your existing agent stack"]
        Agent["Claude / GPT-4 / a custom agent\n(already running today)"]
    end

    Agent -->|"MCP tool calls (stdio)"| Core
    Agent -->|"or REST over HTTP"| Core

    subgraph Core["Agent CRM (this repo)"]
        Logic["one core logic layer\nidempotent · audited · dry-run safe"]
    end

    Core --> DB[("Multi-tenant DB\naccount-isolated rows")]

Loading

• Already using an MCP-compatible runtime (Claude Code, Claude Desktop, or anything that spawns MCP servers)? Add agent-crm to its MCP config, no code changes on your side.
• Everything else — a custom agent loop, a different framework, anything that can make an HTTP call? Hit the REST API directly with the same idempotency and dry-run guarantees.

Both paths call the exact same functions underneath, so there's no "REST version" that's behind or a "real" MCP version that gets the features first — see Engineering principles.

Integrating an agent

Agent CRM is built to be consumed as an API, not cloned and read. Deploy an instance, provision an account, connect via MCP or REST, and start operating: API.md.

---

Built on Y Combinator's "Software for Agents" thesis: the next major rebuild of enterprise software won't come from incumbents bolting AI onto existing dashboards — it'll come from tools built agent-first from day one.