What coding tools can teach office agents

What coding agents already have

A coding agent usually starts in a place that already looks like work: a repository, a history of changes, tests that can fail, a review before merge, a way to revert. Point the same kind of model at a sales deal and that picture breaks. Records sit in Salesforce, documents in Notion, mail in Gmail, chat in Slack, support history in Zendesk, each behind its own login. Before the agent can act, it has to gather those threads itself.

That gap is the argument Karan Vaidya, cofounder and CTO of Composio, makes in a conference talk the AI Engineer channel published on 3 September 2026. He groups the missing support into six parts, from a shared place to work through to undo, and he is arguing for a view of infrastructure his own company builds.

• Watch the original talk
• Korean upload (Tech Bridge)

The layer around the model

Vaidya’s first move is to separate model progress from the environment that makes progress usable. Three years ago, he says, coding help was autocomplete; now people let a coding agent run. He thinks the speed came less from the model alone than from what sits around it: the repo, commit history, tests, review, linters, and revert — the files, checks, and permissions that live outside the prompt.

He does not isolate model quality from tooling in a controlled comparison; the causal story is his thesis. A December 2024 Anthropic note on building effective agents, still useful for its architecture even though that post now warns the tooling landscape has changed, makes a nearby point: coding agents can iterate because the existing work environment pushes back, especially through tests, and human review still has to catch whether a change fits broader requirements. Extra complexity should wait on measurement. That is a reason to take the scaffolding argument seriously. His stronger line — that software engineering is fully autonomous — is not established here.

• Original talk, 1:26 — scaffolding
• Anthropic, Building effective agents (Dec 2024)

One place to work

Coding tasks, he says, usually start near a project the agent can see. The sales deal is the contrast: five systems, five logins, no default center. Access is not the same as context. Handing the model many tools can still leave it stitching a deal together. Not every repo is that clean either — tickets, design notes, and production config can sit outside it — but code at least has a default place to start.

• Original talk, 2:35 — centralization

A record you can inspect

Git is the coding analog. An agent can look back at how a change was made; a person can inspect the work instead of trusting a completion message. Vaidya wants a cross-application record of what the agent touched, skipped, got right, and got wrong. History here is evidence to inspect, not guaranteed understanding.

The business-app side of that claim is too broad. Microsoft’s Dataverse auditing docs, checked 9 September 2026, describe an official, configurable log of customer-record changes: who created or updated a record, which fields changed, previous values, and retrieval through the Web API or SDK. That is usable history in a business system. It is not a unified story of one deal across five products. Fragmented history is the more defensible version of his point.

• Original talk, 4:11 — history
• Microsoft, Manage Dataverse auditing

The map and local quality standards

Context, for Vaidya, is two things people mash together. One is the map: architecture, data flow, how work actually moves. The other is local quality standards: even for the same kind of document, what counts as good content and tone varies by organization. Writing a customer document, in his example, needs usage data, product analytics, and deal context before the first sentence. If you log enough actions, he says, patterns can become reusable procedures at three levels: how a tool works, how a company works, and how a person prefers to work.

That describes what experienced people carry in their heads. Collecting documents is not the same as having the map, and a playbook distilled from action logs is not, on this evidence, a proven skill.

• Original talk, 6:55 — context

Valid is not the same as right

In code, unit tests, integration tests, types, and the compiler can reject a defined output. Vaidya’s hiring-outreach anecdote is the knowledge-work contrast. He says he pointed his own agent at candidate email; it followed instructions; the messages were valid and reached real people; and he still regretted the outcome. Every check from the coding playbook, he says, would have passed. Nothing asked whether the outreach should have gone at all.

That is his first-person account. The point that survives without extra incident detail is narrower: format and delivery success do not answer whether the action was appropriate. His proposed fixes are a style check against prior drafts, and a sandbox — an isolated trial environment — that takes the blast before the real tool does. A sandbox can catch some mistakes before they have effects. It does not prove all real-world behavior.

• Original talk, 9:26 — verification
• Original talk, 10:25 — outreach example

Walls the prompt cannot argue with

Governance, in the talk, is the set of restrictions software teams already use: an agent can work on its own branch, a human reviews before merge, code owners watch critical files, preview is not production. Those walls vary with the potential impact of a mistake. Vaidya says knowledge-work apps have pieces of the same idea — mail scopes, CRM permission levels — but they are fragmented, so people fall back on prompting. When a system summarizes or shrinks earlier context to fit the limited conversation the model can still see, some instructions can drop out of that remaining text. That is not guaranteed every turn, which is why a rule the agent cannot argue with has to live outside the prompt.

What a tool may reach is not the same as what it may do there. He also describes a second layer: natural-language policies on that access, still enforced outside the prompt. Those rules need configuring. Coding agents do not inherently lack merge or deploy rights. If those rights are open, the wall is not present just because the work is code.

• Original talk, 12:31 — governance
• Original talk, 15:01 — walls outside the agent

Undo is not prevention

Local code changes can usually be walked back. Official Git documentation describes revert as recording new commits that reverse the effect of earlier ones. That is not a recall of a sent email or a payment. Vaidya is explicit that this last piece is unfinished for knowledge work. Removing a label may be reversible; a hard delete or a sent message may not be. For actions without a reliable inverse, he wants the sandbox and a review before anything reaches production. Catching a mistake before it happens is not the same as reversing it.

• Original talk, 16:24 — reversibility
• Git documentation: git revert

A local illustration

To make the valid-but-wrong distinction concrete, we ran a tiny constructed example. It uses synthetic task records and Python’s standard library: no model call, no network, no mail. A well-formed update to a task in the allowed project was accepted and recorded a local notice marker. The same JSON aimed at a task outside the allowed project was rejected before the task was changed. A stale revision was rejected. A truncated body never reached the policy check. Restoring the accepted local edit from recorded prior state brought the task back. The leftover marker stands for a side effect — a sent message — that restoring the task cannot recall. In this example the marker is a flag inside the process, not a real message, and the restore path does not clear it. Nothing left the process.

The flow, table, and command below are that example. They do not measure agents or recreate the talk’s platform.

python3 demo.py

assertions_passed: True

What the six parts are for

Vaidya closes by saying the bottleneck has moved from the model to infrastructure, and that his company is building the missing layer. The six-part structure is still a useful way to look at an agent workflow. The stronger claims — fully autonomous software engineering, company scale — are not independently established here. We did not compare models against surrounding tools, and we did not use the Composio product.

For someone already using a coding agent, the six parts hang together as one check. If the work has no default center, the agent is stitching context. If there is no inspectable history, you are trusting a completion message. If “good” is not in the environment, the model is guessing what the organization treats as good work. If the only checks are format and delivery, a valid action can still be the wrong one. If the wall lives in the prompt, it can disappear when earlier context is summarized or trimmed. If there is no inverse, prevention has to come before the effect. The original talk is worth watching for the slides and the delivery.

• Original talk, 19:09 — conclusion

Reproduction files

• README
• demo.py
• fixture.json
• observed-result.json