Every Pending Sales File Needs a Follow-Up. Here’s How I Built an AI Agent to Handle It.
Which loan files are still pending? What is blocking them? What did the executive promise yesterday—and has anything moved since then?
For sales managers, answering these questions means repeated follow-ups across employees, customers, and loan stages. A response like “I’ll complete it soon” still leaves them without a clear commitment to track.
We built a Sales Productivity Agent to handle these conversations: review pending files, question delays, understand blockers, and capture specific completion dates and times.
I worked on making this agent run with Claude Haiku 4.5, using a focused context and a smaller input-token budget per turn.
The engineering challenge was keeping the conversation consistent as commitments and loan stages changed.
Here’s how I approached it.
Prepare the facts before calling the model
Before each call, the backend reads the latest loan pipeline and stored commitments, then builds a shared state object for that turn.
It determines which customer is being discussed, which files are already handled, and which still need attention. If a loan has advanced to another stage, the previous stage’s commitment is treated as outdated.
The model receives this computed context, reducing the work it needs to do to reconstruct the current situation.
Give memory a specific job
For context from earlier sessions, I used the latest session summary from MongoDB alongside filtered semantic retrieval of relevant older information.
This kept the prompt focused on the current conversation and avoided duplicating the same history across memory sources.
I also separated fixed instructions from changing employee data, allowing eligible requests to reuse the static prefix through prompt caching.
Validate what the model wants to do
Haiku returns structured JSON containing its reply, proposed commitments, and whether the session should end.
Server-side guards check that proposal before the reply reaches the employee.
If the employee gives a date without a time, the commitment stays open. If the model reopens an already locked file, the backend corrects the flow. If required files remain unresolved, it blocks an early close.
One recurring issue was particularly revealing: an employee answered “yes” to a confirmation, and the model restarted the discussion. Using the stored state, the guard could move directly to asking for the missing time.
Build the final summary from saved commitments
The closing message uses validated database records for customer names, dates, and times. That keeps what the agent says aligned with what the application actually saved.
This approach comes with maintenance work. Each guard needs logging and tests because an incorrect correction can disrupt a valid conversation too.
My biggest learning from this project: a focused context and clear ownership of business rules make a cost-efficient model much more practical. The model handles the language; the backend keeps the workflow consistent.
Top comments (0)