Varun Sridhar on the agents bridging the gap between buyers and vendors: where they can act, where they stop, and how you test something before you let it near a financing application.

A customer financing workflow involves two sides with very different views of the same deal. The buyer is working through an application and waiting for an answer. The vendor is trying to close the sale and wants to know what is holding it up. Much of running a customer financing program comes down to getting the right information to the right person at the right time.

Gynger has been building agents to do that work. We spoke to Varun Sridhar, Head of Product at Gynger, about how it is put together.

In simple terms, what have you built?

We've built agents that help run a bespoke customer financing program on behalf of technology vendors.

If a vendor is selling a $100,000 annual contract, it may want to give that customer more than one way to pay: upfront, over time, or financed. If the customer chooses financing, the agent guides them through the application, connects to the data needed for review, and asks follow-up questions where something needs explaining.

On the vendor's side, agents help create offers, follow up on deals that have stalled, and keep the team updated in the systems they already use. A vendor should be able to offer this without building a financing operation internally.

What problem were you trying to solve?

There is a tension in B2B sales that never really goes away: buyers want flexibility in how they pay, and vendors want to be paid upfront.

A vendor can offer terms itself, but then it is extending credit, which carries a certain amount of risk, and most technology companies are not set up to assess who they are extending it to. The alternative is an outside financing provider, but that usually means operating within someone else's credit framework and customer experience, with less visibility and control for the vendor.

Even where financing already existed, the process could still be highly manual, with people collecting documents, chasing missing information and moving questions between the buyer and the underwriter.

Underwriting is the clearest example. A buyer connects a bank account. The underwriter looks at it and sees transactions implying there is another account that has not been connected, so they email to ask for it. That takes a couple of days to come back. The account gets connected, and now there is a large transfer in it that nobody can identify. Is that revenue, or is it borrowed money? Another email. Another couple of days.

None of those questions is particularly difficult, but when each answer takes days to come back and the questions happen in sequence, the delay compounds. The agent asks them while the buyer is still in the session. It sees the missing account before submission and flags it. It runs the analysis on the new account and asks about the transfer there and then. So when it reaches a person, the application is complete, and it arrives with the questions the agent asked and the answers it got. The reviewer is not reconstructing the picture. They are looking at it.

A vendor's credit policy is now configured as instructions rather than built as code. What does that actually mean in practice?

Different vendors want their programs to behave differently. One requires financial statements above a certain deal size. One wants first-time buyers capped at twelve months. One wants anything created from their CRM to follow a particular structure.

That used to mean writing each of those differences into a single rules engine, then wiring the logic in, testing it and deploying it. That works for the first few vendors, but becomes harder to maintain as every new program adds another set of branches to the codebase.

Now the deterministic engine stays where it is underneath, and the vendor-specific layer sits above it in plain English. "For deals above $200,000, require financial statements." "For first-time buyers, only offer twelve-month terms." Those instructions go into the agent's context, customized for each vendor. The agent reads them the way a new person would read a playbook, rather than needing them expressed as branches.

Today we write those instructions with the vendor as part of setting up their program. Letting the vendor write and change them directly is what we are building into onboarding now.

The part I would underline is that these are business policy, not prompts. And the agent has to act on them without repeating them back. If a buyer asks why they cannot have Net 90, the agent does not repeat the vendor's internal policy back to them. It explains that Net 90 is not available on the current offer and can route the request to the vendor if the buyer wants to ask for an exception.

What was harder to build than you expected?

The hardest part was defining the boundaries around the agent: where it stops acting and a person takes over, when it should stop answering, and how to make those limits hold consistently.

There is a routing order behind every agent. First, the agent checks whether the question falls within its scope. If not, it looks for an answer in the knowledge base. For buyer questions, the next step may be an escalation to the vendor. Gynger support is the final stop. When a question is escalated, the context goes with it: who the buyer is, where they are in the process, what has already been collected, what the issue is, and the recommended next step. Two failure modes we particularly want to avoid are the agent inventing an answer and the agent escalating a confused buyer with no context.

There are also things it must never do, regardless of what it is asked, such as quoting a rate before approval, suggesting someone is approved when they are not, explaining the decisioning logic or taking bank credentials in a chat window.

How do you test that before you let it near real money?

Before you get to testing, the architecture matters. The agent sits on top of deterministic infrastructure. Every tool it can call maps to a defined endpoint or workflow that behaves the same way every time. The agent decides when to call it and how to explain the result to the buyer. That is where the judgment sits, and deliberately not in the systems underneath. The boundaries are structural too, rather than a matter of how the prompt is worded.

Then we test on two separate axes. Guardrail tests are pass or fail: adversarial cases where the buyer pushes the agent toward each thing it must not do, with specific phrases that count as a failure if they appear. Correctness tests ask whether the answer was actually right rather than merely safe. Did it ask the right follow-up when the bank data showed an unexplained outflow? Did it notice the document uploaded was not the one requested?

We keep them separate deliberately. An agent can give a wrong answer and pass every guardrail. It can give an excellent answer and fail one because of a single phrase. Scoring them together hides the failures that matter most here.

And it does not stop at launch. We sample live sessions and run them back through both suites.

Everyone is shipping agents right now. What is different about doing it here?

The stakes are asymmetric. If a support chatbot gives a wrong answer, someone is annoyed and asks for a human. If ours quotes a rate before underwriting, or implies an approval that has not happened, that can create regulatory risk. The cost of one bad message is much larger than the value of any single good one. That changes how you build. Guardrails are not instructions in a prompt, they are tested rules with defined failure signals.

The other difference in our case is that the agent works across two sides of the transaction. The buyer and the vendor want different things and see different parts of the same deal, and the agent is bridging the gap between them. Take a buyer who asks for twelve months when six were offered. The agent has to work out whether that is something the vendor offers at all, whether it needs their approval, and who owns that decision. It can route the request to the vendor in Slack, the vendor can approve or decline it, and the agent carries that response back to the buyer. That could previously mean several separate conversations and a person coordinating between them.

What does running a customer financing program look like a year from now?

A vendor connects the systems it already has, describes how it wants the program to work in plain English, and can be live in days. We are not trying to replace the tools they run on.

After that, the agents work across those systems and the vendor hears about it where they already work. Less time on individual applications and routine follow-up, more on the things that actually need judgment: the policy, how the portfolio is behaving, which exceptions are worth their attention.

That changes the economics too. Rather than treating customer financing purely as a cost center, vendors can participate in the financing economics and, where appropriate, put their own capital to work.

The shift I care about is that the vendor stops thinking of the program as a product they use and starts thinking of it as a team they manage.

Interested in learning more about how a customer financing program works? See how the process works.