Module 6.2 · Topic 3

Tools and Data Connections

Bottom Line Up Front: Integrations connect your AI tools to external systems (CRMs, databases, practice management platforms) so agents can access data, update records, and trigger actions. Well-designed integrations…

3.1 Setting Up Integrations and Connectors

An integration connects an AI tool to an external system (your CRM, email, document storage, database). A connector is the specific interface that manages the integration—it translates requests from the AI tool into actions in the external system and returns results back to the agent.

Identify the target system: What external system does your agent need to access? (Salesforce, Google Drive, Slack, Stripe, your internal database.) Confirm the system has an API or connector available, not all systems expose integrations equally well.
Authenticate and authorize: Set up credentials (API keys, OAuth tokens, username/password) so the connector can access the external system on your behalf. Store credentials securely (never hardcode them in your workflow). Configure what data the connector is allowed to read and write.
Test the connector: Before putting the integration in production, test it manually. Can the connector read data from the external system? Can it write? Are there permission errors? Test with realistic sample data, not minimal test data.
Map agent inputs to connector calls: Define how the agent's request translates into a connector call. If the agent says "retrieve customer history for email jane@company.com," the connector knows to query the CRM's customer table by email and return all records. Document these mappings.
Handle responses and errors: Not every connector call succeeds. The external system might be temporarily down, permissions might be insufficient, or data might be malformed. Design the agent to handle these gracefully: retry with backoff, log the error, notify a human, or provide a fallback.
Monitor and maintain: As the external system updates or API contracts change, the connector may break. Set up monitoring to detect connector failures early. Keep documentation updated as the external system evolves.

3.2 Designing Data Flows Between Systems

Data flow design maps how information moves through your AI infrastructure: where it originates, how it transforms, where it's stored, and where it's consumed. Good data flow design ensures data reaches the agents that need it and only reaches agents that should have it.

Identify data sources (emails, databases, forms, APIs). Map transformations and destinations. Document constraints: confidentiality, encryption, retention.

A strong data flow design reduces operational risk. If you know exactly how customer email addresses flow from Outlook into your CRM via an agent, you can ensure encryption, audit access, and quickly trace any issues. Weak data flow design creates data governance nightmares: you don't know where data came from, who accessed it, or where it was stored. This is especially critical if you handle sensitive client information.

3.3 Authentication, Permissions, and Access Control

Authentication confirms that an agent is who it claims to be (usually by checking credentials). Permissions control what that agent is allowed to do. This is a critical skill to master because misconfigured access creates security and compliance risks.

Logic behind this approach:

Agents should operate under the principle of least privilege: each agent has access to exactly the data and actions it needs to do its job, no more. A research agent should read contracts but not modify them. A billing agent should update invoice status but not access confidential case files. Proper access control prevents mistakes and limits damage if an agent is compromised.

Sample prompt:

You are configuring access controls for an AI system that processes customer support tickets. Create an authorization specification for three agents: - Support Analyst Agent: Can read ticket text, customer contact info, previous interactions. Cannot see billing or confidential case strategy. - Billing Agent: Can read billing history and update payment status. Cannot see ticket content or customer contact info. - Manager Agent: Can read all agent activity and audit logs. Cannot modify any customer data directly. For each agent, specify: 1. Data sources it can access (with read/write permissions) 2. Actions it can perform 3. Data it is explicitly forbidden to access 4. Authentication method (API key, OAuth, service account) 5. Any rate limits or time-based restrictions Ensure least privilege: no agent has access beyond what it needs.

What to expect in reply:

A well-specified authorization framework mapping each agent to its data access and action boundaries. The response should clarify which authentication methods are appropriate (OAuth for user-delegated access, API keys for service-to-service access, service accounts for automated workflows). Look for explicit mention of data it forbids access to—this shows the responder understands the principle of least privilege.

3.4 Troubleshooting Integration Issues

Integrations fail for predictable reasons. Knowing how to diagnose and fix common issues keeps your workflows running.

Authentication Failures: The connector can't authenticate to the external system. The API key is expired, revoked, or incorrect; the OAuth token was never granted or has expired. Solution: verify credentials are current and have not been rotated by the external system. Check that the service account or user still exists in the external system.
Permission Errors: Authentication succeeds, but the connector lacks permission to access the requested data or perform the requested action. The API key belongs to a user who doesn't have access to that CRM field; the service account wasn't granted permission to write to that database table. Solution: audit the account's permissions in the external system. Expand permissions if needed, following least-privilege principles.
Data Format Mismatches: The connector sends data to the external system, but the system rejects it because the format doesn't match the API specification. You're sending a date as "2026-03-03" but the API expects "03/03/2026"; you're sending a text field that exceeds the database column's character limit. Solution: review the external API documentation and transform your data to match the API's exact specification.
Rate Limiting: Implement exponential backoff. Batch requests when possible. Contact the external system's support to negotiate higher rate limits if your use case justifies it.
Network and Availability Issues: The external system is temporarily down or unreachable. Solution: implement retries with exponential backoff. Log the failure so humans know integration is broken. Switch to a fallback if one exists (cached data, alternate API, manual process). Investigate whether your network egress is configured correctly for the external system's IP addresses.
Schema Changes in the External System: The external system updated its API or database schema. Fields you expected are missing; data types changed. Solution: this is why integration monitoring is critical. As soon as the external system changes, test your connector. Update your integration code or mapping logic to match the new schema.