Your Finance Agent's Bottleneck Is You

A polished finance-agent demo becomes a pilot. New customers arrive with data the agent has never encountered, and the failures begin. For Ramana Siddanth Emani, a data scientist at Auditoria AI, this is where harness engineering meets finance: generating code is easy, but repairing production behavior requires a dependable development workflow.

The obvious suspects are model capability, GPU speed, the framework, or the RLHF loop. Emani sketches a familiar upgrade cycle: another model in roughly three and a half months, new chips in about a year, and new frameworks seemingly every day. Those are illustrative cadences, not a release forecast. Waiting for an upgrade does not resolve the production bug in front of you.

Developer velocity determines how quickly a failure becomes a verified repair. The intervention is to automate the developer loop every day, so improvements in model capability translate into shipped fixes. Emani’s tenfold productivity goal is an aspiration for that workflow, not a measured result.

The harness has four complementary responsibilities:

Worktrees support the subagent fleet rather than constituting a fifth primitive. Git worktrees separate working directories while sharing repository data; they are not running agents or runtime sandboxes. Their value here is keeping independent edits from competing in the same checkout.

Skills encode the organization’s recipes for investigating and fixing production bugs. They give agents repeatable instructions, though instructions alone cannot guarantee correct execution. MCP tools supply connections to systems holding client data; those connections still need an implemented server, a compatible client, and authorization. Finally, minimal UX gives the human a manageable way to coordinate the resulting fleet. More workers create more orchestration work unless the interface absorbs some of it.

Emani suggests that a MacBook with 48 GB of RAM could support 50 active worktrees with 50 independently working agents. He supplies no workload, memory measurements, or throughput benchmark for that capacity claim. The architectural point is that the human can coordinate a collection of independent tasks instead of manually feeding one task at a time to one worker.

QA tickets provide the units of work. Assign each Jira ticket to its own worktree and owning agent; that agent can then delegate parts of the investigation to additional subagents. Two example tickets can receive separate checkouts with ordinary Git commands:

git worktree add -b fix/FIN-101 ../finance-FIN-101 HEAD
git worktree add -b fix/FIN-102 ../finance-FIN-102 HEAD
git worktree list

These commands prepare the folders and branches; the harness must separately start and assign the workers. The ticket-owning agent manages its task and any subsidiary work, reducing the amount of queuing the human must perform.

A useful harness does more than produce a patch. Emani’s proposed ticket-to-staging workflow carries the investigation through testing, review, deployment, and handoff:

1. Parse the QA ticket’s requirements and perform root-cause analysis.
2. Gather the relevant traces and logs into the task’s separate worktree.
3. Use test-driven development to implement the fix, then run local test scripts and end-to-end tests.
4. Create a pull request and submit it to the team for review.
5. After review, merge into the main development branch—master in the example.
6. Build a Docker image, deploy to the development environment, and test.
7. Build for staging, test and deploy there, then return the ticket to QA for validation.

The output of the loop is a change QA can exercise in staging, rather than a patch waiting for someone to move it through the remaining systems.

Asked where humans belong in the slide’s nine-step workflow, Emani chooses its first and last steps: a human needs visibility into what the agent is doing, and another checkpoint must validate the result after it reaches staging. That is an argument for automating the intervening handoffs, but the example also explicitly includes team PR review. It does not establish that review can be removed.

The interface example is a macOS widget that brings together the production application, project dashboards, Kubernetes services and pods, system logs, Jira tickets, and GitHub pull requests, with a Claude Code session at the bottom. Its purpose is to let a developer follow work across the lifecycle without opening a separate window for every system.

The accompanying neck-rotation chart turns that coordination cost into a joke about shipping changes across two or three monitors. It illustrates the intended reduction in context switching, not a measured ergonomic or productivity result. The useful design requirement is concrete: investigation, implementation, and deployment should be visible from one orchestration surface.

Finance adds a constraint that faster orchestration cannot erase. Emani describes a conventional governance example in which a human auditor reviews code and a controller signs off under SOX compliance. This is his example of accountable review, not a universal SOX procedure. Replacing both sides with agents raises the unresolved question of who takes responsibility when production behavior is wrong; blaming Claude does not answer it.

At the same time, one person cannot continuously supervise every action of a large fleet. Once agents can investigate and repair bugs concurrently, human attention becomes the scarce resource. Finance makes that tension especially consequential: reducing supervision must not mean losing responsibility for the outcome.

The next step is to reduce how often the developer must steer the process. Emani connects that ambition to improving model capabilities, then makes a more actionable proposal: feed production failures and the experience of repairing them back into the development harness. The system being improved is the workflow around the agent.

His illustrative cycle is to let the loop run for one or two days, resolve five or six tickets, and then ask the agent to identify the bottlenecks encountered along the way. List those obstacles and remove them incrementally each day. Instead of treating every repair as an isolated success, use it to discover which recurring steps still require manual intervention.

The imagined outcome after a month is a request as short as “Fix this bug for me.” The agent would connect to databases, fetch logs and traces, handle the ticket, and carry the change through the Jira-to-QA pipeline. The month is a proposed progression, not an observed time-to-autonomy result. The vacation and work-from-home remarks express the hoped-for reduction in supervision: the developer should not have to remain at the keyboard to keep each handoff moving.

A goal gives the loop an outcome to pursue beyond the next instruction. Emani’s concrete example is a finance report whose agent-generated output does not match the source data. Set the goal of investigating and fixing that discrepancy, then let a loop keep working toward it. Phone access and closing the laptop are presented as ways to step away from the desk, although the talk does not specify where execution continues.

Dreaming extends the feedback process across customer sessions. If customers repeatedly follow similar patterns and encounter similar problems, a background agent could collect those sessions and compact the recurring observations into data points the system can use to improve itself. This is a proposed learning process, without a specified implementation for turning those observations into system changes.

Together, goals, loops, background work, session learning, and remote access are intended to reduce routine steering. That changes the developer’s job: the work spans the whole software lifecycle, rather than consisting solely of writing code at a desk throughout the day.

The resulting harness combines parallel worktrees with skills that capture both organizational procedures and customer-specific recipes. Its integrations reach beyond the application itself to logging systems and authentication gateways, while one pane of glass keeps the work visible. Goals and loops then carry the tasks the agent can perform effectively without repeated human prompting.

The endpoint is not an absence of human responsibility. Keep the human as the verifier, without making human attention the throughput ceiling. That closing requirement qualifies the ambition to remove the developer from the loop: automate the repeated coordination, while retaining a person who can validate what the system has delivered.