AI Engineer World's Fair 2026
Simulation-Maxxing: How Nubank ships agents 20× faster with simulations
Read the talk
Simulation-Maxxing: How Nubank Accelerates Agent Evaluation
Nubank uses simulated customers and consistent mocked tool state to test agent changes before live experiments, shortening the wait for useful evaluation signal.
From a talk by Shreya Rajpal and Aman Gupta
Before you start: Familiarity with tool-calling agents, offline evaluation and production A/B testing will help you follow the workflow.
Improving support without waiting on every live experiment
How do you improve customer-support agents quickly when every production experiment puts a real customer’s experience at stake? At Nubank, the setting is substantial: Aman Gupta reports 135 million customers across Brazil, Mexico and Colombia, with US expansion still ahead at the time of the talk. Quarterly revenue had crossed five billion in Q1 2026. AI agents handle routine requests end to end, while human experts concentrate on difficult and long-tail cases.
Gupta attributes a 20× faster agent shipping cycle to generating evaluation data in simulation instead of waiting for production data. That is a reported operational result, without a defined timing baseline or aggregation method in the talk. The customer-quality evidence is separate: the opening chart tracks average TNPS, a customer-satisfaction measure, across five production agents. Initially weak results improved over months of work and several quarters of effort, approaching the expert-human benchmark.
Gupta says the displayed results were already stale and that several agents had subsequently exceeded human quality. He also points to a KDD paper. The related Building Customer Support AI Agents at 100M-User Scale documents Nubank’s evaluation-driven framework; its earlier results place most agents below expert-human TNPS, so the later superiority claim remains Gupta’s update rather than a result established by that paper.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An agent example is a trajectory
Reaching those results requires an evaluation system that supports repeated experiments. Evaluation has two inputs: metrics and data. For metrics, Rajpal describes an established, if demanding, process: use LLM-as-a-judge classifiers, align their decisions with human judgments and task rubrics, then improve them through automated optimization and prompt tuning. A judge becomes useful when its scores reflect the behavior the team actually wants.
The harder bottleneck is obtaining the data those judges score. Structured machine-learning examples and single-turn question answering can often be represented as independent rows. A multi-turn agent example is a trajectory: user messages, agent responses, internal tool calls and the state those calls read or modify. Generating one example means making that entire sequence coherent; annotating it means understanding what happened across the sequence. Repeating that work over a useful sample set compounds the cost.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Two ways to obtain data, two different costs
Teams commonly obtain evaluation trajectories through manual authoring or production traces. Each imposes a different constraint:
| Source | What it requires | Experimentation constraint |
|---|---|---|
| Manual authoring | Plan the trajectory, state updates and tool responses | Every call must preserve coherent synthetic state |
| Production traces | Collect conversations from normal operation | Candidate behavior reaches real customers |
Manual authors must anticipate how the conversation unfolds and keep synthetic state consistent across every tool call. Production traces arrive as a by-product of serving customers, but testing changes through those traces means exposing customers to the changes. That makes many parallel production experiments difficult.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Remove the wait for feedback
A conventional release starts with a change to the agent harness—the prompts, tools and surrounding logic that control the language model. Gupta describes implementation taking hours in the best case, followed by days of offline evaluation on hand-curated data. Production A/B testing then introduces another wait: customer feedback forms produce sparse, noisy observations, and establishing a statistically significant improvement can take much longer.
Gupta reports shortening a weeks-long cycle to less than a day, sometimes hours or minutes. Simulation accelerates the evaluation signal, not the implementation work. Harness changes still take hours. What changes is the ability to generate conversations with a simulated user immediately, rather than wait for people to curate new examples or for enough customers to submit feedback. The resulting offline signal helps predict whether a candidate will perform well in production.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Run the real agent inside a simulated environment
For agent evaluation, simulation means exercising the real agent while controlling the customer and the external environment it encounters. Rajpal describes Snowglobe as providing that infrastructure by pointing its SDK at an agent without changing the agent’s code. The current tutorial makes the integration work explicit through wrappers, tool declarations and decorators; the talk’s description should not be read as a universal promise of zero integration code.
The pipeline separates configuration from the conversations it produces:
- Identify tools to mock. Determine which external dependencies the simulator must answer for the agent.
- Configure the scenarios. Supply personas, use cases and the situations the simulation should explore.
- Run conversations. Exercise the real agent over multi-turn interactions, supplying mocked tool responses as needed.
- Judge the trajectories. Apply evaluation judges to obtain per-turn information about agent behavior, then feed it into the existing evaluation pipeline.
The output is a dataset of complete conversations, potentially numbering in the thousands, rather than a collection of isolated prompts. The mocked environment makes those conversations usable for evaluating behavior that depends on tool calls and state.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Maria Souza: a persona with consistent account state
The concrete example is Maria Souza, an explicitly synthetic customer. She is a 34-year-old designer, a first-time credit-card customer, and wants to order a card. The simulator gives her more than a biography: it generates a fake address and credit-card data that remain consistent throughout the agent’s execution. Those facts provide the grounding needed to test whether the agent handles her request correctly.
Maria also has a configured interaction style. Her short, curt, one-line messages follow that persona rather than the verbose, cooperative dialogue a generic simulated user might produce. When the agent calls a tool, the simulator returns valid mocked information identifying Maria and supplying her address for verification. Account data grounds the conversation as well. The test therefore exercises two coupled requirements: the user must behave consistently with her intent and style, and the tools must describe the same customer throughout.
A compact JSON record makes those requirements explicit. It captures the demonstrated scenario and the consistency checks a test fixture needs; the generated address and account values would be shared across the mocked responses that use them.
json
{
"persona": {
"name": "Maria Souza",
"age": 34,
"occupation": "designer",
"first_time_credit_card_customer": true,
"intent": "order a credit card",
"message_style": "curt, one-line messages"
},
"grounding_requirements": {
"identity": "same customer across tool responses",
"address": "same generated address throughout the conversation",
"credit_card": "consistent generated card data",
"account": "consistent generated account data"
}
}
The critical property is coherence across calls: a tool response that supplies an unrelated address would undermine the test even if each individual response looked plausible.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Evaluate real and simulated conversations together
An agent team faces two uncertainties at once: whether the agent is good, and whether the evaluations can tell. Nubank’s improvement loop starts by shipping and observing an agent, then building robust evaluations. Gupta describes investing in automated prompt optimization, including GEPA, to improve those evaluations.
The team then runs simulations and passes both simulated conversations and real production conversations through its evaluations. Those measurements provide the signal for optimizing the agent harness. After verifying that an optimization is good, the team ships again. Repeating this loop supports many experiments across multiple agents: production observation informs the evaluation system, while simulation supplies additional conversations for testing candidate changes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Check whether simulation tracks production
Simulation is useful only if its results say something about real behavior. Nubank compares quality measured by evaluations on simulated conversations with quality measured on production conversations. Gupta reports high correlation between the two, without giving a numerical coefficient.
Gupta reports that 80% of domain-expert labels confirmed that simulation data was usable. The talk does not provide the review sample size or detailed labeling rubric. He describes usefulness for both mature agents and greenfield agents, allowing the team to improve an existing system or bring up a new one before it has accumulated a large production history.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Screen candidates while preserving self-service
Simulation also catches changes that should never reach a live experiment. Gupta describes one regression detected before production and, in a separate agent, an issue that could have reduced the self-service rate. These are different failure modes: a candidate can harm customer experience, or it can make support less efficient by resolving fewer requests without human help.
Gupta reports that one agent’s TNPS doubled through simulation, robust evaluations and systematic improvement work together. No baseline scores are supplied, and the result is attributed to the combined process rather than simulation alone. The team now tries ideas in Snowglobe and waits until it is satisfied with simulation output before launching a candidate.
His illustrative comparison is a team that might otherwise run ten A/B tests in a quarter. It could screen multiple ideas in simulation and move a selected candidate into one live test, avoiding several preliminary experiments. That is a workflow example, not a measured reduction in test count. Production A/B testing remains the next validation step.
Customer satisfaction and self-service must be evaluated together. Higher TNPS can come at the cost of lower self-service if the agent hands more work to humans. Gupta says Nubank improved self-service rather than sacrificing it for satisfaction. Gupta reports a 4% self-service-rate improvement in one case. The talk does not specify whether that means a relative percentage increase or percentage points.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Shortlist models before testing them live
The same infrastructure supports model selection. Nubank places different open-source models inside its agent harnesses, runs them through simulation and evaluates which versions work well for its tasks. Keeping the harness, simulation and evaluation setup available makes it practical to explore more candidates before committing to online experiments.
Gupta reports that simulation saved multiple weeks of effort in screening open-source models. The accompanying slide makes the experiment scale visible: it describes parallel screening of model variants and time saved in online experiments. At the time of the talk, production A/B tests were still running to establish whether the selected open-source models matched frontier models. The demonstrated outcome is a faster shortlist, not established production parity.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Continuous improvement depends on trustworthy signal
Generating evaluation data on demand removes the need to wait for production feedback on every candidate. But faster generation pays off only when the team closes the sim-to-real gap: compare simulation with observed production behavior through offline metrics, online metrics and human review. That comparison establishes when the simulation deserves trust.
For an enterprise agent, continuous improvement rests on two concrete capabilities: metrics aligned with the outcomes that matter, and a reliable way to generate data on which those metrics produce useful signal. Together, they support a repeated loop of feedback, harness changes, verification and release. The destination is an agent that can improve from those signals; the foundation is an evaluation system that makes each proposed improvement worth testing.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Nubank's KDD 2026 paper explains its evaluation-driven workflow and results across five customer-support deployments.
Connect an agent, declare tools, configure mocked responses and run multi-turn simulations. Requires a Snowglobe account and simulation access.
The prompt optimizer uses execution traces and natural-language reflection to propose and select improvements.
Further reading
Official GEPA implementation with installation instructions and optimization examples.
Read the complete timestamped transcript
- 0:00
[on-hold music] Hi, everybody. My name is Shreya. I am the CEO of Snowglobe, and we have with us Aman, who is a principal machine learning engineer at Nu.
- 0:21
And this talk is gonna be about simulation maxxing and how you can ship or, or how Nubank ships, uh, agents twenty X faster using simulations.
- 0:32
Hey, everyone, I'm Aman. Uh, so let me talk about Nubank at a glance. We are the lead, leading digital bank in Latin America. We have a hundred and thirty-five million customers, uh, in Brazil, Mexico, and Colombia, and we are launching in the US real soon.
- 0:47
Uh, our quarterly revenue crossed five billion in Q1 2026. Our NPS, our customer level is very high. And we are the perfect company for using AI agents for customer support, where human experts are fanatical customer care people and AI agents together solve customer issues in a fast, empathetic, and correct manner.
- 1:08
AI handles, uh, a lot of routines end to end. Uh, humans focus on the hardest and long-tail cases, and together, we aim to delight our customers.
- 1:19
So as Shreya said, this talk is only about, uh, one thing really. If you generate your eval data in sim instead of waiting on production data, you can ship agents twenty X faster, and we'll give you evidence for that.
- 1:34
So let's start with the results directly. Uh, uh, so th-this is, you know, the average of TNPS, which is a measure of customer satisfaction for five of our AI agents in production.
- 1:45
And at the beginning, uh, they were not so great, but now, you know, with a few months of, uh, of work and a few quarters worth of effort, we've been able to massively increase the TNPS and customer, uh, love for our AI agents, and many of them are approaching human quality, and this data is a bit stale,
- 2:03
as many of them are exceeding human quality. So we are at the stage where we are actually able to show proof that this actually works in production. Uh, here is a QR code for our KDD paper in case you wanna check it out.
- 2:14
It's gonna be presented, uh, in Korea, uh, in August.
- 2:21
Uh, awesome. So we opened with results, and, you know, it's really about this journey of how do you implement the right systems, uh, for evaluation in order, you know, be able to achieve those results.
- 2:31
So in this talk, we basically split it up into these three sections. The first is why evals are so important and essential, but why they're also the bottleneck from being able to, you know, do a lot of high-throughput experimentation to get the results that Aman was showing earlier.
- 2:44
And then why s-- The second part of this talk is about why simulated data, uh, works as well as collected data and helps you circumvent a lot of this bottleneck that we're gonna talk about.
- 2:54
And then the third part is really digging deep into the systems and the findings that we had by implementing, uh, you know, this framework at scale in Nubank.
- 3:04
Uh, awesome. So evals, we know this. There's, there's like a whole talk track dedicated at this conference to evals. Evals are absolutely critical for building good agents, and evals are really only about two things, right?
- 3:16
There's metrics, and there's data. Uh, metrics, again, I hope you attended many of the amazing talks yesterday on the evals track, but metrics are really... W-while they're challenging, we have a playbook for how to build metrics that are really well aligned with, you know, the rubrics that we care about, right?
- 3:32
Which is you essentially use, um, you know, LLM-as-a-judge style, uh, you know, classifiers, and you align it with human judgment and, and getting human data, and you can iteratively build on it using, you know, auto optimization and auto prompt tuning, uh, techniques.
- 3:46
The thing that's a bottleneck and that still remains very challenging and unsolved is what is the data that you're actually computing these metrics on? And that process is very time-consuming and very expensive, specifically so for agents.
- 4:01
So once again, people have been talking about, you know, uh, if, if you're around, like, machine learning era circa, you know, twenty eighteen, it would be like ML work is eighty-five percent data work, right?
- 4:10
So data has always been challenging, but with agents, the level of sophistication that data requires is just so much more expensive. So here's examples, you know, of what structured ML data look like, uh, and what even early era of AI, uh, data for, you know, chatbots or single-turn QA, which was, you know, much more manageable and tractable,
- 4:29
and you could still think of it as these structured rows. Uh, but now for multi-turn agents, each data point is a trajectory with a lot of internal tool calls that all need state, et cetera, and that becomes very...
- 4:40
Even one data point is expensive to generate and annotate, right? But scaling it up on a sample set becomes even harder.
- 4:49
Um, so how teams primarily get eval data today is two methods. Uh, one is either manual, or the second is production traces, and both of those are painful, but for different reasons, right?
- 5:01
Manual authoring, I mean, this one's obvious. It is so time-consuming, especially the kind of data that I was showing you on the previous slide. You have to hand plan, you know, state updates.
- 5:10
You have to hand plan the trajectory that you wanna take this, uh, you know, agent data point in. And synthetic, uh, the, the state for these data points has to stay consistent across all tool calls, et cetera, that you make, right?
- 5:23
Production traces, in comparison, are almost free. You don't have to pay for them. You're gonna get them anyway. But the cost is that you're testing on real live users every time you're testing it.
- 5:33
So for example, if you wanna run, you know, many parallel experiments at scale, which is often something you wanna do in a machine learning settings, is it becomes very hard to do that in prod.
- 5:46
So for those of you who build agents, you know how difficult building a new agent and maintaining, uh, an existing agent is. So if you wanna change the agent harness, you wanna change the prompt, the tools, anything around the, uh, the LLM that powers your agent, that can take a few hours in, in, in the best case.
- 6:02
But as Shreya mentioned, running offline evals on hand-curated data can take a few days. And then the, the worst part is if you've done an A/B test in production and monitor regressions, see if you get a statistically significant improvement of, of a previous version, that can take forever because customer feedback is, uh, through some kind of a
- 6:21
feedback form, and it can be sparse, it can be noisy, and can take forever to know, am I moving in the right direction or not? So I'm here to tell you that, uh, we have verified in production that, yes, simulation circuit this timeline, short-circuit this timeline.
- 6:36
From a few weeks, you can go to less than a day, sometimes even a few hours, a few minutes.
- 6:41
And, uh, as I mentioned earlier, uh, you know, with simulations, it takes a few hours. Uh, uh, without simulation, it takes a few hours to train the harness and offline evals, and all of this becomes super fast.
- 6:53
Now, with simulation, the agent harness chain still takes a few hours. Running offline evals becomes a lot easier because you have a simulated user to fall back on. You're not waiting on hand-curated data.
- 7:04
You're not waiting on, you know, people to create data for you. And the best part, if you wanna know, uh, that am I doing well in production? Is this version gonna do well?
- 7:14
That can take just a few hours. So this has been a real game changer for us at Nubank.
- 7:20
Um, all right. So we talked about, you know, like, simulation shortening the release cycle, but what is mechanically a simulation? You know, it's existed in robotics, it's existed in, you know, a lot of different domains.
- 7:32
But simulations for agent evals, you know, mean a specific thing, and this is really where Snowglobe enters and, you know, sets up a lot of that core infrastructure for you.
- 7:41
So simulations are essentially, you know, it works by first, like, wrapping your agent, you know, using a, um, a... Like, pointing the, uh, Snowglobe SDK at your agent without requiring any code changes.
- 7:51
And, you know, you can grok what are the tools that you really need and, uh, to mock in order to make the simulation really work. The second input is about how you wanna drive or steer your s- your simulation.
- 8:01
So, you know, who are the personas? What are the use cases? What are the data points that we're really simulating? Once you have those inputs ready, Snowglobe essentially runs the simulation, and on the output, you end up getting, you know, first, just a dataset.
- 8:15
So you get, like, thousands of multi-turn conversations against your real agents. These conversations have, you know, tools, mocked, et cetera, have all of the bells and whistles needed to be actually, you know, useful for evaluating your agent already ready.
- 8:28
And then you run, like, judges on top of it, so that on this dataset you get, you know, per turn information about how your agent is really behaving. And it then, like, pipes directly into, you know, your evaluation pipeline so that you can really get data on demand.
- 8:42
Um, this is an example of what a si- what the, what, what a concrete output of simulation is like, right? So this is, as an example, like, one simulated persona, and then the corresponding conversation or data point for that simulated persona.
- 8:56
So here, for example, this is totally synthetic, a user named Maria Souza. Uh, you know, she wants to order a credit card. This is who she is. She's [REDACTED:age], a designer, first-time credit card customer.
- 9:07
In addition to, you know, this basic information about this synthetic user, we also generate, you know, this essential grounding data. As an example, this fake address, a fake credit card, et cetera, that stays consistent across your agent execution so that, you know, your agent can actually be evaluated against that.
- 9:24
And then you also have things like tone, voice, how do they really interact? And then... Oops. And then when you actually run this persona through the con- through the agent, you end up getting, you know, this, uh, conversation that's consistent with the simulated intent, right?
- 9:39
So you see, for example, that this user has very curt one-line messages in terms of how they interact because this is how the persona was set up. Or that, you know, when the agent wants to...
- 9:49
When the agent runs its tool, when Maria enters the chat, the agent is actually able to get a valid output mocked by the simulator that, you know, is able to identify who the user is, where the address is, the address can be verified, et cetera.
- 10:04
Um, and then finally, all of this is also grounded in, like, account data as well.
- 10:10
So for those of us building real agents, you know how hard things are. Uh, you don't know if your agent is good. You don't know if your evals are good.
- 10:18
You have no idea what's happening, and that was me a few quarters ago. Uh, since the theme of, uh, this year's conference is self-improving agents, so we are also kind of jumping on the bandwagon.
- 10:29
So this is our, uh, self-impr-improvement loop. You ship your agent, you observe, you create robust evals. We have spent a lot of time creating robust evals using automated prompt optimization with algorithms like JEPA.
- 10:41
And then you also do simulation. You run simulation, and you pipe the simulation data and real data through your evals, and that gives you rich signal to then optimize your agent harness.
- 10:53
And once you verify that agent harness, uh, optimization is good, you ship. And this has enabled us to do many, many, many A/B tests for a given agent, and we have many, many such agents across the company.
- 11:04
So this has been a real game changer for us in terms of improving our agents. And the proof, as I already showed you, is that, you know, the quality of our agents is going up, uh, pretty dramatically.
- 11:14
This is some data on how simulation really tracks real production data. So when you run, uh, simulations, you want to compare, is my simulation comparable to production data? So we looked at sim quality, uh, via evals.
- 11:28
So for, uh, you know, quality of, uh, with evals from sim and real data, the correlation is pretty high. And we had human review done, where eighty percent of our domain expert labels confirmed that sims give us usable data, not just for, uh, mature agents, but also for greenfield agents.
- 11:45
So this has been, uh, pretty useful for us in bringing up a new agent from scratch and also taking an existing agent and, and massively improving it.
- 11:55
And as, as we, as I mentioned, you know, simulation is not just about improving, uh, and Shreya also talked about this. We are de-risking a lot of things that could have made to production.
- 12:04
For instance, we caught a regression, uh, with simulation that could have made it to production, but simulation caught it. And at the same time, we also caught, uh, in another agent an issue, uh, which could have lowered our self-service rate, making it less efficient.
- 12:17
And all of this has resulted in pretty large improvements. Uh, for instance, one of our agents, the TNPS, has two xed, uh, thanks to simulation, robust evals, and investing in something super principled rather than, you know, throwing something at the wall and see what sticks.
- 12:33
Um, it's been pretty awesome to see simulation saving us so much time. So now the team uses Snowglobe and tries different ideas, and they're able to short-circuit launching A/B test.
- 12:45
They don't launch until they're happy with sim output. So imagine if you're running ten A/B tests a quarter for your agent, or probably more if you have more data.
- 12:53
Now you can just run a bunch of stuff through sim and launch just one A/B test, which kind of short-circuits launching the first five or six. And at the same time, uh, this, this is often discussed in, uh, customer service circles, that TNPS can come at the cost of self-service rate.
- 13:08
Sometimes there's a trade-off. But I'm happy to report that we are not compromising on self-service rate. With sim, we are also able to pretty dramatically improve SSR across the board.
- 13:18
But in one particular case, we were able to improve it by four percent. All of this makes us a much more efficient company and makes sure that we keep our customers really happy, and we keep our SSR rates and TNPS rates very, very high.
- 13:33
This is one example that I am most excited about. As, uh, you know, you, all of you know, open source models have been on a tear recently. So many of them have come out.
- 13:42
So we've been trying to test various open source models in our agent harnesses and see which ones are the best. And with sim, we have the perfect recipe to just throw a bunch of ideas, open source models at our agent harness and eval and sim setup and see which model versions, uh, you know, really, really work for
- 14:01
us. Uh, this has saved us multiple weeks of effort. I'm probably underselling it. It's, it's been, it's been pretty awesome. And, uh, we have A/B test running, uh, as I speak, uh, figuring out are these open source models as good as, you know, uh, the, the frontier models.
- 14:17
So sim is, is, has been super, super helpful in helping us figure out, uh, kind of, you know, uh, spreading our cards, uh, a bit.
- 14:26
Um, awesome. So, um, the core three takeaways from this talk, right, is about, um, where eval is today and how you can really remove a lot of bottlenecks to it.
- 14:36
So we lied [laughs] when we said earlier that there's just one thing you should take away from it. That one thing is still essential, but there's a, a few key downstream things that you can unlock if you know you adopt it, which is, the first is if you generate your evaluation data in simulation rather than solely relying on
- 14:52
production to get signal on how, you know, different agents are performing, uh, you'll be able to undercut or you'll be able to short-circuit a lot of the, uh, bottleneck in, in releasing, you know, uh, versions of your agents much faster.
- 15:04
The second is, in order for any of these gains to really be unlocked, uh, you know, you really need to close out the sim-to-real gap. So you need to s- you know, set up like offline, online human review kind of metrics to really understand how sim performs vis-a-vis real production da-data that you've seen, uh, so that you,
- 15:22
you, you are able to kind of like trust the results of these simulations. Um, and the third is, again, there's so much excitement around, you know, like auto research, self-improving agents, RSI, et cetera.
- 15:31
Uh, in an enterprise setting when you're building an agent, it really does come down to two things, data and metrics. If you have aligned metrics that are able to really catch the signals you care about, and you have a reliable way of generating data that th-those metrics can give you signal on, it's then very easy to put
- 15:50
together a loop of an agent that, you know, continuously improves itself from, like, feedback it receives from all of these places, uh, which, you know, again, is, like, where the future of this field is heading.
- 16:01
Um, awesome. That's, that's us. Uh, thank you for coming for the talk. Uh, there's a few, like, contact links and details for us, you know, if you guys wanna get in touch, and otherwise we'll be around here if you guys wanna ask us any questions. [outro music]