Karan Vaidya is a co-founder of Composio, where his work focuses on the infrastructure AI agents need to act across workplace applications. His defining concern is what makes that action dependable: access to organizational context, a record of earlier work, meaningful verification, and controls over consequential decisions.
From coding agents to integration infrastructure
Vaidya studied at IIT Bombay from 2013 to 2017, with undergraduate work on database query optimization and a speech-analysis project exploring accent prediction from audio features. He worked at Google and Rubrik before co-founding Composio with Soham Ganatra in 2023. That background placed him close to the enterprise systems that agents would eventually need to navigate.
Composio initially pursued coding agents. Vaidya bought into their promise in 2023, but the models available at the time proved inadequate for what the team wanted to build. The experience redirected its attention toward integrations needed across agent applications. Rather than depending on agents to generate reliable software, the team began building the connections those agents would need to do useful work.
An early enterprise pilot made that problem concrete. A relationship from Vaidya’s time at Rubrik enabled the pilot, but unreliable code generation left the team spending two to three months manually building and repairing integrations. The work exposed the operational demands behind a seemingly simple tool call: an integration had to function reliably enough for another system to depend on it. Those lessons helped shape Composio’s product and explain why integration infrastructure became central to Vaidya’s work.
Composio connects agents to tools through discovery, authentication, and execution. An agent can find an available action, inspect its input schema, and execute it through a connected account. Its tool API also supports authenticated requests with credentials injected server-side, keeping those credentials out of the agent’s code. In its July 2025 funding announcement, the company reported $29 million in funding and described a broader ambition: turning tool interactions and feedback into reusable knowledge about how work gets done.
The systems that make agents dependable
Vaidya’s technical argument starts with the infrastructure surrounding software development. Coding agents inherit repositories, commit history, tests, review, and rollback. Knowledge-work agents often have to assemble their starting context themselves. A single customer relationship might span Salesforce records, Notion documents, Gmail correspondence, Slack conversations, and Zendesk support history. His framework for knowledge-work agents organizes the missing support into six needs: centralization, history, context, verification, governance, and reversibility.
These needs build on one another. Centralized application access gives agents a starting point; a record of actions makes their work inspectable; accumulated experience can reveal how an organization operates. Verification and governance then determine whether an intended action is appropriate, while reversibility determines how much room there is to recover from a mistake.
A cross-application record of actions. Vaidya wants agents to reconstruct earlier work and people to inspect what actually happened, rather than trusting an agent’s report of success. A useful record captures what the agent touched, what it skipped, and which attempts succeeded or failed. It gives subsequent work a history to learn from and gives users a way to check results in the applications where the work occurred.
Organizational learning from repeated work. Recurring successes and failures can become reusable skills describing how a tool works, how a company operates, and what an individual considers good work. Writing a customer document, for example, may require combining database usage, PostHog activity, and Salesforce deal details. Access makes those inputs available; learned workflow patterns help an agent understand how to use them together. Vaidya distinguishes knowing an organization’s structure from understanding its preferences: both affect whether the resulting work is useful.
Judgment as well as execution. His own hiring-outreach experiment illustrates the difference. An agent sent messages to real candidates at valid addresses and did what he requested, yet produced an outcome he regretted. Successful delivery could not answer whether the messages should have gone out. He describes comparing drafts with earlier emails to assess style and quality, then rehearsing consequential actions through mocked tools so their intended effects can be reviewed before they reach people. Verification must address the decision to act as well as the mechanics of carrying it out.
Controls that survive changes in the agent’s context. Vaidya treats prompting alone as fragile because instructions can be forgotten or lost during context compaction. He describes restricting available actions outside the agent—for example, allowing a support agent to create drafts while withholding the ability to send them—and applying policies within that access. A policy might require permission before deleting more than ten emails or prohibit messages outside a specified domain. Access controls determine what the agent can reach; policies govern how it may use that access.
Review before irreversible actions. Removing a newly added label can undo that action; a sent email has no comparable dependable reversal. Vaidya acknowledges that knowledge work cannot reproduce Git-style rollback everywhere. He describes providing reverse actions where possible and using sandbox review before actions that cannot be undone. That shifts inspection ahead of execution, when there is still an opportunity to prevent the consequence.
Vaidya’s early integration work and his later emphasis on verification address the same practical difficulty at different layers. Connecting an agent to an application makes action possible. Making that action dependable also requires a way to understand its context, inspect its work, constrain its permissions, and catch mistakes while they can still be prevented.
Karan Vaidya explains the six kinds of infrastructure that help coding agents work reliably—and how cross-app records, contextual checks, enforced permissions, and simulated actions could bring similar confidence to hiring, sales, and support.
Coding agents benefit from six surrounding primitives: centralization, history, context, verification, governance, and reversibility. Knowledge-work agents need comparable support across their apps.
A cross-app action record can serve as agent memory, a way for humans to inspect work, and material for skills that capture tool procedures, company practices, and personal preferences.
Successful tool execution does not settle whether an action should happen. The outreach example needs checks on the draft and proposed effects before real delivery.
Governance separates access from permitted behavior: permissions control what an agent can reach, while policies constrain what it can do with that access. Enforcement must live outside the agent’s memory.
Use inverse actions where they exist, such as removing an added label. For irreversible effects, sandbox review moves the decision before execution; it cannot supply a universal undo.
