A Practical Data Contract for AI Agents Across CRM, ERP, and Billing

Why “customer intent” breaks when agents can read and write everywhere

Most teams can classify “customer intent” (refund, invoice copy, cancel subscription, change shipping address). The harder part is turning that intent into an actionable case that an AI agent can safely execute across systems like CRM, ERP, and billing—without creating duplicate tickets, corrupting data, or making the customer repeat themselves.

The moment an AI agent can write into production systems, a simple “intent” label is no longer enough. You need a practical data contract: a shared, enforceable shape for cases, permissions, validations, and side effects. Done well, it becomes the thin layer that keeps customer experience stable while you automate more workflows.

The actionable case model: one object that survives every handoff

An actionable case is the unit of work that can move between AI agents, humans, and systems without losing context. It’s not a chat transcript. It’s not a CRM ticket. It’s a canonical object that can be projected into those systems.

A pragmatic case schema typically includes:

• Case identity: a stable case_id, external IDs (ticket_id, order_id, invoice_id), and a dedupe key.
• Customer identity graph: customer_id plus the linking evidence used (email, phone, account number), with confidence and auditability.
• Intent + outcome: the customer’s requested outcome expressed as a target state (e.g., “invoice status = paid”, “subscription = canceled at period end”).
• Eligibility snapshot: the facts used to decide (plan, SLA tier, policy version, refund window, payment status).
• Actions plan: proposed operations with required approvals, dependencies, and rollback guidance.
• Side effects: messages to send, notes to log, entitlements to update, and analytics events to emit.
• Proof and trace: what the agent observed, which tools it called, and the reasoning artifacts you want to retain.

This turns “refund intent” into “refund case” with a concrete, verifiable end state and an action plan that a system can accept or reject.

A minimal data contract that prevents CX breakage

To be practical, the contract should be small enough to adopt quickly, but strict enough to stop the most common failure modes (wrong customer, wrong invoice, double credit, policy drift).

1) Canonical entities and IDs

Pick canonical IDs and require them at the boundary. For example:

• Customer: customer_id (canonical), plus crm_contact_id, erp_customer_id, billing_account_id as mapped references.
• Financial objects: invoice_id, payment_id, credit_memo_id.
• Commerce objects: order_id, return_id, shipment_id.

Rule of thumb: an AI agent can propose mappings, but it shouldn’t be allowed to write money-impacting changes unless it has the canonical ID and an evidence trail for how it matched.

2) Explicit read/write scopes per action

When agents operate across CRM, ERP, and billing, permissioning has to be action-specific, not “agent-level.” Put scopes in the contract itself:

• Read scopes: what fields can be retrieved (e.g., subscription status, invoice balance).
• Write scopes: what fields can be mutated (e.g., create credit memo, update address).
• Approval requirement: none, human approval, or “four-eyes” for sensitive actions.

This is where platforms like typewise.app fit naturally: they sit above existing systems and orchestrate tool calls with guardrails, making “allowed actions” a first-class concept instead of scattered logic in prompts and scripts.

3) Preconditions and invariants (policy as data)

Actions need preconditions that the agent must prove before execution. Examples:

• Refund requires: invoice.status = paid, within refund window, no prior refund for same line item.
• Cancel renewal requires: account owner verified, contract end date known, notice period satisfied.
• Address change requires: no shipment already handed to carrier (or triggers intercept workflow).

Store the policy version and the inputs used in the eligibility snapshot so you can audit decisions and reproduce outcomes later.

4) Idempotency and concurrency controls

CX breaks fast when two agents (or an agent and a human) perform the same action twice. The contract should support:

• Idempotency keys for every write (e.g., refund:invoice_id:line_item_id).
• Optimistic locking (version fields) or “refresh before commit” rules.
• Conflict states that force a handoff (e.g., “invoice changed since review”).

In practice, this is less about perfect distributed locking and more about making double-writes difficult and detectable.

Turning intent into actions: an execution pattern that scales

A useful operational pattern is: plan → validate → execute → reconcile.

Plan: propose an action graph

The agent converts the customer request into a sequence of operations (tool calls) with dependencies. For example, “send invoice copy” might be:

• Find canonical customer
• Locate invoice by date/amount
• Generate PDF link (billing)
• Send via channel + log note (CRM)

Validate: run checks before any write

Validation is where the data contract pays for itself. If any required precondition is missing, the case becomes “needs input” or “needs approval,” rather than the agent guessing.

Execute: apply writes with audit trails

Every write should produce a durable record in the case: what changed, which system, which ID was created, and what message was sent to the customer.

Reconcile: confirm the world matches the promised outcome

After execution, read back key fields (invoice balance, subscription status, shipping status) and attach them to the case so you can confidently close it—or automatically reopen if reality diverged.

Where teams get stuck and how to avoid it

Misaligned timestamps and “truth” fields

CRM and billing often disagree on dates (created vs posted vs paid vs effective). If you report outcomes or drive automations off the wrong timestamp, you’ll see phantom churn, incorrect SLA breaches, or broken revenue attribution. The fix is to define canonical time fields in the contract and map every system’s fields to them. If you’ve dealt with analytics drift before, the same discipline applies as in fixing the spend vs conversion date mismatch.

Human handoffs that lose context

When an agent can’t proceed, the case should carry a compact “handoff packet”: what the customer asked for, what the agent already verified, what’s blocked, and what approval is needed. That prevents re-triage and reduces the “please repeat your issue” loop.

Security and over-broad tool access

Most incidents come from giving a tool too much authority. Keep the contract’s scopes narrow and consider session auditing for sensitive operations—similar in spirit to a remote pair programming security playbook, but applied to AI-initiated tool calls.

What “good” looks like in production

A strong implementation usually shows these behaviors:

• Cases are portable: they can be opened in CRM, billing, or an internal console without translation errors.
• Writes are predictable: every action has preconditions, idempotency, and a reconciliation step.
• Policy changes are safe: you can update instructions or rules without silently changing outcomes, because versioning and validations catch drift.
• Customer experience is stable: fewer duplicate credits, fewer contradictory emails, faster resolutions, and cleaner handoffs.

The practical goal isn’t to build the perfect ontology. It’s to ship a contract that makes AI agents reliable operators across CRM, ERP, and billing—so “intent” consistently becomes a completed, auditable outcome.