AI Engineer World's Fair 2025
How agents will unlock the $500B promise of AI
Read the talk
Getting agents from a working loop into production
A small tool-calling loop can power an agent, but enterprise value depends on permissions, evaluation, observability, and choosing which systems deserve custom engineering.
From a talk by Donald Hruska
Before you start: Basic familiarity with JavaScript functions, API calls, and language models will help with the agent-loop example.
Where does the infrastructure investment become useful work?
Why are enterprises still experimenting with chatbots when AI infrastructure investment is already enormous? Donald Hruska opens with that mismatch, citing half a trillion dollars spent on infrastructure while many large companies remain at toy chatbots and code generation. At Retool, where he leads new product teams, the starting point is internal applications and integrations with AI providers. The newly released Retool Agents extends that work toward agents that connect to production systems with guardrails. The missing step is turning model capability into dependable business operations.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Coding shows what changes when models can act
The revenue figures establish the launch-era context. Citing Reuters, Hruska reports that Anthropic's annualized revenue rose from $1 billion in December to $2 billion at the end of March and $3 billion at the end of May, tripling in five months. He contrasts that run rate with OpenAI's projected total 2025 revenue of $12 billion, more than three times the previous year's revenue. These are different measures—an annualized run rate and a full-year forecast—and Hruska attributes much of the growth to enterprise spending.
Coding is where he already sees workflows changing. His engineers use Cursor or Windsurf, spending more of their effort on prompting and code review while models handle everyday implementation. He describes the productivity improvement qualitatively. The same concentration appears in his snapshot of OpenRouter: a unified API exposing hundreds of models, with a top-app list dominated by code generation.
Providers are investing in that demand. On SWE-bench Verified, Hruska reports an approximately 21-percentage-point gain for GPT-4.1 over GPT-4o, followed by roughly nine more points for Gemini 2.5 Pro over GPT-4.1. SWE-bench Verified measures repository issue resolution, and these historical results depend on the surrounding prompts and tools: OpenAI excluded tasks that could not run on its infrastructure, while Google's result used a custom agent setup. The figures show the direction of investment, not a controlled comparison under a shared harness.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From an idea to an agent
Hruska invokes Rick Rubin's description on the Andreessen Horowitz podcast: “Vibe coding is the punk rock of software.” The analogy is about access. Just as punk's simplicity let someone with something to say make a song, coding agents let someone with an idea begin making software. A rough request to Cursor or Windsurf starts a sequence of deliberation, actions, and code changes. That differs from completing text or copying a ChatGPT answer into an editor: the system participates in carrying out the task.
The next question is whether that pattern can extend to other business problems. Code has an advantage: it has defined semantics and can be tested, giving the agent and its operator ways to check a result. General-purpose business agents need their own ways to validate actions and outcomes. The execution pattern transfers more readily than the assurance that the work is correct.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The agent is an execution loop
Hruska estimates that a basic agent can fit in about 100 lines of JavaScript or Python. His example uses ReAct: interleave reasoning and action until the model reaches a final answer. Tools are functions, whether they call an external service or execute application code. The resulting agent is an LLM inside a loop that can read, decide, call tools, and check the feedback.
The demonstration starts with a calculator tool, its calculation function, and a system prompt establishing the ReAct behavior. The tool definition tells the model what operation is available; the function is what the application actually executes. Keeping those roles separate matters: requesting a calculation does not itself perform one.
The control flow is a bounded for loop:
- Ask the model for its next action or final answer.
- If it requests a tool, execute that function and append the result to the conversation.
- Let the model use that feedback on its next turn.
- Return a final answer when one arrives, or stop when the iteration budget is exhausted.
This JavaScript version makes that application-side contract explicit. nextStep is the model adapter: it receives the conversation and tool definitions, then returns either a tool request or a final answer. For an input such as What is 17 × 23?, the calculator can return 391 as feedback for the model's next turn.
javascript
const tools = {
calculator: {
description: "Multiply two finite numbers",
parameters: {
type: "object",
properties: {
a: { type: "number" },
b: { type: "number" }
},
required: ["a", "b"],
additionalProperties: false
}
}
};
function calculator({ a, b }) {
if (!Number.isFinite(a) || !Number.isFinite(b)) {
throw new Error("Expected two finite numbers");
}
const result = a * b;
if (!Number.isFinite(result)) {
throw new Error("Calculation overflow");
}
return result;
}
export async function runAgent(input, nextStep, maxSteps = 8) {
const messages = [
{
role: "system",
content: "Use tools when needed. Check their results, then answer."
},
{ role: "user", content: input }
];
for (let step = 0; step < maxSteps; step++) {
const decision = await nextStep({ messages, tools });
if (decision.type === "final") {
return decision.answer;
}
if (decision.type !== "tool" || decision.name !== "calculator") {
throw new Error("Unsupported action");
}
messages.push({ role: "assistant", content: decision });
const result = calculator(decision.arguments);
messages.push({
role: "tool",
name: decision.name,
content: String(result)
});
}
throw new Error("Agent reached its iteration limit");
}
The iteration limit prevents the agent from repeatedly thinking and acting without an end, accumulating model costs. Tool results re-enter the conversation; the application then detects and returns the model's final answer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What the working prototype leaves out
A working loop is only the beginning of deployment, much as a quickly generated web application still needs production engineering. Enterprise requirements include single sign-on, role-based access control, secure service integrations, audit logs, SOC 2 compliance, secrets management through systems such as AWS Secrets Manager, and internationalization. Hruska cites reporting from The Information about vulnerabilities shipped through insufficiently reviewed AI-generated code. These surrounding systems cannot be treated as incidental details just because generating the application became easier.
Agents also introduce operational risks within the loop itself. Outputs can be fabricated, inaccurate, or unpredictable. Access must be constrained to the resources the agent should use, and token consumption needs limits. Evals are a safeguard for more predictable behavior, not a way to make a probabilistic model mathematically deterministic. They help establish whether the agent behaves acceptably across the cases the business cares about.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Four ways to deliver an agent
The implementation choice determines how much of that surrounding system your team must own. Hruska groups the options into four categories:
| Approach | Control and flexibility | Engineering burden |
|---|---|---|
| From scratch | Maximum ownership; purpose-built behavior | High, including ancillary systems |
| Framework, such as LangGraph | Substantial control within a framework | Medium |
| Agent platform, such as Retool Agents | Opinionated defaults; platform dependence | Lower effort to production |
| Vertical agent | Tuned for one use case; little flexibility beyond it | Turnkey within its specialty |
Building from scratch can include fine-tuning and dedicated AI or ML engineers. A framework preserves substantial configurability, including choices about memory, while tying the implementation to its abstractions. A platform takes on hosting, service connectors, and fleet observability, which can suit the long tail of business workflows. A vertical offering goes further by concentrating on one task that it can perform particularly well.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Spend engineering effort where ownership matters
The decision starts with the value of controlling the implementation:
- Core product or competitive advantage: Hruska favors building, because the agent's behavior is part of what differentiates the business.
- Sensitive data, regulation, or hard SLAs: Examine both approaches against the actual requirements; neither route automatically satisfies them.
- Commodity workflow with a short deadline: Buying can make more sense when the business needs a result in days rather than quarters.
Then assess the operational risk. Is the best use of the team's time debugging business logic, or diagnosing a broken OAuth integration at two in the morning? Owning an implementation also means owning the failure modes around it.
For a managed platform, inspect what is included rather than assuming the platform removes every integration task. Check whether Salesforce, Databricks, and Snowflake connections are available out of the box. Then examine permissioning, compliance, audit trails, observability, and evals. A missing capability can mean custom engineering or another vendor to purchase and operate. Compare token costs, infrastructure costs, and engineering costs together.
Once agents are deployed, visibility needs two levels. At the fleet level, track token usage, estimated cost, and runtime information. From there, drill into a specific agent and an individual run to inspect whether it did what you expected. Aggregate spending tells you that something changed; a run-level view lets you investigate the behavior behind that change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A few custom agents, a long tail of managed workflows
This can produce a mixed portfolio, much like ordinary business software. Hruska uses Stripe as an analogy: its core billing logic and critical customer applications warrant custom development, while external platforms serve internal needs. He describes Stripe using React for much of its customer-facing software and Retool for much of its internal tooling. His expectation is that businesses will similarly maintain a few purpose-built agents alongside many platform-hosted business agents.
Cursor makes the distinction especially clear. Its coding agent is its product, so control, ownership, iteration speed, and attention to implementation details are central to the business. But as the company grows, chargeback disputes and customer-support requests could become substantial operational workloads. Hruska offers those as hypothetical candidates for an agent platform, not as examples of Cursor deployments already in use.
Hruska describes working with AWS on automating mundane business processes, then points to existing Retool customers. Hruska reports that ClickUp saved over $200,000 in vendor costs and hundreds of thousands of dollars in additional headcount through its Retool AI tooling. These are customer savings claims, rather than a benchmark of the newly launched agent product.
Hruska reports Descript's estimate that its 50 apps save hundreds of work hours weekly. He also cites Retool's announcement that customers had automated over 100 million cumulative hours of work. That broader Retool milestone predates the impact of the newly launched Agents product; it is not an Agents-only result.
The intended benefit is more capacity for creative and strategic work. Hruska compares the concern about AI to fears that the printing press would undermine traditional knowledge: wider access to information instead expanded what people could do. He expects agents to enhance teams' capabilities and ultimately increase global GDP. That is the economic ambition behind the automation examples, rather than a measured outcome of them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Cheaper inference sharpens the engineering question
Hruska cites Mary Meeker's AI Trends Report for a 99.7% decline in cost per token from 2022 to 2024. The talk does not specify the model, workload, or quality baseline behind that figure. His economic observation is that provider revenue can rise rapidly while the marginal cost of inference falls. At the time of the talk, Hruska says Retool's cheapest agent cost $3 per hour. He expects that price to keep declining.
He also cites the Meeker report for an elevenfold increase in Google searches for AI agents over 16 months. But growing interest does not answer the deployment question. The useful question is where engineers can create the most value, and which tool fits that work—not how to find one system that puts an entire business on autopilot.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What Retool had decided—and what was still ahead
The first audience question tests the build-versus-buy framework against Retool itself: which core systems does it build by hand, and where does it use its own agents? Hruska says Retool already builds much of its internal software on its platform and prioritizes using its own product. But Agents had launched only the previous week, so the split between custom agents and platform implementations remained undecided. He offers no concrete core-agent example. Retool's company-specific policy is to use the platform wherever possible, then investigate and build missing capabilities when something cannot be done.
A second question, from someone building government and NGO applications, asks about on-premises deployment. Despite an initial affirmative answer, Hruska clarifies that Retool Agents launched cloud-only. At this June 2025 talk, he expected on-premises support within one or two weeks, possibly three, and eventual support for air-gapped customers without a firm date. Those were roadmap commitments, not capabilities already available at launch—a consequential distinction for teams whose deployment environment determines whether they can adopt the platform at all.
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
The original research on agents that interleave reasoning with actions and environmental feedback.
Retool's May 2025 announcement connects its Agents launch with its reported automation milestone.
Further reading
OpenAI's April 2025 benchmark results, including SWE-bench Verified scores and evaluation limitations.
Google's March 2025 model announcement includes its SWE-bench Verified result using a custom agent setup.
A customer account of AI applications for go-to-market operations, including order-form approval and avoided software costs.
A customer account of more than 50 internal applications spanning operational tools and AI evaluation.
Read the complete timestamped transcript
- 0:00
[upbeat music] Yes, my name's Donald.
- 0:16
I lead the new product teams at Retool. Uh, Retool made its name in the earlier days working on internal tools, making it really easy for any business out there to build internal applications, and we've been making it easy to connect with AI providers for a couple years now.
- 0:33
But we're now breaking into agentic AI with the release of Retool Agents, which we announced last week and made available to our customers. So, half a trillion dollars has been spent on AI infrastructure, and yet most large companies are really just still stuck with toy chatbots and messing around with code generation.
- 0:55
So, let's talk about why that changes this year with enterprises finally being able to build agents with guardrails that plug into real production systems.
- 1:06
Reuters shared last week that Anthropic hit, at the end of May, so a couple days ago, $3 billion in annualized revenue. That's up from $2 billion at the end of March and $1 billion in December.
- 1:19
So, that's 3X-ing their annualized revenue growth in five months, which is some staggering growth. That's not to mention OpenAI is slated to end 2025 at $12 billion in revenue, over 3X where they were at at the end of last year.
- 1:34
These growth rates are massive, and this largely is fueled by enterprise AI spend.
- 1:39
And coding is growing. Teams love using Cursor and Windsurf, including my own. I think every engineer on my team is using one of these tools, and engineers are now becoming experts in prompting and in code review and letting LLMs do the heavy lifting of a lot of day-to-day coding.
- 1:58
Their workflows really are just completely transformed right now, and their productivity is through the roof.
- 2:04
If you look at OpenRouter, which gives access to a unified API that exposes hundreds of AI models, their top apps list is really dominated by code generation use cases, as you can see here.
- 2:20
And the LLM providers are taking note. SWE-bench Verified is a benchmark that measures an AI model's ability to perform real-world coding tasks. If you look at GPT-4.1, it's up 21 percentage points from GPT-4o, really showing the investment that OpenAI is, is putting behind making their models work really well for coding use cases.
- 2:44
And Gemini 2.5 Pro is up another nine percentage points from GPT-4.1. Devs are raving about Gemini 2.5 Pro. I think nearly every developer I know using Cursor is talking about how well it works.
- 2:57
And finally, the term vibe coding has firmly planted itself in the zeitgeist. Last week on the Andreessen Horowitz podcast, Rick Rubin, the legendary music producer, said, "Vibe coding is the punk rock of software," talking about in the same way that punk rock, with its simplicity, made it really easy for anyone who had something to say to go
- 3:18
make a song, vibe coding is doing that now for anyone with an idea.
- 3:25
And vibe coding is so powerful because you just tell Cursor or Windsurf kind of the gist of what you want, and it goes and it thinks and it thinks and it acts and it writes that code for you.
- 3:35
And this is a lot different than basic text completions or copying code from ChatGPT into your code editor. This is agentic AI.
- 3:46
So, vibe coding needs agents to work, but why should we stop with this idea at just code? Code is testable. It has semantics. It's easy to validate and understand if the LLM is generating it correctly, but could we apply the same idea to any problem in our business?
- 4:05
And to do that, we would need general purpose agents.
- 4:10
And building the agent, believe it or not, I would say is actually the easy part. You could build a really basic agent in about 100 lines of JavaScript or Python.
- 4:18
The start of one right here. And what I'm talking about here is using the ReAct framework, which is basically a, a, a framework for building agents that instructs the agent to reason, act, reason, act, until it determines that it's come up with a final answer.
- 4:34
And the agent has access to tools, which are basically a set of functions. These could be external services it's calling, code in your code base that it's running. So effectively, an agent is just an LLM wrapped in an execution loop that can read, decide, call tools, and self-verify.
- 4:54
So here you see, like I said, I have the start of a basic agent. I'm defining a set of tools for that agent. In this case, it has one.
- 5:00
It's a calculator, as well as a function to actually calculate something.
- 5:05
I initialize a system prompt here for the agent using the ReAct framework.
- 5:13
And I know there's a lot here, but basically what this is, is I'm defining that agent loop. It's a for loop, like I'm sure many of us learned in CS101, and a number of maximum iterations so our agent can't get stuck in a loop thinking forever, burning up our, our OpenAI costs.
- 5:28
The LLM tells our logic when it decides that a tool needs to be invoked. We call that tool, we pass the result back to the LLM, and it decides when a final answer has been reached.
- 5:40
We detect that, and we spit it back out to the user.
- 5:44
So, building agents is easy, right? We can all just go build agents at our company and problem solved, right? Not so fast. Just like vibe coding, agents are tough to get into production in the same way that, say, a web app that you build in Cursor really qu- really quickly is tough to get into production.
- 6:01
You have a lot of things at a real enterprise company that you're probably concerned with here, things like single sign-on, role-based access control, integrating with external services in a secure way.
- 6:13
Maybe you care about audit logs, maybe you care about compliance like SOC 2, maybe you use AWS Secrets Manager, maybe you are a multinational corporation, it needs to be internationalized.
- 6:22
The list goes on, and you can't always safely vibe code these things. The Information released an article last week on the high risks of using vibe-coded logic in production, and a couple real-world use cases of vulnerabilities that were, uh, put into production by developers not carefully vetting AI-generated code.
- 6:47
We've also learned firsthand at Retool that there's a lot that you really have to get right when you build agents. Models can hallucinate or give you unpredictable results or inaccurate results, made-up results.
- 6:59
You have to m-- you have to be mindful of security. You have to be conscious of the things that you're giving your agent access to.
- 7:08
You have to be cognizant of cost overruns. It can be really, uh, easy to accidentally burn up a bunch of tokens.
- 7:15
And overall, evals are really an important safeguard here in making your non-deterministic agent as deterministic as you can.
- 7:26
So how do you solve that problem? I would kind of group the options into approximately four buckets. The first is to build your agent from scratch. You write every line of code by hand.
- 7:37
Maybe you're fine-tuning LLMs, maybe you have AI, ML engineers on your team. You have full control, but it's a high lift. You're building all those ancillary pieces, but what you get is something purpose-built that's not outsourced.
- 7:51
You have maximal control. Then there's more of a middle ground using a, a framework like, say, LangGraph. You still have a high level of control, for example, different memory modes.
- 8:00
It's a medium lift, but a pretty flexible framework that you're tied to.
- 8:04
There's agent platforms like Retool Agents, where you would get opinionated defaults, low lift to production. Of course, you're tied to the platform, but it's useful for that long tail of business agents.
- 8:15
The hosting is abstracted for you, connectors to external services come out of the box, observability for your fleet.
- 8:22
Or the fourth bucket is the verticalized agent bucket. These are offerings where the agent is really dialed in for one use case. It can do one thing really well, but you really have minimal flexibility to kind of go beyond that one core use case.
- 8:39
So how do you decide? Everyone wants agents, but you have to be really thoughtful about where you spend those precious engineering cycles. You know, when should you hand roll an agent versus when would you wanna consider a managed agent platform?
- 8:50
Ultimately, I would say the decision boils down to an engineering decision of trade-offs. If you're working on something that's part of your core product or gives your business its competitive edge, then you probably wanna build it yourself.
- 9:04
If you are working with, say, regulated or sensitive data, maybe you have hard SLAs of some sort, you might wanna consider both options. But if you're building some kind of commodity workflow, and you need it in days and not quarters, then I would probably buy it.
- 9:20
I would also, as a part of this, do a risk assessment of either option. You know, do you want your engineers debugging business logic, or do you want them up at two AM trying to figure out why OAuth isn't working right?
- 9:32
As a part of this decision, if you go the managed platform route, I would evaluate the breadth of connectors that the, uh, offering connects to. You know, are you pulling data from Salesforce and Databricks and Snowflake?
- 9:44
Is that gonna come out of the box, or do you have to build that?
- 9:48
Is permissioning built in? Is it compliant? Does it come with audit trails? Is observability built in? Are evals built in, or is that another vendor that you're going to have to go now pay for?
- 10:00
And I think overall, on the build versus buy decision, I would think about the token costs, the infrastructure costs, and the engineering costs that come into play for building or buying.
- 10:13
On observability, this is how we think about it at Retool for agents. It's important overall, I would say, with whatever platform you go with to understand token usage, estimated costs, and runtime information for your agent.
- 10:26
And with whatever platform you choose, you should also be able to dial into any specific agent and agent run to make sure that your fleet of agents is doing what you would expect it to.
- 10:41
So looking ahead, there's an analogy here, I would say, to how businesses today think about building versus buying software. Stripe, for example, is always going to have its core billing logic and its critical user-facing apps built by hand.
- 10:57
But Stripe uses external platforms for that long tail of software. And I would expect the same for agents. I would expect businesses, as time goes on, to have a few hand-built agents, purpose-built for certain use cases, and then a long tail for business use cases hosted on some kind of platform.
- 11:16
To look again at Stripe, they use ReAct for much of their critical customer-facing software, and they use Retool for much of their internal tooling.
- 11:25
Or you could say, look at Cursor. Cursor would never use a managed platform for their core product. You know, this is their core product that we're talking about. It would be slow to use a different provider.
- 11:35
They wouldn't own it. They really need as much control as possible, and they have a lot of really smart engineers kind of poring over every edge of that thing.
- 11:42
But you could imagine that as Cursor, the company grows, which they are, they may eventually be dealing with a high volume of, say, fighting chargebacks against their billing provider, uh, many customer support requests.
- 11:55
I could imagine Cursor, their company, moving towards using an agent platform as they get quite large.
- 12:03
I've been working with closely with customers like AWS on initiatives to automate mundane business processes with AI, and I've, I've really seen the impact here. Another Retool customer, ClickUp, built their AI tooling on Retool.
- 12:15
They saved over $200,000 in vendor costs and hundreds of thousands of dollars on additional headcount.
- 12:21
Descript estimated that they're saving hundreds of hours of work weekly with the 50 apps they built. And in fact, we recently announced at Retool on the topic of work automation that our customers have automated over 100 million hours of work to date.
- 12:36
By doing this, we're freeing human potential for more creative and strategic endeavors. You know, people thought the printing press was gonna lead to the decline of traditional knowledge, and in fact, it democratized the access of information.
- 12:48
And I really do think that AI and agents are going to enable businesses to enhance the capabilities of their people and of their teams, and this is just gonna unlock limitless potential, and I would say overall, just increase the GDP of the world.
- 13:05
Last week, Mary Meeker's AI Trends Report came out, and it was reported that inference cost is dropping dramatically. From 2022 to 2024, cost per token dropped 99.7%. And spend is huge, as we saw with Anthropic's, uh, three X-ing their annualized revenue in five months and OpenAI's $12 billion by the end of this year, while the marginal cost,
- 13:30
as we can see here, is completely bottoming out.
- 13:33
For example, at Retool, for our cheapest agent, we charge $3 an hour. You can imagine that cost is going to keep dropping.
- 13:40
The Meeker report also showed that Google searches for AI agents 11X'd in the last 16 months, so you can expect to keep hearing about agents. So in closing, I would say the question isn't, what is the single golden ticket way to put everything in my business on autopilot?
- 13:56
It's, where can I help my engineers create the most leverage, and what's the right tool for the job? Thank you. [audience applauding]
- 14:08
I think we have two, three minutes for questions.
- 14:16
Yeah.
- 14:18
Uh, first of all, thank you for the talk.
- 14:20
Yeah.
- 14:20
Uh, it was really good. Um, I was curious, like this essentially paradigm of, uh, for core, like, for core business logic, uh, build your own tools, uh, whereas, you know, for more ancillary stuff, look to things like Retool Agents.
- 14:34
Was this like a philosophy that you guys had, uh, basically figured out, like, while working on this stuff internally to Retool? And if so, like, what's an example of, like, Retool's core internal logic that they wanna build themselves, and what's something that they might look to use their own product for, their own agent for?
- 14:52
Mm. That's a really good question. I think, like, this is, like, generally a, a philosophy at Retool we have just, you know, uh, we, we build a lot of our own internal software on, on Retool.
- 15:01
Of course, we're, like, dogfooding as much as we can. Um,
- 15:05
in terms of your second question, I would say it's a great question. Agents released last week, like I said, so we're building as much as we can on it.
- 15:12
I w- I think it remains to be seen what we'll do on the platform and what we'll build by hand. I think just our philosophy is to do as much as we possibly can using our own platform, and if we can't do something, then we should go figure out why and go build it.
- 15:24
And so I think for us specifically, I would say we're just gonna use the platform itself for everything we possibly can.
- 15:31
Thanks for the question.
- 15:34
Hey, Donald. Lance from IOX-A.
- 15:36
Hey.
- 15:36
So we build, uh, applications for government and NGO and stuff, and I'm curious about your AI agents. Do you allow your on-prem, uh, offering to include the AI agents as well?
- 15:47
We do. We do. We, uh... So we launch cloud only, but on-prem support is coming in the next, like, week or two, maybe three. Um, so yes, it is definitely gonna be supported on-prem, and also eventually for our air ga- air, excuse me, air-gapped customers as well.
- 16:01
Awesome. Thanks.
- 16:01
Thank you. Any other questions? Cool. Well, thank you everyone. [audience applauding] [upbeat music]