My first Wall Street job as a junior programmer was to process pool tapes from the GSEs and Ginnie Mae. Every month, the tapes arrived and an operator loaded them. Then I ran through a series of scripts — the same series, in the same order — to produce prepayment reports. The reports were printed, photocopied, stapled. Every desk got its copy before the open. For this, the firm paid me slightly more than the prevailing minimum wage. 

This went on for a couple of years. Eventually two things happened: I wanted to get paid more, and management decided I could do more useful things — like help build prepayment and OAS models. My boss’s solution was not to hire another me. It was to automate the whole process with proper error handling and hand it off to the operator who was already running other overnight jobs. 

Looking back, the strange part isn’t that the job got automated. It’s that for two years, nobody thought it was odd to pay a human to be a scheduler. The job was never “Suhrud runs the reports.” The job was “the reports get run.” The moment someone articulated it that way, the answer was obvious. 

I’ve been thinking about this a lot lately, because the industry is busy making the same mistake with a much more expensive employee. 

The rerun 

Today we wire LLMs into our systems through connectors and MCP servers, and then we ask them to perform recurring tasks. Pull the latest remittance data. Run the QC checks. Format the surveillance report. Post it to the channel. Every day. Sometimes every hour. 

Here’s what actually happens on each run: the model re-reads its instructions, re-loads its tool definitions, rediscovers the schema, re-reasons through steps it reasoned through yesterday, and re-derives the entire task from first principles. It is me in that back office — except the photocopier bills by the token, and the junior programmer occasionally hallucinates a column mapping. 

That is the junior programmer problem: an LLM is a bright, expensive generalist being asked to do clerical work on repeat. It can help figure out the process, draft the checklist, and handle exceptions. But if the job is the same every morning, the goal should be to convert the junior programmer’s reasoning into reviewed code and let the system run it. The junior programmer belongs at the design table and the exception desk — not standing at the photocopier forever. 

Two problems compound here. One is cost. The other, worse one, is that the junior programmer is non-deterministic. 

The economics 

Take a realistic daily agentic job: a report run against a data warehouse via MCP connectors, with QC checks and a written summary. 

Each turn carries a base context of roughly 20K tokens — system prompt, tool definitions, instructions. The agent makes maybe 15 tool calls (list the tables, query, check, query again), each returning a few thousand tokens of results. Because every turn re-sends the growing conversation, cumulative input compounds to roughly 800K–850K input tokens per run, plus a few thousand tokens of output. 

At current mid-tier model pricing (about $3 per million input tokens, $15 per million output), that’s roughly $2.50 to $2.75 per run. Daily across 22 business days: ~$55 to $60 a month. For one report. Run thirty recurring jobs like that — not an unusual number for a surveillance or analytics desk — and you’re around $1,700 a month for work that is identical every day. 

Now the honest version, because a sophisticated reader will raise it immediately: prompt caching cuts repeated input cost by about 90%, and batch APIs knock another 50% off. A well-engineered agent run might land closer to $0.30–0.50, or roughly $10 a month per job. That’s real, and if you’re going to keep agents in the loop, you should absolutely use both. 

But compare the alternative. A scheduled script on Cloudflare Workers runs free or nearly so. AWS Lambda executes this class of job for well under a dollar a month. And the one-time cost of having the LLM write that script? Maybe $1–5 of tokens. Even against the fully optimized agent, the deployed script is one hundred to a thousand times cheaper than the agent — and that gap is before you price the risk. 

The overconfidence risk (AI hallucination) is worse than the bill 

A deployed script is deterministic and auditable. Same inputs, same outputs. It’s versioned, diffable, and reviewable. When it breaks, it breaks loudly and identically. 

An LLM performing the task fresh each morning is a new draw from a distribution. It will usually do the right thing. Occasionally it will skip a QC check, misread a schema change as an instruction, or format a number differently on run 47 — silently. In regulated finance, “the agent usually gets it right” is not a control. Anyone who has sat through a model governance review knows that the question isn’t whether the process works; it’s whether you can prove what it did, every time. 

To be fair, this argument cuts both ways, and pretending otherwise would be dishonest. LLM-generated code can also be wrong — subtly, in edge cases, in ways that survive a casual glance. The principle isn’t “code good, agent bad.” The principle is review once, run many. A script gets one round of concentrated human scrutiny, and that scrutiny amortizes across thousands of executions. An agent-in-the-loop asks you to trust a fresh, unreviewed performance every single run. My boss didn’t just automate my job — he automated it with error handling, and someone reviewed that logic before the operator ever touched it. That review was the whole point. 

Use the LLM for Judgment, Not Execution 

The obvious objection is that nobody serious should run a fully deterministic job through an agent loop. Fair. But many tasks are not purely deterministic. They look repetitive on the surface while still containing moments of judgment: triaging anomalies, deciding whether a failed reconciliation is a data problem or a real signal, or writing the two sentences of commentary that make a report useful. Those are legitimate places for an LLM. 

But that does not make the LLM the operator. 

The right pattern is LLM as designer, author, and escalation point — not as the thing that runs the job every day. The operating layer should be code: scheduled, versioned, reviewed, monitored, and boring. Code should extract the data, validate it, compute the results, apply the rules, and distribute the output. The LLM should be called only when the process reaches a judgment node: when a check fails, when a number looks strange, when the rules do not cover the case, or when a human-quality narrative is actually needed. 

That is the same pattern my boss landed on in the 1990s. The operator ran the job. The human did not sit there rerunning the same steps every morning; the human got called when something broke or required judgment. The modern equivalent is not “replace the operator with an LLM.” It is “let code be the operator, and let the LLM help design the system, explain exceptions, and handle ambiguity.” 

This is also where the tooling ecosystem is already headed. The model vendors themselves are pushing patterns where the model writes and executes code rather than acting as a chatty runtime that makes dozens of repeated tool calls. That is not a rejection of LLMs. It is a more disciplined role for them: use the model to create and improve the machinery, not to impersonate the machinery every time it runs. 

Where to put the production version 

Once the LLM has written your pipeline and a human has reviewed it, deployment is genuinely easy now: 

Cloudflare Workers + Cron Triggers. Zero infrastructure, generous free tier, ideal for API-glue jobs — fetch, transform, post. If your job is stitching services together, start here. 

Railway. Dead simple for Python jobs with real dependencies — pandas, database drivers, the works. Push a repo, set a schedule, done. Roughly $5 a month. 

AWS Lambda + EventBridge. Pennies per run, and the path of least resistance if your firm already lives in AWS and your security team wants everything inside the VPC. 

GitHub Actions scheduled workflows. Underrated. If the code already lives in a repo, a cron-scheduled workflow is free for many light jobs and keeps the pipeline next to its own version history. 

One honest caveat: deployed code is not free either. Schemas drift, credentials rotate, upstream APIs change, and someone owns the pager. But maintenance cost is bounded and occasional. Agent cost is unbounded and per-run. That asymmetry is the whole argument. 

A simple approach 

If you can write down the steps, write code — or better, have the LLM write it, then review it once and deploy it. If the task genuinely requires judgment on every run, keep the LLM in the loop — but only at the judgment node, not driving the whole pipeline. 

Thirty years ago, my boss promoted me out of a job by automating it, and the firm got both a cheaper process and a modeler out of the deal. Do the same for your LLM. Let it write the script. Let the script run. Save the tokens — and the trust — for the work that actually needs a mind. 

Every wave of financial technology innovation brings the same prediction: software will be commoditized. Today, that prediction is being applied to AI. If AI models can reason, summarize, and generate code, the thinking goes, B2B vertical SaaS becomes unnecessary. 

That conclusion is inherently wrong. ABF platforms are not feature layers, they are governed systems.  

The last mile of AI deployment isn’t friction—it’s the moat. 

ABF Is Not a “Promptable” Problem 

ABF platforms sit directly in the flow of capital allocation, risk management, and regulation. For asset managers deploying institutional capital, this creates a very high bar for reliable data, validated models and domain-specific workflow.  

The real question isn’t whether a system can produce answers. It’s whether it can produce results that are: 

• Consistent over reporting periods and market cycles 

• Explainable under stress and investor scrutiny 

• Defensible and robust enough for LPs, investment committees, and regulators 

That high bar changes everything. It explains why technology adoption in financial markets moves cautiously and why legacy systems persist. These systems embed decision rights, controls, and institutional logic that can’t simply be recreated with better prompts. Any platform that ignores this reality will struggle to scale beyond pilots. 

Which leads to the obvious question: if AI is so powerful, where does it actually help? 

AI Accelerates Workflow — Not Accountability 

Applied correctly, AI can materially improve ABF workflows. It can ingest complex credit agreements faster, reconcile data across counterparties, flag covenant breaches, and reduce manual reporting work. In other words, AI increases operational leverage. 

But AI does not remove the need for explicit deployment configuration and governance. Institutions still must define who owns key assumptions, which decisions can be automated, and where accountability sits when outcomes affect capital. These embedded design choices (not prompts) ultimately determine whether a platform is trusted. 

AI compresses timelines, but responsibility remains fixed. Once this distinction is recognized, the broader implication becomes clear: AI does not eliminate the need for software. It raises the bar for it. 

Software Remains the System of Record 

The idea that AI replaces SaaS also misunderstands where SaaS enterprise value lives. Enterprise value in ABF doesn’t live in isolated insights. It lives in controlled systems of record and durable platforms that provide: 

• Governed data and the system of record 

• Embedded domain expertise 

• Repeatable processes that survive personnel turnover 

• A shared source of truth across counterparties, investment, risk, accounting, and investor relations 

AI without software discipline creates speed without stability. With it, AI becomes force-multiplying. The question, then, is what separates platforms that successfully integrate AI from those that don’t. 

The Real Differentiator: Deployment Intelligence at Scale 

What separates enduring platforms from feature-rich tools is not model sophistication—it’s deployment intelligence — the ability to integrate AI into live production environments without weakening controls. That requires: 

• Controlled data pipelines designed for real-world imperfections 

• Configuration layers that adapt to fund-specific structures without breaking controls 

• AI outputs that are transparent, and auditable 

• Implementation treated as a repeatable product, not bespoke services 

This is where defensibility emerges. Deployment intelligence compounds with each client rollout. Each successful implementation strengthens the next, deepening institutional trust and operational resilience. AI amplifies this flywheel but cannot replace it. 

The Mispriced Risk of “AI-Only” Narratives 

In private credit, trust is earned slowly and lost quickly. It is built through consistent valuations, defensible reporting, and reliability during market dislocations. 

A system that produces faster answers, but weaker confidence does not displace incumbents. It increases operational and reputational risk. Investors should be wary of platforms that promise instant replacement without acknowledging institutional reality of fiduciary-grade infrastructure. 

The Investment Takeaway 

AI is not commoditizing ABF software solutions. It is widening the moat for platforms that integrate AI responsibly into governed systems. 

The next phase of growth for category leaders such as RiskSpan will be driven by combining deep domain knowledge with AI-native architecture. Leaders will treat the last mile – data integration, workflow configuration, and control design — as a core product capability, not an implementation afterthought. 

In markets where trillions in capital allocation depend on data integrity and institutional trust, the last mile isn’t an implementation detail. 

It’s the moat. 

The lessons nobody puts in the demo. 

In 2025, our team built production AI systems that process billions of performance records for tens of millions of mortgages, develop cash flow models for complex private ABF structures directly from documents, and connect large language models directly to bond analytics APIs. 

We built dashboards, connectors, and credit analytics. Some of them worked. Some of them taught us more by failing. 

This is what we learned—not the polished conference talk version, but the notes we’d share with a peer team starting the same journey. 

The Value Shift Nobody Prepares You For 

A portfolio delinquency analysis that used to take three hours now takes twenty minutes. 

That sounds like a win. It is a win. But it also raises a question that’s harder to answer than any technical problem we solved this year: 

If AI handles in minutes what took us hours, what are we contributing? 

When we started pulling this thread, we realized that a significant portion of what felt like skilled analytical work was actually mechanical labor—data extraction, formatting, applying the same methodology we’d applied dozens of times before. The expertise was real, but it was wrapped in hours of execution that masked how much of the work was routine. 

Here’s where we landed: 

AI handles the “how.” Humans own the “why” and “so what.” 

The value now lives in knowing which questions matter. Understanding what the client really needs versus what they say they need. Recognizing when output is wrong because we understand the domain deeply enough to see the error. 

That’s an entirely different skill set. It requires judgment, contextual awareness, and domain intuition that deepens over years—the kind of expertise AI can’t simply replicate, unlike procedural analytical work.

Not everyone will make this transition comfortably. The analysts who built their identity around being fast and thorough at execution face a harder adjustment than those who always saw execution as a means to an end. 

We don’t have this all figured out yet. But we’ve stopped pretending the shift isn’t happening. 

Stop Asking AI to Write Code—Start Asking It to Think With You 

For years, we used Claude as a coding assistant. “Write a function that does X.” “Convert this data from format A to format B.” “Generate a script that calculates Y.” 

That works. But it captures maybe 20% of the value. 

The shift that changed our results was: treating Claude not as a tool to instruct, but as an analyst to think alongside. 

The difference looks like this: 

Before (instruction mode): 

“Write a Python script to calculate delinquency rates from this loan data.” 

After (thinking partner mode): 

“We need to identify hidden credit risk in this CLO portfolio—issuers that resemble recent defaults but haven’t shown price distress yet. What factors should we consider? What data would we need? Let’s build a scoring model together.” 

That second conversation led to identifying hidden exposure across issuers. Claude suggested factors we hadn’t considered—CLO concentration patterns, industry clustering effects, the relationship between coupon levels and distress signals. We debated the weighting. We refined the methodology. The output was genuinely collaborative. 

The code that emerged from the second approach was better, but that’s almost beside the point. The thinking was better. The model was better. The insight was better. 

This requires a different posture than most of us learned. You have to think out loud. Admit what you don’t know. Explain your reasoning and invite critique. Treat the AI as a colleague who happens to have read every document and doesn’t get tired—not as a sophisticated autocomplete. 

The developers and analysts on our team who made this shift produce substantively different work than those who are still in instruction mode. And the gap is widening. 

The First Version Will Be Wrong—Plan for It 

We built a benchmark analysis comparing a client’s NonQM loan portfolio against the broader market. The analysis looked solid: the portfolio showed a 1.37% delinquency rate advantage versus the universe. Strong results. Ready to present. 

Then someone asked about DSCR loans. 

In NonQM lending, DSCR (debt service coverage ratio) loans are a category unto themselves—with measurably better performance than other NonQM products. When we segmented the data, we discovered the universe was comprised of 43% DSCR loans while the client’s portfolio had only 30% DSCR loans. 

This changed everything. 

The client’s portfolio had less exposure to DSCR loans (the better-performing segment) yet still outperformed the benchmark. That alone was impressive, but our initial analysis understated the true picture. Once we compared performance within segments (DSCR vs. DSCR, non-DSCR vs. non-DSCR), the client’s edge was even larger than we’d initially observed. 

If we had presented the first version, we would have undersold our client’s own performance. The insight that mattered most—superior underwriting across both loan categories—would have been invisible. 

Lesson: “Wrong” doesn’t mean broken. It means the output doesn’t fully reflect reality. Have a domain expert review the work before drawing conclusions. 

Deploying AI Agents for End Users Is a Security Project 

Building an AI agent that works in a demo is straightforward. Deploying that agent in a production UI where real users interact with real data took us months. 

We built an agent that lets users query our bond analytics platform conversationally. The AI worked. Making it production-ready required solving problems: 

Prompt injection: When users can type anything into a text box processed by an LLM, you inherit a new attack surface. We implemented input validation, output filtering, tightly scoped permissions, and logging that captures every agent action for audit. 

Rate limiting: A single conversational turn might trigger 50 API calls. We built tiered limits—per-user, per-session, per-token—plus circuit breakers for runaway queries. 

Session management: Agent sessions need conversational context across multiple turns, isolated per user, with graceful expiration handling and automatic cleanup. 

Audit trails: Regulated industries need to know what the AI did. Every query, tool invocation, and response needs to be logged immutably. 

The agent itself was 20% of the effort. Authentication, authorization, input validation, rate limiting, session management, and security review were the other 80%. 

Lesson: In production, the agent is the easy part. The security wrapper is the product. 

Post script: AgentCore from AWS and Agent Framework from Microsoft are solving the deployment and security headaches.  

AI Is Good at Finding Information But Sometimes Overstates What It Means 

While building the credit risk analysis, we asked Claude to research distressed issuers—companies that had defaulted or were showing signs of stress. We wanted to understand patterns we could use to identify similar risks in the portfolio. 

Claude surfaced real-time signals we wouldn’t have found efficiently on our own: FTC antitrust actions, rating agency downgrades, refinancing walls, fraud allegations. Information that wouldn’t appear in pricing data for months was available in news coverage and regulatory filings. The research phase that would have taken days was completed in hours. 

But we also caught Claude drawing confident conclusions from weak sources. In one case, it attributed claims to “industry reports” that didn’t exist when we followed the links. The search results were real. The sources were ‘real’. But the synthesis drew conclusions the sources didn’t support. 

The lesson: use AI-powered search aggressively. It’s the difference between stale knowledge and current intelligence, especially in fast-moving situations. But verify specific claims. Click the links. Read the actual sources. 

AI is excellent at finding relevant information across large volumes of text. It is sometimes too confident about what that information means when synthesized. The combination of broad retrieval and skeptical verification is more powerful than either alone. 

Your Org Chart Isn’t Ready for This 

Our AI strategy deck included projections: reduction in onboarding costs, increased client capacity and margin expansion. 

The numbers were defensible. The business case was clear. 

What the projections didn’t address: the organizational implications of realizing the promised efficiencies. 

If analysts can serve five times more clients, do you need fewer analysts—or do you pursue five times more clients? If the answer is “more clients,” do you have the sales capacity? The support infrastructure? The management bandwidth? 

If developers now own adoption metrics for the features they build, then what happens to the product managers who previously owned that? Are product managers freed up for more strategic work, or are they defending territory? 

If AI drafts client communications, who reviews them? What error rate are we willing to accept? Who’s accountable when the AI gets something wrong? 

These aren’t hypothetical questions. We’re navigating them now, and the answers aren’t obvious. 

AI doesn’t just improve workflows. It reshapes roles. And most organizations—including ours—are making it up as they go. 

The companies that figure out the organizational design will outperform those that simply purchase better software. The differentiation in 2026 won’t come from adopting AI. It will come from redesigning teams, incentives, and accountability structures around what AI makes newly possible. 

What We’re Taking Into Next Year 

A year of building AI systems in structured finance clarified a few things: 

AI is more powerful than the hype suggests—once you integrate it into real workflows rather than treating it as a research toy. 

AI is more frustrating than the demos show—the gap between “works in claude.ai” and “works in production” is where most of the time goes. 

AI is more dependent on domain expertise than the automation narrative implies—it generates analyses quickly, but distinguishing plausible from accurate requires human judgement that compounds over years. The “why” and “so what” remain stubbornly human problems.  

AI changes more than technology—it changes job descriptions, team structures, and how people understand their own value. The skill isn’t operating the tool; it’s knowing when the output reflects reality. 

We don’t have all the answers. We’re still learning what this means for how we build software, how we serve clients, and how we organize ourselves. 

But we’re no longer wondering whether AI will change our industry. We’re focused on making sure we’re the ones defining how.