Every AI workforce capability described in Blitzify's product literature depends on one foundational truth: the agents need to see the actual data in your business systems to do their work.

SAL cannot maintain an informed sales pipeline without reading from the CRM. BEN cannot monitor financial variances without reading from the accounting system. JOY cannot manage client relationships without reading from the communication history. ZED cannot coordinate intelligently across agents without access to the operational context that lives in these systems.

IAN, the Integration Network Agent, is the specialist responsible for establishing and maintaining these connections. This article explains how that integration layer works, what it means for deployment, and how operators interact with it.

The Integration Architecture

IAN operates as the data access layer for the entire Blitzify workforce. Rather than each agent having its own independent connection to each business system, all data access routes through IAN. This has specific architectural implications.

Centralized permission management. Permissions for each business system are granted once, to IAN, and then allocated by IAN to the agents that need them. SAL does not need independent CRM credentials, it requests CRM data through IAN, which has the permissions to provide it. This means permission management for the entire workforce happens in one place, not separately for each agent.

Read-first by default. Most agent operations are read operations: researching accounts, monitoring financial data, reviewing communication history. IAN's default permission posture is read access. Write operations, creating CRM records, sending communications, updating calendar entries, require explicit permission grants that are configured per agent per system during deployment setup.

System of record preservation. IAN does not replicate data into a parallel store. It accesses data where it lives. The CRM remains the CRM. The accounting system remains the accounting system. When BEN surfaces a financial insight, it is drawing on live data from the connected accounting system, not from a copy. This means the accounting system's data quality directly determines BEN's intelligence quality.

Bidirectional where configured. For systems where agent output should be recorded back to the system (SAL's outreach logged in the CRM, BEN's alerts logged for the accountant), IAN supports bidirectional sync with the appropriate write permissions.

What IAN Connects

The core integrations available through IAN at GA cover the most common small and mid-size business technology stack.

CRM. HubSpot and Salesforce at launch, with additional CRM support in development. SAL's pipeline management, contact research, and outreach logging all route through the CRM integration. JOY's account health monitoring draws on contact and deal data from the CRM.

Accounting. QuickBooks Online and Xero at launch. BEN's financial monitoring and reporting routes through the accounting integration. Read access to chart of accounts, transactions, invoices, and AR aging. Write access (for logging BEN's report outputs) is optional.

Email. Google Workspace and Microsoft 365. SAL's outreach execution, JOY's client communications, and MAX's email newsletter distribution all route through the email integration. Importantly, the email integration does not give agents access to all email, it gives access to specific outbound functions defined by the operating brief. Inbound monitoring is configured separately.

Calendar. Google Calendar and Outlook Calendar. ZED uses calendar integration for meeting awareness, briefing timing, and operator availability context. JOY uses calendar integration for client check-in scheduling.

E-commerce. Shopify integration for operators with DTC or wholesale channels. BEN uses Shopify data for revenue monitoring and margin analysis. KAI uses Shopify operational data for fulfillment monitoring.

Project management. Linear and Asana integrations for operators using project management tools for operational workflows. KAI uses project management integrations for task and workflow monitoring.

The Deployment Configuration Process

IAN configuration is the first technical step in every new deployment. It happens during the onboarding session and typically takes two to four hours depending on the number of systems being integrated and the complexity of the permission structure.

The configuration process follows a specific sequence.

System identification. What tools does the business use for each relevant function? This maps the existing technology stack to the integration layer.

Permission scoping. For each system, what does each agent need to read, and what does each agent need to write? Permission grants are scoped to the minimum required for each agent to perform its function. An agent that only needs to read pipeline data does not receive write access to the CRM.

Data mapping. For systems with configurable data structures (custom CRM fields, non-standard accounting categories), IAN's data mapping needs to be configured to correctly interpret the business's specific schema. This is particularly important for BEN's financial monitoring, where incorrect account mapping produces incorrect variance detection.

Testing and validation. Each integration is tested before the workforce begins operating. SAL's account research is tested against a small set of known accounts. BEN's financial monitoring is tested against a recent period of known financial data. Validation confirms that the integration is reading the correct data in the correct format.

How Operators Interact With IAN

Most operators interact with IAN primarily at two points: initial configuration and troubleshooting.

Initial configuration. The deployment session walks through IAN configuration systematically. For most operators, this is the most technical part of the deployment process. The configuration interface is designed for business operators, not engineers, most systems connect through OAuth authorization flows rather than API key configuration.

Adding integrations. When new tools are added to the business's technology stack, IAN configuration is updated to include them. An operator who adds a new project management tool can configure KAI's access to it through IAN's integration settings.

Troubleshooting. When an agent is not performing as expected on a function that relies on external data, the first diagnostic step is IAN. Is the integration connected? Are the permissions correct? Is the data mapping accurate? ZED's diagnostic layer surfaces IAN connectivity issues in the morning briefing when an integration is producing errors.

Revoking access. When an operator wants to remove a system from the workforce's access (a tool being replaced, a function being paused), access is revoked through IAN's permission management. The agent immediately loses access to the relevant data without requiring changes to the agent's operating brief.

Security and Data Handling

A reasonable question for any operator evaluating Blitzify is: what data does IAN actually access, and how is it handled?

Access is scoped, not comprehensive. IAN does not request broad admin access to connected systems. Each integration request is scoped to the specific data the configured agents need. A CRM integration for SAL requests access to contact, company, and deal data, not to billing records, admin settings, or unrelated data objects.

Data is accessed for agent operations, not stored independently. IAN does not build a parallel data store. Data accessed from integrated systems is used for agent operations in the session and not retained in a separate repository outside the business's own systems.

Credentials are handled through OAuth where available. For systems that support OAuth (HubSpot, Google Workspace, Shopify, QuickBooks Online), IAN uses OAuth authorization flows that do not require the operator to share passwords or API keys. For systems that require API key configuration, keys are stored encrypted and are not exposed in the operator interface.

Revocation is immediate. If an operator revokes an integration, access is immediately suspended. No data cached from the integrated system persists for agent use after revocation.

A Technical Note on Agent Data Access Patterns

For operators with technical backgrounds, a brief note on how agents access data through IAN.

Agents do not maintain persistent connections to integrated systems. When an agent needs data to complete a task, SAL researching a prospect, BEN compiling a weekly report, it makes a request through IAN for the relevant data. IAN authenticates against the connected system, retrieves the requested data, and returns it to the requesting agent.

This request-based pattern means that agent operations reflect the current state of the connected systems at the time of the request. BEN's financial reports reflect the accounting system data as it exists when BEN queries it, not data cached at a previous time. This is the mechanism behind the "continuous monitoring" capability: agents query at regular intervals rather than relying on stale cache.

FAQ

What happens if a connected system is unavailable? If IAN cannot reach a connected system, the agents that depend on that system's data gracefully degrade, they flag the connectivity issue in the ZED briefing rather than operating on stale data. ZED's briefing will include an integration health indicator showing any systems with connectivity issues.

Can I connect a custom or proprietary internal tool? Custom integrations are available through IAN's API integration layer. This requires the custom tool to have an accessible API. The configuration process for custom integrations is more involved than for standard integrations and is currently available on request.

Does IAN require any software to be installed on our systems? No on-premise installation is required. All integrations operate through API connections and OAuth authorization flows. Connecting a system requires only that the operator authorize IAN's access through the connected system's standard authorization interface.

Key Takeaways

  • IAN is the centralized integration layer that gives every agent access to business system data through scoped, controlled permissions.
  • System of record preservation: IAN reads from existing tools, it does not replace them. Data quality in the connected systems directly determines agent intelligence quality.
  • Permissions are scoped to the minimum required for each agent's function. Broad admin access is not requested or required.
  • The configuration process during deployment is the most technical step in onboarding, it typically takes two to four hours and is designed for business operators rather than engineers.
  • Integration health is surfaced in ZED's daily briefing. Connectivity issues are flagged for operator attention before they affect agent performance.

[Meet IAN →](/agents/ian) | [See how the workforce connects to your systems →](/how-it-works/workforce) | [Request access →](/request-demo)