How do I troubleshoot an agent that sends bad data to the CRM?

Here’s a practical way to troubleshoot an agent sending bad data to a CRM.

1) Identify the exact failure

Start by answering:

• What field is wrong?
• Is the value malformed, missing, duplicated, or mapped to the wrong place?
• Does it happen for all records or only some?
• Did it start after a change?

Capture one or two concrete examples with:

• source payload
• expected value
• actual CRM value
• timestamp
• agent/version used

2) Trace the data path end to end

Follow the data through each step:

1. Source input
2. Agent extraction or generation
3. Transformation/mapping
4. Validation
5. CRM API call
6. CRM record storage

The goal is to find where the corruption occurs:

• bad data in the source
• bad parsing by the agent
• wrong mapping rules
• formatting issue before API submission
• CRM rejecting or coercing values

3) Check logs and payloads

Look at:

• raw input to the agent
• intermediate structured output
• final request body sent to CRM
• CRM response codes and error messages

Compare them side by side. Common issues:

• wrong field name
• type mismatch
• truncation
• encoding problems
• date/time zone conversion errors
• null handling
• duplicate insert vs update confusion

4) Verify mappings and schema

Make sure the agent is using the CRM’s expected schema:

• field names match exactly
• data types are correct
• required fields are populated
• picklist values are valid
• enums use CRM-approved values
• phone, email, and address formats are normalized

If there’s a mapping table or prompt/template, inspect it for:

• outdated field definitions
• ambiguous instructions
• fallback logic that guesses incorrectly

5) Test with controlled examples

Create a few known-good test cases:

• simple normal record
• record with missing optional fields
• record with edge cases like special characters, long text, international phone numbers, non-UTC dates

Send them through the agent and compare the output at each stage. This helps isolate whether the issue is in:

• input interpretation
• transformation logic
• CRM write step

6) Check for recent changes

Look for:

• agent prompt changes
• model/version changes
• CRM schema changes
• integration code changes
• new validation rules
• updated business logic

Bad data often starts right after:

• a prompt edit
• a CRM field rename
• a new required field
• a change in timezone or locale handling

7) Validate before writing to CRM

Add guardrails:

• schema validation
• type checks
• required-field checks
• value normalization
• allowlists for enum values
• length limits
• date format checks

If validation fails, log the record and stop it from reaching CRM.

8) Add observability

Useful monitoring includes:

• count of failed writes
• count of field-level validation errors
• samples of rejected payloads
• diff between source and CRM values
• alerts for sudden spikes in malformed records

9) Reproduce outside the agent

If possible, send the same payload directly to the CRM API or a sandbox environment:

• If direct submission works, the problem is likely in the agent or transformation layer.
• If it fails there too, the issue is probably schema, formatting, or CRM-side behavior.

10) Apply fixes and prevent recurrence

Typical fixes:

• correct the mapping
• tighten the prompt/instructions
• add schema validation
• normalize values before write
• handle timezone/locale explicitly
• use retries only for transient API errors, not bad data
• create regression tests for known failure cases

If you want, I can give you:

• a troubleshooting checklist,
• a sample debugging log template,
• or a flowchart for isolating whether the agent, mapping, or CRM is at fault.