Sevda Polat profiled Aman Gupta in Issue #43 through the frame of what his agents don't decide. I want the same KDD 2026 paper — KDD being the applied data-mining conference where industry teams publish what actually shipped — from a different angle: what his team at Nubank built before they built the agent, and why the ordering is the argument.
A March 2026 post by Gupta and Daniel Braithwaite describes an early card-delivery agent. Three steps: check delivery status, verify the address, trigger a re-order. They asked the model to sequence them, and it hallucinated the sequence. Skipped steps, dropped intermediate results, invented orderings. The fix wasn't a better prompt. They wrote a composite tool called "Fix Card Delivery" with the three-step logic in code. The model calls one tool. The tool does the rest.
The paper generalizes that into a rule: when an operation needs multiple data sources, compose the flow deterministically, in code. Their published example folds a carrier-tracking query and an internal order-management lookup into a single tool. The model doesn't decide the order because there's no order left to decide, and its reasoning gets spent on the parts that actually require judgment. I've watched teams hand responsibility to the wrong layer of the stack for twenty years. Gupta's team worked out which layer should own sequencing, and it wasn't the probabilistic one.
The paper is explicit about build order. Data and action layers come before model layers because they stay useful across model generations. Those layers are identity and authentication, action APIs, and audit trails. The action APIs are specified as idempotent and transactional, which means the endpoint can recognize that a call is a repeat of one it already handled and declines to do the work twice. The failure it's guarding against is boring and constant: a transient blip, the model retries the tool call, and a customer gets two cards. Or a payment adjustment lands twice. Blips don't schedule themselves around the on-call rotation, and the one that fires on Labor Day weekend hits the same endpoint as the one that fires on a Tuesday.
Polat framed this as "nobody gets charged twice." Right intuition, but the paper provides a contract, not a proven mechanism. It requires idempotency. It doesn't publish the key format, the deduplication store, or a duplicate-effect rate from production. The requirement is architectural; enforcement lives in infrastructure the paper doesn't show you. Audit trails have the same shape: every tool call's inputs, outputs, latency, and errors get recorded, and none of it gates execution. The architecture names the properties it needs and stops short of claiming to have proven they hold.
The five deployments are real. A/B-tested agents in front of more than 100 million customers, satisfaction up in all five, self-service resolution up in four. But those are outcome metrics: satisfaction scoring, resolution rates, escalation patterns. Action-error rates, retry rates, duplicate-effect counts don't appear. The layer the architecture treats as foundational reports no production numbers of its own. Requiring a property and measuring whether it holds under load are different things, and the paper does the first one thoroughly.
Gupta joined Nubank in April 2025. Fourteen months later: five production agents, a KDD paper, a customer base larger than most countries. The speed is itself an argument for the build order. You can move that fast when the infrastructure absorbs the model's mistakes instead of passing them downstream.
Which is the specific reason ordering matters in financial infrastructure. The model will hallucinate a tool sequence. It will retry a call it shouldn't. Those aren't edge cases you prompt your way out of; they're properties of the component you chose. The layers underneath exist to turn each one into a handled case before the agent ever talks to a customer. Build the agent first and you'll learn about the duplicate cards from the people who received them.
- Tool count changes performance: SOP-Bench, accepted at KDD 2026, found that giving an agent exactly six required tools produced nearly twice the success rate of giving it those tools plus twenty plausible but unnecessary ones — a controlled result that supports Nubank's 5–15-tool constraint from a different direction.
- Production agents stay short: The ICML 2026 study Agents in the Wild surveyed 306 practitioners and found that 68% of deployed systems allowed no more than ten steps before human intervention, with reliability ranked as the leading deployment challenge.
- Retry logic beyond idempotency: Rina Takahashi's earlier piece in this section argued that an idempotent individual call doesn't control whether a probabilistic orchestrator selected the correct call or order, a problem Nubank's composite tools address by removing the selection from the model entirely.
- Task success isn't user safety: TrickyArena tested six generalist agents against dark-pattern interfaces and found 41% average susceptibility, with the highest-performing agents often the most vulnerable — a reminder that completing the requested task and protecting the user's interests are separately measurable outcomes.