Enterprise AI in Production: Mumbai Call for Proposals

Engineering Trust in a Financial Agent: The Harness Behind the Chat

I will show how we built a financial agent, where we put the boundary between a user’s request and an authorised action, and what belongs in the agent harness rather than in the prompt.

An agent that answers a financial question and an agent that can act on it are different engineering problems. At Flip, we built a financial agent inside iMessage. The system has reached $57 million in connected volume. The interesting part is not the number. It is how we engineered trust when the interface is a conversation and the next step can have a real financial consequence. In this talk, I will walk through the agent harness: the software around the model that connects conversation state, tool execution and user approval. I will use one financial workflow to explain the boundary between understanding a request, preparing an action and executing it. I will show our Face ID approval flow inside an iMessage extension, then trace the decisions around permissions, action state and the record a user can inspect afterwards.

The implementation discussion will focus on what must be enforced outside the model, how approval fits into an asynchronous conversation, and how we reason about interrupted workflows and uncertain outcomes. I will explain the trade-off between making the agent useful and making its authority explicit. I will also cover one production failure, how we found it and what we changed This is a case study from a consumer financial product, not a claim that we deployed inside a bank. I will connect the lessons to enterprise teams building agents with real permissions and consequences. Attendees will leave with a practical way to separate model capability from execution authority, place approval at the right boundary, and evaluate the harness using workflow outcomes rather than a convincing demo.

I will explain one end-to-end workflow rather than give a tour of the product. The confirmed surfaces are iMessage, the native iOS app, an iMessage extension with Face ID approval, a dashboard and financial-account connections through Plaid.

The proposed walkthrough is: user request in iMessage → conversation and workflow state → model proposes the next step → application checks the action and its authority → user reviews and approves a money action through Face ID → financial integration executes → result and action history return to the user. This is a presentation outline, not a verified implementation diagram; I will replace each stage with the actual component and data flow before filing.

I will distinguish the harness from the application: model invocation and tool execution versus product-specific identity, permissions, financial-action rules and approval UX. I will show which decisions we made and which alternatives we rejected

Models and routing: provider/model names or an approved anonymised description; explain routing and fallbacks only if implemented.

State and execution: runtime, durable state store, queue or scheduler, and the exact approved-action lifecycle.

Trust boundaries: how user identity maps to accounts; where permissions are enforced; what approval binds to; what expires or invalidates approval.

Integrations and records: Plaid account connection is publicly described. Confirm action providers, trace/audit storage, retry behaviour and reconciliation.

Safety controls: list only implemented controls and their limits; do not imply prompt-injection immunity or guaranteed safe execution.

5. Failures and trade-offs
   The design trade-off I will explain is explicit approval versus friction. Face ID gives the user a clear checkpoint for payments and trades, but that checkpoint has to fit a conversation rather than a conventional checkout screen. I will show how we handled that in the iMessage extension.
   I will also discuss the actual recovery behaviour when an action’s outcome is uncertain I will not present a hypothetical duplicate payment or a generic model failure as something that happened to us.

6. Three takeaways
   Separate what the model can suggest from what the application is allowed to execute. Draw and test that boundary before expanding tool access.
   Make approval part of the workflow, not a sentence in the prompt. Show the intended action, bind approval to it, and define what happens if the action or its context changes.
   Evaluate the complete workflow, including interruption and recovery. Measure authorised outcomes and explain connected scale separately from execution success.

7. Audience and prerequisites
   I am aiming this talk at platform engineers, backend engineers, technical leads, and security or risk practitioners building agents that can take actions. Financial-services teams should find the control boundaries useful, while understanding that my deployment is a consumer product, not an internal banking platform.

Attendees should understand APIs, basic authentication and asynchronous workflows.

8. Preferred format
   30-minute talk, including questions. I propose 25 minutes of presentation and 5 minutes of Q&A: context and evidence (3 minutes), one workflow and its architecture (8), trust and the harness (8), failure and trade-offs (4), takeaways (2). I will use an approved architecture diagram and an anonymised workflow rather than a live demo that could expose customer data.

9. Speaker details
   Name: Uzair Ali

Role: Founding Engineer, Flip Labs

Organisation: Flip Labs

Contact: uzaxirr@gmail.com

Professional profile: https://linkedin.com/in/uzaxirr