Stop Doing Agent Archaeology on Your Team's Code - Richard Feldman, Delta

It’s Monday morning. A coworker is leaving for vacation and sends you a gist with a branch name and a pasted agent transcript. In Richard Feldman’s handoff scenario, you also have the issue, so you know what your coworker set out to do. You check the commits to see what they tried. But suppose the agent abandoned an approach before committing it. To the engineer picking up the branch, that dead end can still look like a promising next step.

Feldman illustrates the problem with a puzzle. You can make out a frog with its hands on something purple and dotted. A climbing wall? With the rest of the picture, it’s plainly a mushroom. The engineering version comes six months later, when someone needs to extend a feature. The code is legible. The hard question is whether its author already considered the change you’re about to make and had a good reason to rule it out.

That reason might be in a transcript nobody sent, a Slack exchange or a meeting. Now another engineer and another agent are trying to infer it from a throwaway line in a commit message. Feldman calls this “agent archaeology.” His analogy is recording a video on a phone and playing it back there. You could assemble separate devices for both jobs. Part of the convenience of the phone is that the recording is already where you need it for playback. What would it take for a decision to be there when you open the code?

While Feldman was preparing his slides, a coworker’s agent suggested checking with him about a feature he had worked on before. The coworker @-mentioned him in Delta and asked whether he was still working on undo within an agent conversation. Feldman’s earlier work was stale, and the coworker was welcome to take it over. Undo turned out to be tangential to the coworker’s task. A few messages settled who was working on it and whether someone else could pick it up.

The mention brought Feldman into the middle of the coworker’s existing agent thread. His reply stayed at the point where the question arose, and the agent could read what both people had said. Looking beyond the exchange also gave Feldman access to the work in progress, including a diff of about 2,000 lines. He could inspect the changes or join the work with his own agent if the question warranted it.

The live demo starts in Delta’s native macOS app, in a thread about a test-notification button. The operating system lets users allow notifications for individual apps. Pressing the button would let someone check whether a Delta notification actually gets through. The agent had pointed out that Delta waited until its first real notification to request permission. Feldman highlighted that statement and asked whether the delay was avoidable. With the relevant sentence selected, a few words were enough to tell the agent what to investigate.

The agent replied in the thread. Delta’s design lets teammates choose the model and the software that runs the agent, often called its harness. Feldman described support for bringing API keys and work underway on additional subscription integrations. Two engineers could use different agents and still work from the same conversation.

A second question called for a teammate’s judgment. Should an error appear briefly as a toast or stay inline? Feldman @-mentioned Bennett, who received an app notification, joined the thread and replied that he preferred the inline error. Feldman agreed. What could a future engineer learn from that reply that the UI alone would never tell them? The exchange records how much weight to give the choice. Two colleagues expressed a preference and went with it. A future agent with access to the thread could see how readily the team had made that call.

How does the agent know which part of an implementation raises a portability concern? Feldman opened the agent’s changes for line-by-line review, selected a line in the diff, asked whether it would work on Linux and pressed Enter. Delta submitted the question to the agent with the line it referred to. The demonstration established what the agent received. Linux compatibility itself remained an open review question.

A reviewer could mark the review complete, invite another coworker to approve or reject the changes, or edit the code directly. Bennett’s earlier reply had settled a design preference. Formal review gave the team a separate way to record who had examined and approved the implementation.

For the reverse handoff, Feldman took his hands off the keyboard and asked Bennett to invite him to a thread. The notification arrived. The trick was that Bennett was sitting in the audience. His thread already contained a running terminal, and its animated output updated live on Feldman’s machine. Letting Feldman type there would have given him a way to execute commands on Bennett’s computer, so Delta shared a read-only view.

Where did the next command run? Feldman pressed ! to open his own terminal and entered cargo run. Bennett could watch the build output as it happened. When the program ran, it identified Feldman as the person running it. Both engineers could follow both terminals, while each retained control of the process on his own machine.

Joining the thread had already put a mirror of Bennett’s repository on Feldman’s filesystem. That gave cargo run local code to build. Delta implements its own worktrees to make switching between these checkouts quick. Feldman could use his preferred agent against the checkout, and Bennett could keep using his. More coworkers could join the thread or open subthreads, including nested ones, to keep a discussion focused.

The audience’s first questions put practical limits around the two-person demo.

• Concurrency. Delta’s team routinely held standups with roughly 30 to 40 people in one thread and reported no problems at that size. The team had yet to run a large stress test, so the maximum concurrent user count remained open.
• Deployment. The demo used local execution and Delta’s cloud for synchronization. A cloud runner was another option for executing the agent. For organizations that needed the infrastructure on their own hardware, the first on-premises pilot was underway.
• Cost. An attendee asked about additional token expense. Feldman said the private beta was free and eventual product pricing was undecided. The effect on model token usage remained unspecified.

Delta’s own team had stopped using pull requests. When an engineer finished a change, they could ask the agent to run continuous integration (CI). After CI passed, the engineer could give a second instruction to land the change. A dedicated landing flow reported success with a green check. Teams that needed a record of human review could also have a reviewer explicitly sign off. That kept the reviewer’s approval distinct from both the test result and the confirmation that the change had landed.

Could a team @-mention an issue-handling bot the way Feldman had called in Bennett? Feldman saw a possible extension of the mention system. Delta lacked an official bot API at the time, and this was the first request he recalled for one.

When Bennett joined, did he have to read everything above the mention? Feldman answered with a different invitation he had received on the train to the talk. A coworker was working on a feature Feldman knew and brought him into the conversation. Feldman opened a subthread and asked the agent for an overview of the approach. His coworker kept working in the main thread.

Feldman used the same subthread for follow-up questions. That changes who has to do the work on Monday morning. The departing engineer can leave the conversation where it happened. The person taking over can ask for the overview they need, then spend their attention on the particular decision they came to understand.