Ishween Kaur
Senior Engineer, Crypto and AI @SoFi
Santa Clara, California, United States
Actions
Ishween Kaur is a Senior Software Engineer in Crypto and AI at SoFi, where she works on bringing AI thinking into the crypto space and building AI-native experiences that make her Ops teams' work easier so they can better serve SoFi members.
She was previously a founding engineer on Salesforce's AgentForce, an agentic platform serving 6,000+ enterprise customers across 17+ languages, where she built the harness, memory, guardrails and evaluation that keep agents reliable under real load and debugged them when they failed in ways a prompt could not explain.
She is Communications Lead, Women in AI California and DEIB Lead for Society of Women Engineering, and served as an AI advisor with Cornell Tech's Break Through Tech program. She speaks and runs workshops regularly, and shows working demos rather than slides.
Area of Expertise
Topics
The Memory That Made Your Agent Worse: A Live Demonstration
Give an agent memory and it gets more personal. Whether it gets more correct is a separate question that almost nobody tests.
Retrieval systems optimize for semantic relevance to the user. That is the wrong target. A user's savings goal is essential context for one question and active distraction for another, and no similarity score will tell you which situation you are in.
Bring a laptop. We run one seeded memory set through a financial agent across two contrasting decisions and watch the same stored fact improve one answer and degrade the other. Then we demonstrate the counterfactual harness: delete one
memory, rerun, and measure what changed. That single technique answers a question most memory stacks cannot, which is whether a specific memory helped a
specific decision.
Attendees leave with the repository, a seeded dataset, and a memory metadata schema to finish at home.
Python and an API key required. A hosted fallback environment is available for anyone whose setup does not cooperate.
Key Takeaways:
- Why relevance to the user is not relevance to the decision
- The counterfactual removal technique, demonstrated live
- A memory metadata schema covering freshness, decision scope, and sensitivity
- Working code to continue with after the session
Lost in Translation: What a Blind Hindi Review Reveals About Multilingual AI
Only about a quarter of internet users are native English speakers, yet most AI systems are built and evaluated as if that number were 100%. For organizations in regulated and public-facing industries, this creates a trust problem.
This session shares findings from "Lost in Translation: An Autonomous AI and Language Translation Study," a Women in AI research project led by Karen Jensen. Six AI models were evaluated in Hindi and Chinese by native-speaker reviewers: I led the Hindi evaluation and Charlotte Tao led the Chinese evaluation. Each model was scored across five dimensions: localization fluency, semantic fidelity, linguistic accuracy, terminology precision, and cultural nuance. No model excelled across all dimensions in either language and the only open-source model used scored lowest in both.
The most concerning finding was bias laundering. A Forward and Reverse Translation Audit showed that bias introduced when translating into a language can disappear when the text is translated back into English making it invisible to English-only reviewers. The study also found a consistent gap between how models rated their own translations and how they actually performed. In my blind Hindi review, five of six models scored the lowest rating on localization fluency, one silently dropped an entire section and technical terms were often left in English. Yet every model preserved gendered references correctly, which I didn't expected for Hindi, so it was a reminder that the risks we expect are not always the ones we find.
Drawing on this study and on my experience building multilingual agentic AI at enterprise scale across 17+ languages, I will share why native speakers must be part of evaluation, why model self-assessment and back-translation are not enough and how to design human-in-the-loop review that catches what automated checks miss.
Key takeaways:
- What bias laundering is and why English-only review cannot detect it
- Why model self-assessment is not a reliable evaluation signal
- A five-dimension framework for evaluating multilingual AI output
- How to build native-speaker review into AI governance without multiplying cost
Did That Memory Actually Help? (Counterfactual Evals for Agent Memory)
Give a financial agent memory and it gets more personal. Whether it gets more correct is a separate question that almost nobody tests.
The same stored fact has different value depending on the decision. A user's emergency-fund target is essential context for one question and pure distraction for a debt-repayment question. Semantic relevance to the user does not imply relevance to the decision, and retrieval systems optimize for the former.
I will walk a financial-agent prototype through the same memory set across budgeting, debt repayment, and emergency-fund decisions, comparing semantic retrieval, user-state retrieval, full-context prompting, and decision-aware retrieval. Then the workflow: freshness checks, counterfactual removal to test whether one specific memory improved the answer, deterministic calculation tools instead of trusting the model with arithmetic, and transparent memory-use logs.
For anyone deploying memory in a regulated context, the audit trail is not a nice-to-have. If you cannot say which stored facts produced an answer, you cannot defend the answer.
Key Takeaways:
- A memory metadata schema and retrieval policies for high-stakes decisions
- Counterfactual removal testing: did this specific memory improve the decision?
- Measuring decision quality against token cost, latency, and privacy exposure
- Audit trails that explain which memories drove a recommendation
Your Agent Just Paid for Nothing (6 Attacks on x402 Payments)
Agents can now discover paid APIs and authorize machine-to-machine payments without a human in the loop. Protocols like x402 make this work over plain HTTP. But a payment that settles correctly is not the same as a payment that should have happened.
I will demonstrate live attacks against an autonomous payment agent: price manipulation, malicious service discovery, prompt injection into the payment decision, duplicate payments, budget exhaustion and payment-resource mismatch. Where the agent pays for one resource and receives another. Every one of them produces a technically valid transaction.
Then the controls that actually constrain the surface, all of them are deterministic(none of them a model call): spending limits, recipient allowlists, resource binding, nonce checks, retry limits and pre-payment validation.
Attendees leave with a threat model, a benchmark and a local simulation and testnet harness for testing their own payment agents without risking real funds.
Key Takeaways:
- A working threat model for autonomous agent payments, with six demonstrated attack classes
- Deterministic controls that do not require another model in the loop
- A local simulation and testnet harness for safe testing
- Why "the payment succeeded" and "the payment was correct" are different assertions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top