How Jota runs banking and AI workflows on Temporal

The customer#

Jota is a Brazilian fintech building a conversational financial operating system. It brings banking, money movement, and financial intelligence into the app customers already use every day: WhatsApp. Through a single conversation, customers open an account, send and receive Pix, manage Pix keys and contacts, pay and schedule bank slip payments, get intelligent statements, create simple tasks and reminders, manage Google Calendar, and connect their other banks through Open Finance.

The choice of WhatsApp is deliberate. In Brazil, WhatsApp reaches roughly 160 million people and sits on about 99% of smartphones, and around 97% of Brazilians open it every day. Meeting customers there removes the usual barrier of downloading and learning yet another bank app. The mission is to make managing money feel like messaging a capable financial agent who happens to also be your bank. Jota also ships a native mobile app, which concentrates payments and money management in one place while staying connected to the same WhatsApp experience.

Jota is led by founder and CEO Davi Holanda, formerly director at PagSeguro and an executive at Cielo. The company launched in early 2025 and, from a standing start, grew to more than 300,000 customers (mostly small businesses and self-employed professionals) and about R$3.5 billion in annualized transaction volume within its first year.

Jota provides a conversational banking experience with an AI assistant at the center, available on WhatsApp and in the Jota app. Core capabilities include Pix (in and out, including Pix by voice, plus key management), bank slip and card payments, charges and collections, statements, scheduled payments and tasks, and Open Finance connectivity.

The headline product today is Jota 2.0, the agentic version of the assistant. It is a single durable agent that reasons step by step, calls real banking operations as tools, runs skills (such as full account management, or choosing which bank a Pix should draw from straight from the conversation), keeps memory across the conversation, and acts proactively.

Jota serves Brazilian consumers and small businesses, with a strong base of micro-entrepreneurs (MEIs), self-employed professionals, and small merchants. Many customers use both business (PJ) and personal (PF) accounts.

The challenge#

Operating a financial platform on regulated banking infrastructure means every customer action is a multi-step process that touches outside systems (a banking-as-a-service provider, an acquirer, the Pix and DICT network, WhatsApp, Open Finance providers) and must never be lost, run twice, or left half-finished. A Pix transfer, an account opening, a card payment, a scheduled task, or an end-of-day reconciliation each needs retries, idempotency, durable state, crash recovery, and a trustworthy record of what happened and when.

The AI assistant adds another layer of complexity. It has to call banking operations, get structured results back so it can reason over what actually happened, stream progress to the user, and sometimes pause and wait for the customer to tap a confirmation button, possibly minutes or hours later, without ever losing its place. Building that durability, state management, and step-by-step visibility by hand was work Jota didn't want to own.

The original plan was to climb a ladder of solutions as scale demanded. The team expected to start with out-of-the-box database patterns, then move to an event stream solution for event processing once volume grew, and only much later look seriously at Temporal, which an advisor had mentioned to us a few times. About two months into writing the first version of the backend, they decided to skip the middle steps. They pivoted the backend programming language and adopted Temporal early. Since day one of that decision, everything at Jota has run on top of Temporal.

There was no single champion. Adopting Temporal was a collective call by Jota's first four engineers early in the company's life, when they chose to skip the planned interim steps and build the backend on durable execution from the start.

The deciding factors were durable execution with strong guarantees for financial operations, first-class state management for long-running processes, and built-in visibility into every step of a workflow. The engineering and platform team were the primary stakeholders, with the decision made early enough that it shaped the backend itself.

The initial alternative was building orchestration in-house, hand-rolling state machines on top of a database and queues (with Celery planned for event processing), along with the team's own retry, idempotency, recovery, and visibility layers. The most critical factor in choosing Temporal was that it delivers durable execution, automatic retries, and full workflow visibility as a platform, which lets a small team run a financial platform without owning that orchestration plumbing.

The solution#

Jota uses Temporal across two broad use cases:

Core banking workflows: Pix out, account and merchant onboarding, card and bank slip payment processing, Open Finance reconciliations, scheduled payments and tasks, and batch jobs such as daily yield processing. Webhooks answer in milliseconds and hand the real work to workflows.
The AI agentic loop (Jota 2.0): the conversational agent itself runs as a durable workflow that calls banking operations and folds the results back into its next reasoning step.

The system is split across two Temporal-backed services that talk to each other: Banking (Go) and AI (Python). Banking runs a fast web tier for webhooks and APIs plus a Temporal worker that holds the business logic. AI runs a Temporal worker that executes the agent loop. A customer message arrives, Banking hands it to the AI workflow, the agent reasons and calls banking operations as tools, and the outcome flows back to the customer over WhatsApp or the app.

The important detail is how the two halves stay honest with each other. When the AI calls a banking tool, that tool is a banking workflow, and its user-facing results are captured and returned to the agent loop, either as the workflow result or streamed back through signals, so the model reasons over what the bank actually did rather than guessing. When an action needs the customer to confirm with a button tap, a child (fire-and-forget) workflow waits for that tap and continues the flow, while the agent loop stays free to keep working. The diagram below shows the shape of it.

High-level architecture

Here is how the architecture maps onto Temporal Workflows and Activities:

Each customer conversation runs as its own AI workflow, so the agent loop is one Temporal workflow per conversation, carrying a durable state across turns.
Each banking operation the agent triggers (Pix, payment, charge, onboarding step, and so on) runs as its own workflow, often as a child or a linked independent workflow.
Activities are split by what they touch. External and network calls (the banking-as-a-service provider, the acquirer, WhatsApp, DICT) are regular activities, so they get retries and isolation, while database and cache reads and writes use local activities for speed.
Signals stream progress and deliver tool results between Banking and AI without blocking, queries expose status, and timers let a workflow wait (for example, for a customer's button tap) over long spans.

These are the most valuable Temporal capabilities for AI:

Durable state management of the agent loop. The Workflow preserves the conversation and task state across crashes, deployments, and long waits, so the interaction can resume from the correct point.
Signals: Banking pushes results and progress into the loop as they happen, which keeps the agent unblocked and gives the customer live feedback.
Observability. Every step of a conversation and every banking action shows up on the Temporal timeline, which makes debugging an AI interaction tractable instead of opaque.
Durable waits for a human in the loop. The agent can pause for a confirmation and resume exactly where it left off.
Recoverability and replay, so failed or stuck interactions can be inspected and reasoned about deterministically.

More broadly, Jota's view is that the competitive edge in AI has shifted from the model to the harness, meaning the engineering around the model that turns raw capability into a reliable product: the loop that calls the model and interprets its answer, tool calling, context and memory, guardrails, evals, and observability. Durable execution is the backbone of that harness, which is the same reason companies like Coinbase, Netflix, LinkedIn, Block, and Datadog run critical processes on Temporal.

For our use case, we are using Signals, queries, child workflows (including fire-and-forget), schedules and timers, continue-as-new, memos and search attributes for cross-workflow traceability, automatic retries, and the split between local and regular activities. Observability is end-to-end, combining the Temporal UI, Temporal Cloud metrics dashboards, and OpenTelemetry instrumentation from the first user message to the outcome. The team is also exploring worker versioning and serverless workers for safer rollouts.

Temporal Cloud instead of self-hosting#

Self-hosting Temporal at Jota’s required reliability level would mean operating the Temporal Service and its data stores, along with the surrounding reliability work for upgrades, monitoring, backups, and any required failover architecture. As a lean fintech team, Jota chose Temporal Cloud so engineering could focus on the product and its regulated financial workflows rather than operating the orchestration platform. The team revisits this trade-off as volume grows.

The results#

The impact for our use case:

Reliable financial operations. Multi-step money movement and onboarding run with durable state, retries, and recovery from the platform rather than from hand-written code.
Releases became routine. Together with high test coverage and solid CI/CD, shipping changes to complex flows turned into a safe, everyday event.
Deep observability. The Temporal UI, Cloud metrics dashboards, and end-to-end OpenTelemetry let the team see latency, bottlenecks, and failures across an entire customer journey, and that visibility has driven real architectural decisions.
A foundation for the AI product. Jota 2.0, the agentic loop, was built on Temporal from day one, so the same reliability and observability applied before customers ever saw it. The new agent reached 100% of the base after a staged rollout and delivered roughly 3x the engagement of the previous generation in A/B testing.

In plain terms, a lean team runs a conversational AI financial platform with confidence that in-flight operations will not be lost or double-run, and with the visibility to find and fix issues quickly. That reliability foundation is what let Jota grow from a standing start in early 2025 to more than 300,000 customers and about R$3.5 billion in annualized transaction volume.

On platform scale, Jota runs on the order of 180 million Temporal Actions per month in production, growing by double digits month over month, including tens of millions of workflow executions and millions of signals as the AI loop and the bank talk to each other in real time.

Business value is quantified through Temporal Cloud metrics (action counts and activities per second), the team's Temporal metrics dashboards, and end-to-end OpenTelemetry. Together they quantify throughput, latency, and reliability since they tie platform health back to product metrics like engagement and successful transactions.

The clearest way to frame ROI is engineer-time-not-spent. Jota did not have to build or operate a durable-execution platform of its own (the state, retries, recovery, and visibility layers), and it did not have to staff a team to self-host one, which on its own would be several engineers as a floor. That saved headcount and calendar time went straight into product: a financial platform and a brand-new agentic AI built by a small team. Adopting Temporal early, before writing most of the backend, also avoided the cost of a later migration off a homegrown queue-and-database orchestration layer.

These are some words of advice we would give to other companies evaluating Temporal:

Use local activities for database and cache access and regular activities for network calls, which keeps both cost and latency in check.
Watch retention and action volume early, and tune retention plus history export so observability stays affordable as you grow.
Adopt it earlier than you think you need to. Jota planned to reach for Temporal last and ended up adopting it first, which avoided a painful migration later.
Lean on the partnership. The Temporal team's architecture reviews materially improved how Jota runs the platform.

Jota is heading into a much larger growth cycle, with public targets of 1 million customers and 5x the transacted volume in 2026, led by voice payments through Fala Tap. On the platform side, that means more proactive and capable AI agents (including voice and richer image understanding), per-product isolation through dedicated task queues so a heavy batch can never slow a Pix transfer, safer rollouts through worker versioning and serverless workers, and a move toward Kubernetes to orchestrate worker pools per task queue with rainbow deploys.

The takeaways#

Temporal enables Jota to run an AI Conversational financial platform on regulated banking infrastructure with a lean team. Durable execution, retries, recovery, and workflow visibility come from the platform, so engineers can spend their time building customer value instead of orchestration infrastructure.
Temporal is also the backbone of the AI agent, not just its backend. Jota 2.0, the agentic loop, runs as a durable workflow, and the durable state, human-in-the-loop waits, and step-by-step observability are what make an agentic banking assistant trustworthy.
Adopting it early paid off. Jota planned to reach for Temporal last and chose it first, and everything has run on it since day one, across roughly 180 million actions a month today.