How IAN Connects the Workforce to Your Business Data

An AI workforce operating without access to real business data can only produce generic output. IAN, the Integration and Analytics Network, is the layer that connects every agent to the operator's actual systems: CRM, accounting software, email, calendar, e-commerce, and project management.

Why Integration Quality Is Intelligence Quality

An AI agent that cannot see your actual business data produces generic output. SAL researching prospects without access to your CRM produces duplicates and misses accounts already in your pipeline. BEN monitoring your financial position without access to your actual accounts produces estimates rather than actuals. KAI watching operational workflows without access to your order management system cannot detect the signals that matter.

The quality of the workforce's intelligence is a direct function of the quality of the data the workforce can access. This is what IAN is designed to solve.

IAN, the Integration and Analytics Network, is the data integration layer of the Blitzify workforce. It is not an agent in the same sense as SAL, MAX, or BEN, it does not execute a business function. It is the infrastructure that makes the other agents' outputs accurate, relevant, and grounded in the operator's actual business reality.

What IAN Connects

At the current release, IAN supports connections across five integration categories:

CRM and sales data. Salesforce, HubSpot, Pipedrive, and others via API. SAL reads CRM data to avoid duplicate prospecting, understand the current pipeline, identify accounts already in relationship with the business, and surface pipeline health signals. Without CRM integration, SAL is researching in isolation from the existing sales context.

Accounting and financial data. QuickBooks, Xero, and others via API. BEN reads accounting data to monitor revenue, expenses, and cash position against actuals rather than estimates. Without accounting integration, BEN's financial monitoring is approximate. With it, BEN works from the same numbers the business operates on.

Email. Gmail, Outlook/365. Multiple agents access email context: SAL uses it to understand the state of existing outreach relationships; JOY uses it to monitor client communication patterns; VAL uses it for executive communication context. Email access is read-only for context, no agent sends email without operator-approved content.

Calendar. Google Calendar, Outlook Calendar. Used primarily by VAL for meeting context and preparation, and by ZED for understanding the operator's schedule when assembling the morning briefing priority queue.

E-commerce. Shopify, WooCommerce. KAI reads order data to monitor fulfillment performance; BEN reads revenue and transaction data for financial monitoring. For operators with e-commerce businesses, these integrations significantly expand operational and financial intelligence quality.

Project management. Asana, Monday, ClickUp, Notion. KAI reads project management data to monitor delivery stage progress, identify stalls, and track resource allocation. VAL reads it for executive context on active projects and deliverable status.

Communication. Slack (read access for context). IAN can read relevant Slack channels for operational context, project channels where delivery discussions happen, client channels where relationship signals surface. Blitzify does not post to Slack channels without explicit configuration.

How IAN Maintains Data Security

Data access through IAN follows a principle of minimum necessary access: each agent accesses only the data required for its function.

SAL accesses CRM contact and pipeline data and outbound email sending (through configured sending accounts). It does not have access to financial data, project management details, or non-sales email threads.

BEN accesses accounting and financial data. It does not have access to CRM contact details, email content, or project management data.

KAI accesses order management, project management, and supplier communication data relevant to operational monitoring. It does not have access to financial account details or non-operational email.

This scope-scoped access model means a security issue affecting one agent's integration scope cannot expose the full business data landscape.

All connections are established through standard OAuth flows with the connected systems' native security models. No business data is stored persistently in Blitzify's systems beyond what is required for the immediate briefing and analysis cycle.

The IAN Configuration Process

IAN configuration is the most time-intensive part of onboarding, and the most important. The configuration process:

Step 1. Data source inventory. The operator lists the key business systems: which CRM, which accounting software, what e-commerce platform, etc. This inventory determines the integration scope.

Step 2. Connection setup. IAN establishes OAuth connections to each system through the integration settings panel. Most connections complete in three to five minutes. Some systems (particularly older accounting software) require API key setup rather than OAuth.

Step 3. Access scope configuration. For each integration, the operator configures which data objects IAN can access and which agents have access to each integration. The defaults represent the minimum access required for each agent's function.

Step 4. Data quality review. After initial connection, IAN surfaces a data quality summary: what it can see, what appears incomplete or inconsistent, and what gaps in the data may affect agent output quality. Operators can review and address data quality issues before agents begin operating.

When Integration Is Not Available

Not every business system has a ready API connection in IAN's current integration library. For systems outside the current library:

Custom integration pathway. IAN supports a custom integration pathway for systems with documented APIs. This requires technical configuration and is typically handled during an extended onboarding session.

Partial integration. For systems where full integration is not feasible, IAN can often connect to a subset of the system's data, for example, connecting to exported financial reports from a legacy accounting system rather than a live API connection.

Operating without integration. Agents operate with the data they have access to. An agent with limited integration operates on reduced information and produces correspondingly less specific output. The tradeoff is transparent in each agent's output quality indicators.

Integration as an Ongoing Investment

The initial IAN configuration covers the most critical data sources. Integration breadth grows over time as operators identify additional data sources that would improve workforce intelligence quality.

A common pattern: operators begin with accounting + CRM, see the improvement in BEN and SAL output quality, and then add e-commerce + project management to improve KAI's operational intelligence. Each addition improves the specific agents that depend on that data.

IAN configuration is not one-time, it is an ongoing aspect of maintaining and improving the workforce's operational quality.

Troubleshooting Integration Issues

Integrations occasionally encounter connection issues, permission changes, or API changes from the connected system. IAN surfaces these as integration health alerts in ZED's briefing rather than silently degrading agent output quality.

A common pattern: an accounting software connection loses its OAuth token after a password change on the connected account. Without IAN's health monitoring, BEN's financial reports simply become less current without a clear explanation. With IAN's health monitoring, ZED surfaces the connection issue and the operator can re-authorize the connection before it meaningfully affects BEN's output.

Integration health alerts follow the same three-tier model as operational alerts:

Monitor: The integration is functioning but showing signs of potential degradation (slower response times, occasional query failures that resolve automatically).

Alert: The integration has had a significant number of failures in the last twenty-four hours and may not be reliably providing data.

Escalation: The integration is offline and the connected agent is operating without data from this source. Operator intervention required to restore the connection.

The Data Access Architecture

Understanding how IAN actually accesses data helps operators configure it correctly and understand its limitations.

IAN uses OAuth 2.0 flows for systems that support it, the industry standard for delegated access that does not require sharing credentials. The operator authorizes IAN to read specific data from the connected system on the business's behalf. This authorization can be revoked at any time through the integration settings panel.

For systems that do not support OAuth, IAN uses API key authentication where the system provides one, or file-based import for systems with no API (older accounting software, legacy ERP systems). File-based imports are less real-time, they are updated when the operator exports and uploads the latest data, but they ensure the agent has access to the data even when live API access is not available.

Read vs. Write access: Most of IAN's integrations are read-only. IAN reads data from connected systems to provide agents with context; agents produce outputs (communications, reports, alerts) that the operator can act on. The exception is IAN's email integration, which provides SAL with the ability to send outbound emails from the operator's configured sending account, but only for messages the operator has approved.

Privacy and Data Handling

IAN is designed around data minimization: each agent accesses only the data required for its function, and data is not stored in Blitzify's systems beyond the immediate processing cycle.

What this means in practice:

BEN reads transaction data from the accounting system for its current monitoring cycle. It does not maintain a copy of the accounting system's full dataset.
SAL reads contact and opportunity data from the CRM to inform its outreach. It does not export or replicate the CRM database.
JOY reads communication history from email to understand client relationship context. It does not archive emails in Blitzify's systems.

The connected systems remain the systems of record. IAN enables agents to read from them in real time. The data stays in the connected systems; the intelligence is in the agents.

Common Integration Mistakes

Connecting too broadly in the initial setup. A common early deployment mistake is connecting every available integration before understanding which agents need what data. This creates noise in the integration health monitoring and makes troubleshooting harder. Recommended approach: connect only the integrations required for the agents you are deploying in the first ninety days. Add additional integrations as those deployments stabilize.

Not reviewing data quality before activating agents. IAN surfaces a data quality report after initial connection. It is worth reviewing this report before activating the dependent agents. Common data quality issues: CRM contacts with no email addresses, expense categories that have been applied inconsistently, project management tasks with no due dates. These issues do not break the agents, but they do degrade output quality in predictable ways.

Not re-authorizing after system password changes. When a connected system's credentials change, a new team member takes over an account, a password is rotated for security reasons, IAN's OAuth token is invalidated. Reconnecting takes under five minutes, but only if the integration health alert is noticed and acted on promptly.

[Meet IAN →](/agents/ian) | [Read the v1.1 GA Release Notes →](/intelligence/platform-update-v1-1) | [Read: What Business Owners Should Expect from Autonomous Agents →](/intelligence/what-business-owners-should-expect-from-autonomous-agents)