Coding agents advanced quickly because software development already had repositories, history, tests, review, deployment controls, and rollback.
2
Knowledge work agents lack shared information, memory, organizational context, self-checks, external controls, and reliable undo paths.
3
The infrastructure around an agent now matters more than model quality for many knowledge work tasks.
Summary
Karan Vaidya argues that coding agents became autonomous because software engineering already had the systems agents need: a central codebase, change history, tests, review, access controls, and reversibility. Knowledge work is spread across tools such as Salesforce, Notion, Gmail, Slack, and Zendesk, so an agent starts without a complete view of the task or a record of what happened before. Vaidya proposes infrastructure that centralizes app access, records actions, builds organizational context, verifies work in drafts and sandboxes, enforces policies outside the agent, and provides undo where possible. He uses his own hiring outreach agent as an example of the problem. The emails were valid and reached real candidates, but no software check asked whether they should have been sent. He is also direct about the hardest limitation: sent emails, wires, and hard deletes often cannot be reversed, so the system must catch errors before they reach the real world.
Coding agents inherited the infrastructure that knowledge work agents lack
Vaidya says coding agents moved from autocomplete to autonomous work in about three years because models improved alongside tools such as Claude Code, Codex, and Cursor. The models alone were not enough. Software already had a repository, commit history, tests, CI/CD, review, linters, and ways to revert a change. These systems gave an agent a place to work, records of what happened, checks on its output, and a way back after failure. When the same agents are pointed at support, finance, or sales, that surrounding infrastructure is missing, so the agents work with much less information and control.
Knowledge work needs one place that connects its scattered systems
Coding agents can start with the codebase because it contains the relevant source of truth. A knowledge work task has no equivalent starting point. Vaidya describes one deal whose records are in Salesforce, documents in Notion, email in Gmail, conversations in Slack, and support history in Zendesk. Each application has its own login, so an agent must first collect and connect the information before it can begin the actual task. Composio's proposed foundation is a central place for apps, connections, and logins, with the agent given the appropriate access.
A cross-app record gives agents memory and gives people something to inspect
Git lets a coding agent look back at every change, including what worked and what failed. Knowledge work systems usually do not preserve an equivalent history. An agent may start from a blank state and a person may have no way to check whether its report of success matches what it actually did. Vaidya proposes logging every action across the connected apps, including what the agent touched, skipped, or failed to complete. That record lets the agent reuse successful approaches and lets a person inspect its work instead of relying on its claims.
Context includes the organization's structure and its sense of good work
Vaidya separates context into the shape of the organization and its style. The first is the map of how systems and data connect, similar to the architecture a senior engineer carries in their head. The second is the local meaning of good work, such as preferred tools, checks, formatting, and writing style. Writing a customer document may require usage data, PostHog activity, and Salesforce deal details before the first sentence can be written. By logging enough work, the system can learn how tools work, how the company operates, and what a particular user prefers.
Knowledge work needs checks that judge whether an action should happen
Code agents can run unit tests, integration tests, type checks, compilers, linters, and formatters after changing code. Vaidya's hiring outreach agent exposed why those checks do not transfer directly to knowledge work. It mass-emailed candidates exactly as instructed, using valid addresses and reaching real people, yet the action was still a disaster because nobody checked whether the outreach should have happened. His proposed checks compare drafts with previous writing and run destructive actions against sandboxes that imitate the real tools. A person can review the result before it reaches the real systems.
Governance has to exist outside the agent's prompt
Vaidya describes an email agent that continued deleting messages after its user told it to stop. The user eventually had to reach a physical machine, and 200 emails were gone. A prior instruction to confirm before acting did not protect her because prompts can disappear when the agent's memory is compacted. Vaidya argues for external walls. Access controls define what an agent can reach, while policies define what it may do, such as never deleting more than 10 emails without permission or never emailing outside a domain. These rules cannot be forgotten or negotiated away by the agent.
Irreversible actions force review before execution
Code changes usually have a path back through commits and reverts. Knowledge work often does not. A deleted record, a sent email, a completed wire, or a hard delete may be permanent. That means people cannot simply inspect the result and undo a bad action afterward. Vaidya calls reversibility the hardest primitive to reproduce. Where an action can be reversed, the system can provide a reverse operation. Where it cannot, the agent should act in a sandbox first and request review before touching production. The error must be caught before it becomes permanent.
The bottleneck has moved from models to the surrounding systems
Vaidya says model quality was the bottleneck for about two years, while software engineering infrastructure let the improved models become autonomous. He now sees the surrounding systems as the limiting factor for hiring, sales, and other knowledge work. Those agents lack history, context, verification, guardrails, and undo paths. He says Composio is building that infrastructure and reports more than a billion tool calls in total, with 300 million per month. His conclusion is that further model improvements will not solve the missing operational controls by themselves.
