Cross-Application Tools

Char’s defining capability is cross-application tool access. An agent in your CRM can invoke a tool from your ERP—without either application knowing about the other. This page explains why this is valuable, why it’s hard, and how Char makes it possible.

​

Why Cross-App Matters

Consider a typical enterprise workflow: “Check if Acme Corp’s invoice is paid, update their CRM record, and notify their account manager.” This touches three systems: ERP, CRM, and email. In a traditional setup, you’d need to:

1. Build an integration between ERP and CRM
2. Build an integration between CRM and email
3. Write orchestration logic to coordinate the workflow
4. Handle errors, retries, and edge cases

For one workflow, this might be acceptable. For dozens of workflows, it becomes unsustainable. And for workflows you haven’t thought of yet, you’d need to build new integrations before you could even try. AI agents change the equation. Instead of building integrations, you give the agent access to each system and describe what you want. The agent figures out the coordination. But for this to work, the agent needs access to all the systems simultaneously—not just the one you’re currently looking at.

​

The Technical Challenge

Making tools from different applications available to a single agent is harder than it sounds. Authentication fragmentation. Each application has its own authentication. Your CRM session is different from your ERP session. An agent that wants to call both needs credentials for both. Context boundaries. Traditional web security isolates applications from each other. JavaScript in your CRM can’t call APIs in your ERP—same-origin policy prevents it. This isolation is intentional and important for security. Discovery. The agent needs to know what tools exist across all applications. If tools are defined per-application, there’s no unified view. Most solutions to these problems involve building a server-side proxy. The proxy has service accounts for each application, routes requests between them, and provides a unified tool surface. This works but introduces:

• Credential management. Service account tokens need to be stored, refreshed, and rotated.
• Over-privileged access. Service accounts typically have broader permissions than individual users.
• Complex deployment. The proxy becomes critical infrastructure requiring high availability.
• Audit challenges. Actions appear to come from the service account, not the user who initiated them.

Char takes a different approach.

​

Why Browser-Based Execution

When you’re logged into an application in your browser, you already have an authenticated session. That session represents your identity, your permissions, your access. The session exists—no additional credentials needed. Char’s insight is that the browser can be the execution environment. Instead of a proxy with service accounts, tools execute directly in your browser tabs using your existing sessions. When the agent calls erp.lookupInvoice, the request routes through the Tool Hub to your ERP tab, which executes it using your ERP session. The API call happens in the browser, uses your cookies, respects your permissions. This means: No credential storage. Char doesn’t have your ERP password or API token. The browser has your session; that’s enough. Permission parity. The agent can only do what you can do. If you can’t delete invoices, neither can the agent. Proper attribution. Your application’s audit logs show your user ID, not a service account. Instant revocation. When you log out or your session expires, the agent loses access. No tokens to revoke separately.

​

The Execution Flow

When an agent invokes a cross-app tool, the request traverses several boundaries: Key points:

1. The Hub routes, doesn’t execute. The Hub never sees the actual API request or response body. It only knows “tool X was called” and passes opaque messages.
2. postMessage bridges contexts. The Char agent runs in an iframe with its own origin. Communication with the host page uses postMessage, the standard cross-origin messaging API.
3. fetch() uses the session. When the host page calls the application’s API, the browser automatically attaches session cookies. No code needed to “pass” credentials.
4. Same-origin policy applies normally. The host page can only call APIs it could normally reach. Cross-origin requests require CORS headers just like any other JavaScript.

​

Tool Namespacing

When multiple applications register tools, name collisions are inevitable. Your CRM might have a search tool. Your ERP might also have a search tool. These do different things. The Hub automatically namespaces tools by their source domain: The agent sees distinct tools and can choose which to invoke. When you ask “search for Acme in the CRM,” the agent knows to call crm.search, not erp.search.

​

Identity Continuity

Cross-app tools work because all your applications recognize the same user. Your CRM knows you’re Alice. Your ERP knows you’re Alice. Char knows you’re Alice. This consistent identity is what makes per-user tool aggregation meaningful. This is why Char uses federated authentication. Your identity provider is already the source of truth for who you are across enterprise applications. Char validates tokens from the same IDP, ensuring identity continuity. If your applications use different identity systems—separate user databases with no federation—cross-app tools won’t work naturally. The Hub is scoped by user ID, but “user 42 in CRM” and “user 42 in ERP” might be different people.

​

Tradeoffs of Browser Execution

Browser-based execution has genuine limitations: Tab dependency. If you close your ERP tab, ERP tools become unavailable. The Hub reflects reality—you can only invoke tools from applications that are actually open. Latency. The message path (agent → Hub → iframe → page → API → page → iframe → Hub → agent) adds round-trips. For interactive use, this is acceptable. For high-frequency automation, it might not be. Not background-capable by default. You can’t schedule a workflow to run at 3am using your local browser because it isn’t open at 3am. For unattended automation, enterprise deployments can use remote browsers with delegated credentials—headless execution that maintains the session inheritance model without requiring user presence. User presence required. Someone needs to have the applications open. This aligns with Char’s user-centric model—the agent acts on your behalf while you’re present—but doesn’t fit all use cases.

​

Compared to Alternatives

Server-side proxies (like traditional integration platforms) trade browser dependency for credential management. They can run background workflows but require storing secrets, managing tokens, and often grant broader access than any individual user has. Browser automation (like Playwright-based agents) can control any application without predefined tools but can also read arbitrary page content—creating the prompt injection risks Char’s tool model avoids. API aggregators (like unified APIs) provide a clean interface but require the aggregator to support each application. Adding a new application means waiting for vendor support. Char occupies a middle ground: tool-based access (more secure than automation), browser-based execution (simpler than proxies), but limited to interactive scenarios (unlike background automation). For services that have well-designed APIs—internal microservices, data platforms, custom tooling—remote MCP provides an alternative that doesn’t require browser tabs. The Tool Hub aggregates both browser-based and remote tools under the same identity scope. See Why Char Exists for how these approaches complement each other.

​

Further Reading