Your Finance Agent's Bottleneck Is You

[on-hold jingle] Hello, everyone. Welcome to this session about your fin-finance agent's bottleneck is you.

So, sorry for the rude title. I don't mean to call the audience here the bottlenecks, but I'm here to talk about the harnesses that you guys are developing and using these internal harnesses to build your production agents.

So, my name is Siddanth Emani, and I'm a data scientist at Auditoria AI, and we build fi- production agents for finance. So if you're a CFO in the audience, I would love to speak to you after the session.

This talk is in between the harness engineering track and AI for finance. So this talk is mostly about identifying the bottlenecks within your developer harnesses. And if you're a developer yourself, how do you be ten-X productive with the agent harnesses that you're using?

So all of us have seen, you know, beautiful demos in this AI Engineer World's Fair. But once these demos are promoted to pilots and you start onboarding new customers, the agents has never seen these future data.

So all of us know production bugs are very high, and production guards bill by the hour, so that's a hard fact. And [chuckles] writing code is very easy, so shipping beautiful demos and showing it to a lot of people is very easy r- nowadays.

So what is the problem, and why do these demos fail in production? Is it the model? Do you need a better model? Fable Five perhaps? Or do you need faster GPUs?

Or do you need a better framework maybe? Or your RLHF loops are not working properly? So what is the answer? If we wait three and a half months, we are awarded with a new model in the market, so we can easily swap models.

If we wait perhaps one year, we have new chips, we have faster GPUs. And again, writing code is easy, so we have new fram- frameworks every day. So you can swap your framework every now and then.

So how do we, in real time, fix these production bugs? The answer is your develop velocity. The model capability increases very exponentially, and the developers have to spend a lot of time every day to automate your developer loop.

So I'm talking about four primitives here. All of you need to think about loops, and at the end of the session, I hope you can ten-X your production code.

So first we have subagents. Nowadays, whatever harness you're using, you can spawn new subagents. You can have a, you can have an army of them.

And Git worktrees are your best friend. So think of worktrees as isolated folders, and inside these folders, the agent writes whatever code it's generating. So you want these worktrees to be in parallel, so the subagents are doing independent tasks and are not fighting over the same thing.

Second, we have skills. These are your organization's secret recipes. So make sure you have a lot of skills because these skills, once you start say, uh, giving it to your agents, the agents will always make sure to use the correct and proper workflows to solve whatever production bug you're facing.

And of course, all of us have seen a lot of MCP tools being shipped into the market right now. Everybody says we can-- y- the agent can connect to whatever MCP tool and whatever third-party server there is, and your client data can live in any system you want.

And at the end of the day, if you have a lot of subagents, you have a lot of work to orchestrate, so minimal UX is the key here.

Let's look at the subagents. With you as the orchestrator, you can have, let's say with forty-eight GB of RAM on your MacBook, you can have fifty active worktrees. That is fifty active subagents working diff- independently on different tasks.

So where do these tasks come from? So let's say the production software you're going to ship has a lot of bugs that your QA is reporting. So all the Jira tickets can be thought of in a separate different worktree.

So different worktrees are h- handled by a separate agent, and these agents can spawn multiple subagents to solve that particular task. You don't want to queue up your tasks because the agent is-- will do that a lot better than you.

Let's look at, you know, um, an example harness. What if the QA reports a lot of bug tickets, and somehow, magically, there is an agent which parses the requirements, does a root cause analysis, pulls all the traces, pulls all the logs,

s- puts all this in a separate worktree,

does the TDD, r- does the-- implements the fix. Because it's in your local system, you have to do test scripts, local end-to-end testing. You create a PR. You submit the PR to your team for review.

And after review, you merge it into your master branch, let's say. After merging it, obviously you have to build a Docker image, deploy it into your development environment, test it.

Again, ship build an, an image to your stage environment, test it, deploy it to stage, and then you go back to the QA saying, "Here you go. You can test it now."

So I would like to ask a question in the audience, um,

at what points do you think the human contact is required in this, um, steps one to nine?

So I would say the human is only required at steps one and nine because the in between steps, the agent can do a lot better work.

There needs to be a human to see what work the agent is doing, and there needs to be a human at the end to validate after the work is being shipped to stage.

And obviously we need minimal UX because humans love minimal UX. So in the image if, um, you can s- if you squint your eyes and see, the image shows, um, the production agent software that you're building, the project dashboards which shows all your Kubernetes services, pods, examples, all the logs, system logs, all your Jira tickets, all your

GitHub PRs, and maybe a Claude Code session at the bottom. So this is basically a macOS widget, and you don't need to open multiple windows to do all of this work.

A developer does like variety of things in their software dev lifecycle, so you can use just this one widget to do a lot of things. So you can see from the graph also the number of neck rotations to ship one change like reduces a lot drastically, and I imagine all of you have like two to three monitors

on your table, and you just keep rotating your neck mo- orchestrating these agents.

So Auditoria works in finance, so there's a lot of regulation and policies happening in finance right now. So what does it look like for orchestrating a team of subagents in the finance sector?

If we take AI out of the picture, usually what happens is you have a human auditor which reviews the code, and you have a controller which signs off under your SOX compliance.

And reviewing agent to agent, it, it doesn't, uh-- where do you keep the accountability? If something goes wrong in production, you can't say Claude is doing this. Something is wrong.

So but let's say you have all these subagents, and you're using these harnesses to sh- fix bugs in real time. What is the bottleneck? It becomes a human attention because you yourself have to orchestrate all these different tasks.

And moving fast and breaking things in sector, in the finance sector is a lot different.

So let's look at part two, which is removing yourself from the loop. Till now I've been saying a human is required to see what the agent is doing, and at the end also to validate what the agent has done.

But with the self-improvement of the agent and model capabilities these days, we get Mi- Fable five and Mythos five and f- GPT 5.6 also. So what does it look like when you have this recursive sel- self-improvement in your internal developer, developer harnesses?

So all your production failures become input. So let's say you automate, keep automating these sel- developer harnesses every day, and you ask the agent to upgrade itself, uh, essentially.

So you do a task, you let the loop run, let's say one or two days. You solve five to six bug tickets, and you just tell the agent to analyze all the bottlenecks in this process, make a list of them, and somehow slowly keep removing these bottlenecks every day.

At the end of one month, let's say, you have a really nice self-automated loop where you just type in one sentence and just say, "Fix this bug for me."

And the agent goes off, connects to all your database systems, fetches all the logs, traces tickets, and ships it, and migrates it, migrates it to the Jira to QA pipeline.

And you can just book a vacation maybe or work from home.

And what does it look like internally, and what happens when you steer less and ship more? Nowadays, how many of you know you can give goals to your agents?

You can just set a goal and forget about it.

Anybody? Nice. Um, so what if you combine goals and loops? You can just set a goal saying there is some data discrepancy in this report, and in the production bug, like the source data is not matching with what the agent has generated.

So you can just set a goal to fix this, look into this, set a loop. You can even close li- close your laptop because you can do it from your phone nowadays.

And if you look at the last but one point, which is dreaming,

um, let's say a lot of customers are using your production software, and they're doing the same type of patterns and t- they're facing the same type of problems. So you let the agent dream like humans dream in the background so that it collects all the sessions that your customers are using and compacts it into a set of

data points which your system can use and basically upgrade yourself.

So with a combination of all these features, basically you can essentially remove yourself out of the loop. But as I said before, the developers do a lot of variety things in their software development life cycle, and sitting behind a desk from nine to five and just writing code is not valid anymore.

So just an overview of what I've covered till now in this session. You can have a team of subagents working in parallel work trees. You can have skills, your organizational secret recipes, your customers' recipes.

You can give all of these to an agent. Your agent can connect to whatever third-party server there is. It can be a logging system. It can be an authentication gateway.

And you just compress all of this into one pane of glass because minimal UX is the key.

And you can set goals and loops for autonomy. If you think this particular work can be done by the agent a lot better, you can just ship it to the agent.

Always have the human as a verifier, but not the throughput ceiling because human attention is very limited.

So thank you for your time, and thank you for your-- thank you for... I hope you, um, learned something from this session. Thank you. [audience applauding] [outro music]