AI Agents • iPaaS • Knowledge Graphs
Agent Tools, iPaaS Adapters, and Knowledge Graphs
The fastest way to make agents dangerous is to give the model raw product APIs. The fastest way to make them useful is to wrap those APIs as governed iPaaS tools and ground every call in a knowledge graph of entities and policies.
Why tools should be iPaaS adapters
Freshworks already has messaging, CRM, and orchestration adapters. Agents should not grow a second integration estate. Each tool is a versioned adapter: auth, retries, schemas, and SLOs already exist.
- One IAM story for humans, automations, and agents.
- One CDC trail when an agent mutates a ticket or account.
- One place to turn a tool off without redeploying prompts.
Retrieve → decide → act → write-back
Tool catalog and risk classes
Every adapter is registered with a risk class that drives approval, rate limits, and whether a human must confirm before execution.
What the knowledge graph actually stores
Knowledge graph work on the platform team is about modeling relationships between entities and business concepts so agents (and humans) get contextual discovery across products.
| Node / edge | Example | Agent use |
|---|---|---|
| Account —owns→ Ticket | Acme → INC-4421 | Scope retrieval |
| Ticket —mentioned_in→ Thread | WhatsApp lane | Channel-aware replies |
| AgentRun —used_tool→ Adapter | create_ticket | Evals / replay |
| Policy —constrains→ Tool | EU residency | Block illegal calls |
| Entity —similar_to→ Entity | duplicate contacts | Dedupe before write |
Tool schema, not free-form JSON
Publish a strict JSON schema per tool. The planner may only emit that shape. Workers validate before hitting the product API. Version adapters independently of prompt packs so a Teams bot change does not require a model redeploy.
Tool name, domain, risk class, schema.
IAM role + tenant + residency.
Conductor task, idempotency key.
CDC upserts graph edges.