From coding to Knowledge work agents — Karan Vaidya, Composio

Why have agents advanced so quickly in coding while support, finance, and sales trail behind? Karan Vaidya, co-founder and CTO of Composio, opens with the change from pressing “Tab, Tab, Tab” for autocomplete to letting Claude work through an assignment. His description of software engineering as fully autonomous is a broad characterization, rather than a demonstrated result across all engineering work. The useful question is what makes longer stretches of independent execution possible.

Better models and harnesses such as Claude Code, Codex, and Cursor explain part of that progress. But a coding agent also enters an environment with a repository, commit history, tests, CI/CD, review, linters, and ways to revert changes. These systems give it somewhere to find information, feedback on its work, limits on deployment, and a route back when it makes a mistake.

Moving the same agent into a business workflow removes much of that surrounding support. Composio’s proposed bridge has six primitives: centralization, history, context, verification, governance, and reversibility. The talk develops them in that order because several depend on the earlier layers: connected tools make a shared record possible, and that record can help reveal how an organization works.

A repository gives a coding agent a starting center: code and infrastructure definitions sit together, ready to inspect. A single sales deal has a different topology. Its records live in Salesforce, documents in Notion, emails in Gmail, conversations in Slack, and support history in Zendesk. Each app has its own login. Before useful work begins, the agent must find and connect those threads.

Composio’s missing center is a shared place for apps, connections, and logins, with appropriate access assigned to the agent. This gives the agent a common way to reach the information distributed across the stack. It removes the repeated work of assembling access before every assignment; understanding the relationships among the retrieved facts still requires the later context layer.

Git lets an agent look backward. Suppose a useful change was reverted after a failure, and someone now wants to recover it. The agent can inspect the earlier change and its surrounding history instead of reconstructing everything from the current files. That same record helps a human examine the agent’s work independently of its account of what it did.

Knowledge work needs comparable answers: what led to the CRM’s current state, how a colleague wrote an email that helped close a deal, or which steps escalated a support issue successfully. Vaidya’s concern is the lack of a coherent, agent-readable record across apps. Without it, each run starts with little knowledge of previous attempts, and a completion message gives the user little help checking the result.

Once actions run through a common connection layer, a record can sit above it. It logs what the agent touched, what it skipped, and what worked or failed. The record serves two parallel purposes:

• Agent memory: Retrieve similar past tasks and reuse successful approaches instead of starting blank.
• Human inspection: Examine the actions and check the affected apps rather than accepting the agent’s success message on faith.

Repeatedly observing good work can then justify delegating more tasks.

Access and history still leave two different questions unanswered:

• The map: How do the parts of the system connect, and how does data flow between them? This resembles the architectural map a senior engineer carries in their head.
• The style: What counts as good work here? A codebase’s conventions, formatters, linters, and unusual implementation choices reveal preferences that may never appear in a written playbook.

An agent needs both to produce work that fits its surroundings.

Writing a customer document makes the missing map concrete. Before the first line, a person may pull usage from a database, examine how the customer uses the product, and read deal details in Salesforce. The document becomes possible when those separate facts meet in one working context. Connecting the apps supplies the ingredients; knowing which ingredients belong together supplies the workflow.

Composio’s proposed learning mechanism begins with the action record. Enough recorded work exposes recurring approaches, successful paths, and past failures. Those patterns can be distilled into skills that an agent queries on later assignments. The context operates at three levels: how a tool works generally, how a company uses it, and how an individual prefers the work to be done.

How does a record of past actions become guidance for future work? The flow below shows the intended relationship: centralized access makes cross-app logging possible; accumulated logs reveal patterns; skills make those patterns available to another run. The valuable change is from merely remembering an event to recovering a procedure that helps the agent stop guessing.

Coding has several feedback mechanisms that check different properties. Unit tests catch local mistakes; integration tests expose failures involving other components; type checks and compilation reject certain invalid programs. Linters, formatters, and review guidance check team conventions. Together, they let an agent inspect feedback, revise its work, and continue the loop without asking a human about every small error.

Vaidya’s hiring outreach shows why that loop needs different checks outside code. He pointed OpenClaw at mass emails to candidates. It sent them as instructed, and the resulting complaints put his name on Twitter. The messages were valid, the addresses were real, and delivery reached actual people. Those checks could all pass while missing the consequential question: “Should this have gone at all?”

The failure sequence matters. An instruction became a batch of outgoing messages; real delivery made the effects public; only then did feedback reveal that something was wrong. Vaidya identifies the practical failure as outreach going out before he knew about it. The proposed correction moves evaluation earlier, while the message is still a draft and the action is still preventable.

Composio describes two complementary checks:

• Compare against previous emails: Assess the draft against messages the user has sent before, including their style and expectations of quality.
• Exercise mocked tools: Let the agent perform consequential actions in a sandbox that imitates the real tools. The user can review what would happen before the action reaches the real world.

The first supplies a contextual quality standard. The second changes where the consequences occur. In the sandbox-review path, a human still participates before execution, even though the agent can perform the preparatory checks itself.

Verification asks whether the work is good. Governance controls which actions the agent can take. The coding workflow Vaidya describes has several gates: an agent works on a branch, a human reviews before merging to main, code owners get involved for critical files, and preview deployments keep experimentation away from production. The gates vary with the damage an action could cause, leaving room for fast work inside safer areas.

Vaidya recounts an incident involving an alignment director at Meta whose email agent continued deleting messages after being told to stop. In his account, she reached a physical machine to stop it after 200 emails had disappeared, despite having prompted it to confirm beforehand. He suggests that the instruction may have been lost during context compaction; that causal explanation remains conjectural. The design problem survives either way: a remembered instruction does not itself prevent a tool from executing.

Business apps already provide pieces of access control, including Gmail scopes and Salesforce permission levels. The difficulty is coordinating those scattered controls rather than relying on prompting to fill the gaps. Composio’s answer separates two kinds of restriction:

• What the agent can reach: Deterministic permissions can make a hiring agent read-only or allow a support agent to create drafts without sending them. These limits live outside the agent’s prompt.
• What it can do with that access: Policies constrain permitted behavior, such as requiring permission to delete more than ten emails or prohibiting messages outside a particular domain.

An email agent may legitimately need email access, so access control alone cannot settle every action.

The distinction is reach versus behavior within that reach. A read-only permission removes the ability to send; a deletion policy can govern an agent that does have deletion access. Natural language supplies the policy definition in Vaidya’s description, but the talk does not explain how those definitions become enforced decisions. Its architectural requirement is clear: the tool path must enforce the rule even when the agent forgets it.

When code breaks, history provides a path back. git revert can reverse a recorded change, while git bisect helps locate the commit that introduced a failure. A production failure is still bad, but the ability to restore the code changes how much independent work a team can tolerate.

Many business actions offer no comparable reversal. Vaidya’s examples include a sent email, a completed wire, and a permanently deleted record. For those effects, checking after execution is too late. The hiring example makes the timing tangible: reviewing the outgoing text after candidates receive it cannot turn it back into an unsent draft.

Reversibility therefore needs an action-by-action decision. Adding a label has a straightforward inverse: remove the label. An irreversible hard delete needs a different route: simulate it with mocked tools, review the proposed result, and only then execute it in production. This prevents a reviewed mistake from happening; it does not make the eventual real-world action reversible.

Where should review sit for the proposed deletion of 200 emails? The comparison below contrasts the incident as recounted with the proposed sandbox path. In the first, the real inbox changes before the user can stop the run. In the second, the simulated deletion makes the proposed effect inspectable while the real inbox remains unchanged. Approval comes before the irreversible step.

Vaidya concedes that this is the hardest primitive to reproduce and that the work is unfinished. Composio is learning which actions can be walked back and preparing sandbox behavior for those that cannot. In his proposed sandbox path, a notification would tell the user that 1,200 emails are about to be deleted and ask whether to proceed; the earlier incident involved a reported 200 deletions. The useful capability is a preview of the consequence, not a universal undo button.

The ending returns to the opening question. Vaidya’s thesis is that improving models has made the surrounding infrastructure the limiting factor for knowledge-work agents. A model that can write code may also be useful in hiring or sales, but it needs information, history, organizational context, checks, permissions, and a plan for irreversible effects before it can act with comparable confidence.

Vaidya reports that Composio has powered more than a billion tool calls in total and is handling 300 million tool calls per month. Those are tool-execution volumes, rather than counts of successfully completed jobs. They give context to the company’s effort to learn from action patterns and distinguish reversible operations from irreversible ones.

The closing invitation is both practical and unfinished: connect an agent to Composio, or help build the infrastructure—the company is hiring, and there is still substantial work to do. Better models will continue to arrive. For an agent about to send an email or delete a record, the immediate engineering question is whether the systems around it can make the proposed effect visible and control when it becomes real.