IMPERIAL CRM Agent Professional

Mission: IC-CRM-AGENT-PROFESSIONAL-SKILL-001 Version: 1.0.0 Status model: REGISTERED -> CONFIGURED -> TESTED -> RUNNING -> LIVE -> AUTONOMOUS

Purpose

Provide IMPERIAL Core with a reusable AI-native Revenue & Relationship Intelligence capability for contacts, companies, leads, opportunities, tasks, communications, relationship graphs, revenue intelligence and governed agent-to-agent CRM.

This skill is not a global orchestrator. It is a federated capability that can be granted to NCA and specialized agents by policy.

Canonical architecture

Preserve the IMPERIAL Core boundaries:

Federated Multi-Orchestrator -> Runtime Domain -> AI Passport -> Capability Policy -> CRM Skill -> Guardian Core -> Approval Gateway (when required) -> Authorized Action -> Audit Ledger

Mandatory principles:

  • Zero Trust and deny-by-default.
  • Identity is not authority.
  • Capability knowledge is not capability grant.
  • Recommendation is not authority.
  • ORION remains ALWAYS_ON advisory/coordination only.
  • T2 external communication is not executed by the baseline skill without connector policy and approval.
  • T3 commercial commitment and payment-destination modification are never autonomously executed by this skill.
  • Sensitive CRM data must stay behind the Private Boundary; public status endpoints may expose health metadata only.
  • CRYPTO IMPERIAL Ecosystem Boundary remains separate from CRM data and recommendation logic.

Capability interface

Baseline T0/T1 capabilities:

  • crm.contact.create
  • crm.contact.search
  • crm.contact.update
  • crm.company.create
  • crm.company.search
  • crm.lead.create
  • crm.lead.qualify
  • crm.lead.score
  • crm.opportunity.create
  • crm.opportunity.update
  • crm.pipeline.read
  • crm.task.create
  • crm.task.complete
  • crm.communication.log
  • crm.followup.recommend
  • crm.relationship.create
  • crm.relationship.map
  • crm.revenue.analytics
  • crm.audit.read

Controlled capabilities:

  • crm.communication.send = T2, denied by baseline and requires connector policy/approval.
  • crm.commercial.commit = T3, Approval Gateway required; baseline CRM never executes it autonomously.
  • crm.payment.destination.change = T3, high-risk; Approval Gateway required and Guardian review mandatory.

Data model

Project-scoped storage uses separate CRM tables:

  • crm_agents — agent binding, role/domain, status, AI Passport identifier, granted capabilities.
  • crm_companies — account/company profile.
  • crm_contacts — contact profile, consent status, owner-scoped dedupe key.
  • crm_leads — source, intent, score, qualification and next action.
  • crm_opportunities — stage, value, probability, close date, blockers, competitors, risk and evidence.
  • crm_tasks — owner, object, status, priority, deadline and evidence.
  • crm_communications — canonical interaction event log. Baseline logs events; it does not send external messages.
  • crm_relationships — Human/Company/NCA/Agent/Partner/Vendor/Service relationships.
  • crm_risk_events — Guardian-style risk findings with input SHA-256 instead of raw secret-bearing evidence.
  • crm_audit — policy decision, approval state, result, evidence and SHA-256 event hash.

CRM memory remains isolated from uncontrolled general agent memory. Local runtime storage and canonical shared memory are distinct trust layers.

Canonical shared CRM memory

A governed canonical-memory layer is now implemented through canonical_sync.ts and the Supabase imperial-crm-bridge service. It uses a dedicated CRM-only server credential, SHA-256 credential verification, append-only hash-chained events, current-state projection, unauthorized-request denial, and explicit read-back/chain verification.

This layer is TESTED for authenticated append, entity read-back, unauthorized 401 denial, and chain verification from the three governed Val Town runtime projects. Automatic replication of every local CRM CRUD mutation is NOT IMPLEMENTED yet; canonical synchronization is an explicit governed API and must not be described as transparent full replication.

Lead Intelligence

Pipeline:

Lead -> Enrichment -> Qualification -> Scoring -> Assignment -> Follow-up Recommendation -> Opportunity

The reference scorer is deterministic and explainable. It uses source, stated intent, engagement, fit, budget signal and consent. If consent is explicitly false, the score is capped and external follow-up remains prohibited.

No model-generated revenue or probability is written as fact without source evidence.

Opportunity Engine

Canonical stages:

DISCOVERY -> QUALIFICATION -> PROPOSAL -> NEGOTIATION -> APPROVAL -> WON | LOST

Each opportunity supports owner, account, expected value, probability, expected close date, next action, blockers, competitors, risk score, evidence, activity/audit history and status.

Business-specific pipelines may extend the schema through governed adapters, but invalid arbitrary stage mutation is rejected by the reference implementation.

AI Sales Copilot boundary

The skill may recommend:

  • next best action;
  • qualification actions;
  • proposal follow-up;
  • stalled-deal review;
  • blocker review;
  • cross-sell/up-sell candidates when evidence exists.

The skill does not convert a recommendation into authority. External execution requires the appropriate connector, capability, consent policy and approval path.

Follow-up safety

The baseline follow-up engine returns recommendations only. It must respect OPTED_OUT, DENIED, UNSUBSCRIBED and equivalent states. It may create internal tasks/reminders, but must not:

  • spam;
  • bypass unsubscribe;
  • create fake engagement;
  • impersonate a human;
  • mass-message without policy authorization.

Guardian risk gate

The reference risk detector blocks or escalates high-risk CRM content including:

  • prompt-injection attempts;
  • seed/private-key/recovery-phrase requests;
  • credential/API-key requests;
  • payment or wallet destination substitution;
  • consent bypass;
  • impersonation;
  • script/HTML event-handler payloads;
  • suspicious executable attachment indicators;
  • urgent payment social-engineering patterns.

Any payment-destination modification is treated as CRITICAL and never executed by the baseline skill.

AI Passport and capability policy

Each runtime action requires:

  1. registered agent;
  2. exact AI Passport context match;
  3. explicit capability grant;
  4. Guardian risk gate;
  5. tier decision;
  6. action execution only if allowed;
  7. audit event with SHA-256 hash.

The fleet bootstrap currently uses AIP:<agent_id> as a registry-bound identifier, not proof of per-agent cryptographic attestation. Production cryptographic AI Passport verification is a separate security control and must not be overstated.

Multi-business support

The capability is domain-neutral and can be configured for:

  • real estate;
  • technology;
  • AI services;
  • fashion;
  • e-commerce;
  • professional services;
  • partnerships;
  • enterprise sales;
  • future IMPERIAL Core businesses.

Each federated business domain may define its own fields, scoring policy, stages, workflows and assigned NCA without changing the global CRM security boundary.

Connector architecture

Adapters are intentionally isolated from the core CRM authority model.

Planned adapter classes:

  • Gmail;
  • Google Calendar;
  • Slack;
  • Telegram;
  • website forms;
  • generic REST/webhook APIs;
  • databases;
  • spreadsheets;
  • external CRM systems.

A connector grant does not imply global CRM access. T2 communication remains fail-closed until the connector has authenticated identity, consent policy, allowlist, rate limits, audit and Approval Gateway behavior where applicable.

External CRM / best-of-breed review — 2026-09-03

The core runtime deliberately embeds no third-party CRM code. This minimizes supply-chain risk, runtime weight and copyleft/commercial-license coupling. External systems are adapter candidates, not silently installed dependencies.

Reviewed candidates:

  1. EspoCRM — strong open-source/self-hosted adapter candidate; REST backend, PostgreSQL support, AGPLv3. Decision: ADAPTER_CANDIDATE, not embedded.
  2. Frappe CRM — strong open-source workflow/CRM adapter candidate; Frappe CRM is AGPLv3 while Frappe Framework is MIT. Decision: ADAPTER_CANDIDATE, not embedded.
  3. SuiteCRM 8 — mature enterprise/open-source ecosystem and API-first modern stack; AGPLv3. Decision: ADAPTER_CANDIDATE, not embedded.
  4. Twenty — modern open-source CRM and self-hosting candidate, but licensing is mixed (mostly AGPLv3, some MIT and commercial files/features). Decision: REFERENCE/ADAPTER_CANDIDATE; commercial features are excluded by FREE_ONLY unless separately approved.

FREE_ONLY is fail-closed. No paid plan, card requirement, paid-only feature, automatic billing or silent paid fallback is admitted by this skill.

Jarfis / Morgan / ORION

MORGAN

CRM may surface evidence-backed opportunities and relationship context. It must not bypass MORGAN's existing Guardian / Approval / Audit pipeline for economic actions. No new wallet, signing, trading or spending authority is granted by CRM installation.

Jarfis

CRM may support business pipelines and relationship management only after Jarfis runtime identity and capabilities are verified. No unrestricted financial authority is implied.

ORION

ORION may consume safe aggregated CRM signals for advisory analysis, bottleneck detection, workload recommendations and opportunity discovery. ORION = ADVISORY_ONLY; it is not the CRM owner or global orchestrator.

CYBER HAK defensive validation

Security test organization maps to five groups:

  • A — Identity & Access;
  • B — API & Application Security;
  • C — Data & Privacy;
  • D — Agent Security;
  • E — Audit & Incident Response.

The supplied self-test contains 30 named defensive cases, six per group. A passing set demonstrates those 30 test cases against the reference runtime. It does not prove that 30 independent CYBER HAK agent processes executed them. Independent-agent participation requires separate runtime evidence.

Test standard

self_test.ts exercises functional, data, governance and security behavior using real project-scoped SQLite and runtime dispatch.

PASS requires zero failed checks in the executed run. A code file or registry record alone is not TESTED/LIVE evidence.

Fleet bootstrap

fleet_bootstrap.ts binds agents from an existing runtime agents table into crm_agents in one bulk operation, granting baseline T0/T1 CRM capabilities only. It does not promote agent execution status.

A source agent remains whatever its verified source state says: REGISTERED, RUNNING_BOUNDED, etc. CRM registration must never be used to relabel an inactive agent as working/autonomous.

Truth boundaries

  • REGISTERED != RUNNING != LIVE != AUTONOMOUS.
  • SKILL_INSTALLED != AGENT_EXECUTED_IT.
  • 30_SECURITY_TESTS_PASS != 30_INDEPENDENT_SECURITY_AGENTS_ACTIVE.
  • LOCAL_CRM_STORAGE != CANONICAL_SHARED_CRM_MEMORY.
  • AIP:<agent_id> REGISTRY BINDING != CRYPTOGRAPHIC AI PASSPORT ATTESTATION.
  • RECOMMENDATION != AUTHORITY.
  • CRM OPPORTUNITY VALUE != REALIZED REVENUE.

Files

  • core.ts — capability policy, normalization, deterministic scoring, risk detection, follow-up policy, hashing.
  • storage.ts — isolated CRM schema, owner-scoped CRUD, analytics, risk and audit.
  • runtime.ts — AI Passport/capability/risk/tier enforcement and operation dispatcher.
  • fleet_bootstrap.ts — bounded bulk fleet registration from a verified local agents registry.
  • self_test.ts — functional/data/governance test suite plus 30 defensive security cases.
  • canonical_sync.ts — authenticated adapter to the separate Supabase canonical CRM event chain and state projection.

Evidence policy

Permitted result labels: VERIFIED, TESTED, PARTIAL, BLOCKED, UNVERIFIED, NOT IMPLEMENTED, NOT TESTED.

Use TESTED only for an executed test run. Use VERIFIED only when independent read-back/evidence confirms the claimed state. Use LIVE only when the deployed runtime itself is exercised, not merely copied.