PTEN

Itaú · AI product concept · 2026

i.agora

Making the financial future visible enough to act on today.

Hackathon concept / prototype — not a product launched by Itaú.

Try the interactive prototype (opens in a new tab)

Refined after the hackathon · simulated financial data.

During Batalha de agentes Itaú, our multidisciplinary team explored how transactional data, deterministic financial calculations and generative AI could help financially vulnerable customers move from diagnosis to action.

Role
Product Designer / AI Experience Design
Team
Design · Data · Engineering · Business
Scope
Problem framing, journey, AI interaction, prototyping, design system and proposed metrics
Output
Functional AI prototype, mobile experience and product concept
Editorial cover featuring the i.agora and Itaú marks beside two real screens of the refined prototype: Maria's negative balance and the January plan
Real screens from the refined post-hackathon concept, composed for this case. Financial values are simulated.Open interactive prototype (opens in a new tab)

01 / Problem

The problem wasn’t only debt. It was financial vulnerability.

We began with the synthetic, challenge-provided dataset, expecting to find an opportunity focused on people already in debt or delinquent. The analysis shifted that framing.

Hackathon dataset analysis Challenge sample only · not Itaú’s full customer population

~1,000customers

~98,000transactional records

30–34%of the sample showed signs of financial vulnerability

The team's analysis shifted attention from delinquency alone to a wider pattern: roughly 30–34% of the challenge sample showed signs of vulnerability, such as ending a period close to zero or in the negative. This was a directional reading of the hackathon dataset—not a population estimate, statistically significant finding or official Itaú statistic.

The opportunity wasn’t only helping people after financial distress. It was helping before a fragile pattern became a larger problem.

Reactive bankingPreventive financial guidance

02 / Insight

People can see their balance. They can’t easily see their trajectory.

Financial interfaces are good at showing how much I have, what I spent, my bill and my transactions. They are less equipped to answer a harder question: “If I keep going like this, where does it take me?”

Our first product hypothesis was to turn financial intentions into visible, comparable futures. The concept brought three capabilities together:

01

Understand

Interpret income, recurring expenses, commitments and goals.

02

Anticipate

Project how a decision could affect the coming months.

03

Orient

Explain scenarios and trade-offs without deciding for the customer.

03 / Scope discipline

The first idea was broader than the problem needed.

In the first hours, we explored multiple futures, goals, personalization, gamification, financial products, recommendations, rewards and coins, multiple agents and continuous follow-up. It could become a rich ecosystem, but it was too much scope for the challenge’s timebox.

Broad ecosystemOne customer. One problem. One plan.

This was not a failed direction; it was a lesson in scope discipline. We shifted from explaining an entire financial system to telling one coherent financial story.

04 / Journey

Instead of explaining a financial system, we told one financial story.

Maria is the character in the prototype, not a real participant. Her six steps connect a difficult present to a more tangible next decision.

  1. 01

    Reality

    Maria opens the app and sees her account in the negative. She does not need another dashboard to tell her she has a problem; she already feels it.

  2. 02

    Conversation

    She talks with i.ai, the bank’s conversational experience. When it recognizes her financial context, it introduces i.agora as a specialized capability—not a separate app. Keeping it within the existing conversation reduces fragmentation and another destination to learn.

  3. 03

    Context

    Available financial history helps the concept understand income, recurring spending, commitments, relevant categories, financial margin and recent behavior.

  4. 04

    Plan

    Rather than saying “spend less,” the agent proposes values and limits in a measurable plan. Maria can accept or adjust them. The 50 / 30 / 20 model is an organizing reference adapted to her scenario—not a universal rule or definitive financial recommendation.

  5. 05

    Optional share card

    After accepting the plan, Maria sees an optional share card to mark the moment. It contains no financial values; the agent does not make decisions or move money for her.

  6. 06

    January tracker

    The tracker shows a R$620 projected reserve against the plan, while explicitly noting that no progress on January commitments has yet been confirmed. The reserve is a projection, not an achieved result, and no automatic transfer takes place.

05 / Prototype

From a negative balance to a next step she can see.

The mobile prototype makes the sequence legible: context, conversation, diagnosis, plan, commitment and a possible future. These are screens of a concept, not evidence of a launched service.

01 / Reality

Start with the moment that matters.

Maria sees the state of her account in context. The experience begins where her concern already is instead of adding another summary dashboard.

i.agora concept opening screen showing Maria’s account context and negative balance
Account context opens Maria’s story.

02 / Conversation · 03 / Diagnosis

Move from a question to a clearer picture.

In the existing i.ai conversation, i.agora appears as a focused capability. The diagnosis brings together the financial context that can inform a plan without presenting the AI as an independent authority.

i.ai conversation introducing the i.agora financial guidance capability
The conversation introduces the capability.
i.agora concept diagnosis summarizing financial context for Maria
A contextual, explainable diagnosis.

04 / Plan

Make “spend less” specific enough to consider.

The 50 / 30 / 20 reference is adapted to the character’s scenario as a proposal, not a universal formula. Maria can review the proposed values and choose to accept or adjust them; the figures are simulated, not transactions or confirmed spending.

i.agora January plan comparing recent spending with proposed category limits for Maria
A proposed plan, grounded in Maria’s scenario.
i.agora proposed January values, including a projected R$620 reserve, with controls to accept the plan or adjust values
Proposed amounts and a choice to accept or adjust.

05 / Optional share card · 06 / January tracker

Mark the choice, then show what is still only projected.

The share card appears after plan acceptance and contains no financial values. The January tracker shows a R$620 projected reserve, but no confirmed progress on commitments yet. Nothing is transferred automatically.

Optional i.agora share card shown after Maria accepts the plan; it contains an encouraging message but no financial values
An optional, value-free share card shown after accepting the plan.
January tracker showing a R$620 projected reserve and stating that no January commitment progress is confirmed yet
R$620 projected reserve; January progress is not yet confirmed.

06 / My contribution

My role was to turn the concept into an experience people could understand.

I shaped the problem framing and experience proposition, built the journey and interaction narrative, and designed the i.agora experience. I also worked with the team on product metrics, mapped the conceptual connection between i.ai and i.agora, and explored conversational prompts and behavior.

To support rapid prototyping, I created Figma components and tokens based on the existing app experience, built a visual library, iterated on the prototype and explored gamification. I later refined the experience and prototype after the official challenge period.

This work was collaborative. Data interpretation and analysis, data modeling, backend, full architecture and GCP infrastructure belonged to other specialties on the multidisciplinary team; I partnered with those contributors rather than claiming those deliverables as my own.

07 / AI in the product and process

AI wasn’t added at the end. It changed how we designed and built the experience.

Inside the product

The concept separated numerical responsibility from conversational explanation. Transactional data feeds a financial context layer; deterministic calculations and simulation produce the figures; an LLM interprets that context and supports conversation; the interface turns it into an actionable explanation.

  1. Transactional data
  2. Financial context layer
  3. Deterministic calculations / simulation
  4. LLM interpretation and conversation
  5. Generative interface / actionable explanation

Financial calculations should not depend on an LLM generating numbers. In the proposed architecture, calculations and rules belong to deterministic layers. Generative AI is primarily responsible for interpretation, contextualization, conversation, explanation and adapting language. This separation is intended to reduce hallucination risk in a high-trust context; it is an architectural principle for the concept, not a claim of production validation.

In the design process

AI accelerated concept exploration, prompt structure, conversational variations, prototyping, implementation, flow critique, front-end iteration and post-hackathon refinement. It compressed the distance between idea, interface and working prototype—but did not replace research, design judgment or validation.

08 / Trust

Designing for a high-trust context

These were behavior principles considered while shaping the concept—not a certification, legal approval or claim of regulatory compliance.

  • No fear, guilt or shame as persuasion.
  • Projections framed as hypotheses, never guarantees.
  • Make assumptions and simulations visible.
  • Never make the decision for the customer.
  • No definitive financial recommendations.
  • Keep deterministic calculations separate from generative language.
  • Support financial education and personal autonomy.
  • Show product information only when supported by authorized sources.
  • Allow escalation to human support when needed.

We considered Brazilian financial-education and responsible-communication principles while defining the agent’s behavior.

09 / Hypotheses

How we would measure success

These are proposed metrics from the challenge—not achieved results. The concept did not go into production, so there are no measured customer or business outcomes to report.

  • Goal attainmentShare of financial goals reached within the defined timeframe.
  • Response qualityProposed target of >80% success across relevance, clarity and context.
  • Action rateShare of users who take an action after a simulation.
  • Plan adherenceHow a user’s progress changes against an agreed plan.
  • Product relevanceFit between a customer’s profile, context and any product presented.
  • ConversionConversion to products only when those products genuinely fit the journey.

Customer value

Better understanding, greater ability to act and financial progress.

Business value

A more relevant relationship and contextual opportunities to present products.

The business opportunity appears after customer value—not instead of it.

10 / Retrospective

The strongest lesson wasn’t about AI. It was about scope.

As a group, we explored an enormous number of possibilities in very little time—and tried to develop too many of them at once.

We designed an ecosystem when the challenge probably needed one exceptionally clear moment.

What worked

  • A relevant problem emerging from the dataset.
  • Multidisciplinary collaboration and close work across Design, Data and Engineering.
  • Rapid prototyping and a functional prototype.
  • Conscious use of AI.
  • A visual language close to the existing product.
  • Turning abstract data into an experience people could follow.

What I’d change

  • Reduce scope much earlier and choose one central hypothesis.
  • Set success metrics before the final phase.
  • Cut parallel features and protect the presentation narrative.
  • Prioritize clarity of value over the number of possibilities.

Less would have made the idea stronger.

That insight directly informed the version I refined after the hackathon.

11 / After the challenge

Hackathon submission post-hackathon refinement

After the event, I individually refined the prototype to show how the experience could work with more design time. This is a later concept iteration—not a representation of the exact version judged in the competition.

  • Removed distractions.
  • Strengthened Maria’s story.
  • Connected negative balance → conversation → diagnosis → plan → commitment → future.
  • Improved hierarchy and pacing.
  • Reduced unnecessary explanation.
  • Made i.agora’s purpose more immediately visible.

12 / What remains

The future doesn’t need to be predictable to become useful.

i.agora started as an exploration of financial simulation and gradually became something simpler: a way to turn abstract financial consequences into a next step someone can actually understand.

The project reinforced something I increasingly believe about AI products: intelligence alone isn’t the experience. The design challenge is deciding what the system should know, what it should calculate, what it should explain—and when it should simply help the user decide.

Make the complex clear enough to act.

Try the interactive prototype (opens in a new tab)