← All AI Engineer talks

AI Engineer World's Fair 2025

The rise of the agentic economy on the shoulders of MCP

Jan Curn· Apify18:08

Read the talk

The rise of the agentic economy on the shoulders of MCP

Dynamic tool discovery lets agents find new capabilities, but acquiring services also requires credentials and payment. Apify’s marketplace shows how those pieces can fit together.

From a talk by Jan Curn

Before you start: Familiarity with API credentials, language-model tool calling, and basic web APIs will help you follow the examples.

How does intelligence emerge from connected parts?

How does intelligence emerge in biological systems? Start with an individual neuron. It grows connections, communicates with other cells, and obtains the nutrients it needs. Zoom out, and the collective behavior becomes something much richer than the activity of an isolated cell. Jan Curn opens with this picture of intelligence emerging from smaller units pursuing their own interests.

Markets provide the next analogy: participants establish relationships, exchange information, and respond to one another. Companies offer a more familiar—and deliberately provocative—version: intelligence emerges through Slack, as employees interact and coordinate. Neither analogy guarantees wise decisions, but both shift attention from the capability of one participant to the behavior of a connected system.

Applied to computing, the question becomes whether general intelligence could emerge from multiple models pursuing goals and interacting, rather than from increasing model size alone. That is Curn’s hypothesis, not a demonstrated route to AGI. He proposes Model Context Protocol (MCP) as connective infrastructure for an agentic mesh. Introducing himself as Apify’s founder, he describes an economy in which agents find counterparties and purchase services from businesses, tools, and other agents: business-to-agent and agent-to-agent transactions.

Question beside a network of Agent and Tool boxes connected by arrows, with database and web icons.
How will general intelligence emerge in computing systems?
0:160:39
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:16 · section reference included

Package software so other systems can buy and call it

Curn reports approximately 5,000 Actors in Apify’s marketplace at the time of the talk. Its origins are in web scraping: extracting social media and search data, supplying RAG pipelines, and finding leads. The catalog also includes data processing tools. Some Actors come from Apify; others come from community developers who earn money from their use.

An Actor is a self-contained, Docker-based piece of software with defined inputs and outputs. That boundary makes it a distributable product as well as a callable program. Google Maps Scraper illustrates the packaging: a listing combines the tool with its creator, description, statistics, and pricing. Curn says it extracts more data than the Google Places API provides; the talk does not establish a field-by-field comparison.

Google Maps Scraper listing with a Try for free button, developer attribution, description, rating, Pay per event pricing label, and usage statistics.
Google Maps Scraper in the Actor marketplace.

The same input/output contract supports several integration surfaces: TypeScript and Python SDKs, OpenAPI access, and a CLI for terminal use. Make, Zapier, Clay, and other automation platforms can also call Actors. The underlying software unit stays the same while the calling environment changes.

3:093:22
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:09 · section reference included

Discover capabilities when the workflow needs them

The Apify MCP server adds an agent-facing interface to that catalog. An agent connects using an Apify account and API key, then accesses Actors through the server. The crucial capability is dynamic tool discovery: the client can learn about tools during a workflow instead of starting with every callable definition already in context. Curn describes VS Code and Claude Desktop support as newly available at the time of the recording.

There are two layers here. Apify supplies catalog search and the ability to add Actors to the available tool set. MCP supplies the protocol for listing and invoking tools; its March 2025 tools specification also defines optional notifications when that list changes. A tool-list request has this JSON-RPC form:

json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Listing the server’s exposed tools is different from searching a marketplace for a suitable Actor. The latter is application behavior built on top of the protocol.

Expose tools as needed, rather than loading the entire catalog into context. Curn’s objection to his OpenAPI approach is the size and selection difficulty of presenting thousands of definitions at once. More available tools also create more opportunities to choose incorrectly. His claimed advantage for MCP is the ability to change the available set during the workflow—not a claim that OpenAPI cannot describe those services.

4:595:24
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:59 · section reference included

Finding a server does not grant access

Curn points to a Google Trends comparison with OpenAPI and Google’s A2A as evidence of MCP’s momentum. Search interest is not protocol adoption share, but the proliferation of directories supplies another sign of activity: Mastra even published a registry of MCP registries.

Anthropic’s own registry was still being developed in this account. Curn also references A2A discovery at /.well-known/agent.json, which he characterizes as DNS-based. These are historical examples of how an agent might locate a counterpart. They lead to a separate question: once an agent finds a server, can it actually use the service?

6:316:47
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:31 · section reference included

Credentials still determine the agent’s reach

Curn describes Zapier MCP as offering access to roughly 5,000 apps, while still requiring users to connect the individual services. A GitHub or Slack integration cannot supply access to the user’s account merely because a callable interface exists. The user must facilitate authorization.

That leaves the developer deciding which counterparties the agent can reach before the workflow begins. Calling an authorized tool and acquiring a new service are different capabilities. A person can find a provider and purchase its service; an agent constrained to prearranged credentials cannot do the equivalent independently. Curn connects that limitation back to his opening hypothesis: richer collective behavior will require agents that can acquire services, not just invoke the tools humans have already connected.

7:418:00
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:41 · section reference included

Two ways to acquire services—and their obstacles

The first approach is to let agents register with each service themselves. Give the agent an email address and a credit card, then have it work through subscription forms, CAPTCHAs, and account creation. Phone verification and requirements for a real person behind an account make this more than a browser-automation problem.

The second approach is shared identity and payment infrastructure: fund an account that agents can use to identify themselves and buy services. Curn names Vertify, Coinbase’s x402, Stripe, Mastercard, and Visa in this discussion. These are not equivalent architectures; x402 is an open HTTP payment protocol using stablecoins, rather than a universal centralized identity provider.

ApproachAgent needsMain obstacle
Register with every serviceSignup details and payment methodHuman-oriented onboarding
Shared identity and paymentsFunded identity accepted by providersAdoption on both sides

A payment network needs providers willing to accept it and customers who want to spend through it. Curn invokes PayPal’s spending to acquire a market and the difficulty of establishing credit-card acceptance as analogies. The underlying problem is that buyers need accepting sellers, while sellers need buyers.

9:079:21
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:07 · section reference included

Put upstream accounts behind a marketplace

The third approach is a centralized marketplace of MCP services. The agent uses one marketplace account and authentication token. A tool publisher supplies the upstream service account, credentials, and payment method, then sets a price for using the Actor. The agent purchases the packaged capability without opening its own account with every underlying provider.

The Actor can execute its own code, wrap an external API, or expose an external MCP server. In the nested case, a parent server makes the downstream server’s tools available through its own interface. The request travels from agent to marketplace to Actor to upstream service; the user pays for Actor usage, the developer receives revenue, and the developer pays the upstream bill. Curn proposes that publishers can add these wrappers without the provider’s participation. Technical independence does not, by itself, establish permission or contractual compliance.

Diagram routes an AI Agent through mcp.apify.com to Actor A and Actor B, with money symbols on the branches. Actor B connects to Service or MCP server X through an API key arrow.
An open marketplace connects an AI agent to Actors and an external service.
10:2810:47
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:28 · section reference included

Find the conference venue through an Actor

The demonstration is prerecorded because the venue’s internet connection is unreliable. It starts in Claude Desktop with the Apify MCP server connected and 18 tools available. The request asks for the venue of AI Engineer World’s Fair in San Francisco, preferably using Apify Actors.

The workflow proceeds through three operations:

  1. Search the Actor catalog for a tool that can answer the question.
  2. Select RAG Web Browser, which combines Google search with retrieval of page content.
  3. Submit the venue query and parse the resulting page.

The recorded result identifies the San Francisco Marriott Marquis. This first task establishes the basic path from a natural-language question through tool discovery to retrieved information.

11:5112:03
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:51 · section reference included

Add a Twitter tool during the conversation

The next task needs a Twitter scraper that is absent from the current context. Claude first searches the store for a suitable Actor, then calls add-actor to add the new tool. Finding a tool and making its definition available to the model are separate steps. A catalog result alone does not give the client a refreshed callable interface.

The recorded client exposes that distinction: Curn must disable and re-enable a tool to refresh Claude Desktop’s tool list. This is a workaround observed in that historical demonstration, not current setup guidance. Once refreshed, Claude calls the newly available Actor on Apify to retrieve the conference’s latest tweet. The result concerns that morning’s workshops. Curn suggests the Twitter handle probably came from the website, but does not establish its source.

12:4312:54
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:43 · section reference included

Reach Browserbase through a published wrapper

The final task crosses into an external provider’s service. Curn says Apify created a Browserbase account, supplied its own API token, and published a wrapper for Browserbase’s MCP server. Browserbase, he says, neither published the Actor nor participated in its setup. The important architectural change is that the upstream account belongs to the wrapper’s publisher, while the agent continues to enter through Apify.

Claude is asked to use Browserbase to fill the conference website’s email subscription form with Curn’s email address. The call passes through the published Actor to Browserbase MCP, which performs the browser interaction. Curn presents this as a way to expand the marketplace without arranging a bespoke integration with each provider.

The browser task takes time: the agent evaluates screenshots and searches for the input field before completing the form. Curn advances through part of the recording and reports that the email subscription succeeded. The demonstration therefore connects three previously separate capabilities—discovering a tool, accessing a publisher-funded upstream service, and acting on a website—through the marketplace interface. Clients need tool-discovery support to use the ecosystem in this way.

13:3613:52
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:36 · section reference included

Publication brings distribution and billing

For a developer, publishing an Actor combines monetization with distribution: the tool becomes accessible to AI clients already connected to Apify and to its existing integration ecosystem. Curn reports more than $250,000 paid to creators in the month preceding the talk.

He also reports overall Actor revenue above $1.5 million per month and one million monthly visitors across the ecosystem at talk time. Creator payouts, Actor revenue, and visitor counts measure different things; none is presented as MCP-only revenue. The invitation is to publish tools or agents into that existing marketplace, rather than build a separate acquisition and billing channel for each one.

15:4716:08
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:47 · section reference included

Discovery leaves reliability and trust unresolved

Even a fixed-tool agent workflow can be difficult to make reliable. Letting the agent discover new tools introduces another source of variability: the available capabilities, their interfaces, and the agent’s choices can change during execution. Curn acknowledges that this can be flaky. His expectation is that improving models will make discovery useful and reliable, but he explicitly leaves that outcome open.

Trust is a separate unresolved problem. An agent may be able to find, call, and pay a tool without knowing whether it should trust that tool or another agent. No reputation or economic trust mechanism is supplied here. Whether autonomous interaction can ultimately enable AGI remains unanswered as well. Curn closes by inviting experimentation through mcp.apify.com: the marketplace demonstrates a path to acquiring capabilities, while reliability, trustworthy counterparties, and emergent intelligence remain questions to test.

Open questions slide asks whether autonomous discovery will provide real value and how agents can trust tools and each other.
Open questions about autonomous discovery and trust.
16:4417:02
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

16:44 · section reference included

Resources

From the talk

Read the complete timestamped transcript
  1. 0:00

    [on hold music] So let me start with a question.

  2. 0:16

    How does intelligence emerges in, uh, biological systems, right? Well, it's through neu-neurons, right? Well, when neurons are born, they are just like individual cells. But like over time, they grow their axons and dendrites and establish connections with other cells or other neurons and actually learn how to communicate in order to pursue their own interests, basically, like to

  3. 0:39

    get nutrients and so on. And over time, they learn how to, how to communicate with each other and with other cells to get nutrients and basically thrive, right? And this collective behavior, if you like sc-zoom out and look at like really large number of them, uh, it's something we call intelligence, right?

  4. 0:54

    So it's like emergent behavior of smaller individual units that pursue their own interest. So how does intelligence emerge, uh, emerge in the markets, right? People always talk about markets like, well, market thinks that, market, uh, reacted to this, and so on.

  5. 1:11

    And in some way, uh, markets are more intelligent, uh, than like individual like participant of the market, right? And it's-- there are mutual, uh, interaction of these individual members of the market, basically, who pursue their own interest and communicate and establish new interactions with others, uh, where some, some sort of like collective intelligence, which is like bigger

  6. 1:33

    than the sum of different parts emerges, right? So how does intelligence emerges, uh, emerge in companies? Well, this one is provocative, through Slack, right? [laughs] Where people interact and pursue their own interest, uh, in the company and over-- like all together, the company, well, sometimes becomes more intelligent than the individual employees of the company.

  7. 1:55

    And, uh, so this leads to my final question. So how does or how will the general intelligence emerge in computing systems, right? And there is a lot of talk about AGI and, uh, like, you know, like ever larger models, uh, exhibiting like, uh, super intelligent behavior.

  8. 2:11

    But in my opinion, the like general intelligence will actually emerge through interaction of multiple entities, you can call them agents, basically like multiple models, uh, pursuing their own goals, interacting with each other, and, uh, all together exhibiting something which we can call general intelligence.

  9. 2:30

    And thanks to, uh, MCP, we finally have this, uh, missing part that allows the, the agents to communicate with each other and really like create a fabric or agentic mesh where they can talk together.

  10. 2:43

    So, uh, hello everyone, my name is, uh, Jan Curn. I'm the founder of Apify, and, uh, I'm gonna talk about the rise of the agentic economy on the shoulders of MCP.

  11. 2:52

    Basically, economy where agents, uh, can, you know, find counterparts, uh, to interact with and purchase services from other, uh, uh, from businesses or tools or other agents, right? So like B2A and B2B, uh, sorry, and A2A.

  12. 3:09

    All right. So before I start, um, let me just introduce quickly Apify. Apify is a, is a marketplace of five thousand tools called actors. And, uh, historically, we come from the web scraping industry, right?

  13. 3:22

    So most of these actors are data extraction tools that allow you, you know, to get data from social media, from search engines, uh, data for AI, for building RAG pipelines, you know, uh, data from web, uh, for lead generation, and so on.

  14. 3:36

    But also there are other tools like data processing tools and so on. So altogether, there's about five thousand of them, and some of them are built by Apify, some are built by our community of creators, uh, who actually make money on it, right?

  15. 3:48

    So it's like a marketplace of software creators, if you will, right? So actors are self-contained piece of-- pieces of software based on Docker with well-defined input and output, right?

  16. 4:00

    And basically, they represent a new way how to ship software and publish it, you know, and, uh, and integrate to, to, you know, other systems, right? So for example, Google Map Scraper, it's quite popular actor, uh, from our store.

  17. 4:12

    Uh, it can extract data from Google Maps, right? Uh, more data than, than the Google Places API provides, right? Uh, well, there is like creator of the actor description, you know, uh, different stat and so on, something you would expect from normal mar-marketplace.

  18. 4:25

    And actually, thanks to the way actors are built, it's actually super easy to integrate actors from other systems, right? So for example, we have SDKs for TypeScript, for Python, uh, for OpenAPI, uh, for C-- um, um, for CLI, it's like we can call it from terminal.

  19. 4:43

    And it's only because they are well-defined units of software with input and output, right?

  20. 4:48

    Uh, also we have integrations with, uh, workflow automation tools like Make, Zapier, you know, Clay, and many others. So to make it really easy to call actors from these systems, right?

  21. 4:59

    But obviously now, uh, we also have MCP integration, which makes it possible to call actors from AI agents or, you know, AI workflows. And the way it works actually is, uh, the agent just needs a API key or, you know, workflow on an a-an account on Apify, and then through our MCP server, basically it can interact or

  22. 5:24

    call any of those five thousand actors on our marketplace, right? And actually, this only became possible thanks to, uh, I would say the killer feature of, uh, MCP, which is the tool discovery, right?

  23. 5:36

    Actually, um, not many clients support this yet, uh, but, uh, just yesterday, I saw that V-VS Code added support for it. Uh, and actually just like two days ago, Claude, uh, for Desktop added support for tool discovery.

  24. 5:49

    And basically how it works is that, um, the client connects to the MCP server and dynamically discovers tools to use and to interact with based on the, based on the, the, the workflow, right?

  25. 6:03

    And let's say we have like five thousand tools on our, our store, and there is simply no way we could publish all these tools through OpenAPI because, you know, the, the context would be just too large.

  26. 6:12

    And like the more tools you have, the, you know- ... riskier the result is, right? So we really want, like, provide the tools only, like, uh, as needed. And that is only possible t- through tool discovery, which I think is really the main thing that will actually make MCP really, uh,

  27. 6:31

    the huge differentiator from, from OpenAPI, for example, right? So MCP actually quickly became a standard for agentic interaction. This is, uh, Google Trends data showing that MCP is, is basically dominating the space compared to OpenAPI or A2A from, from Google, right?

  28. 6:47

    And actually, I think MCP already became a standard for agentic interaction. And it became so popular that w- currently there are, like, you know, many different like, uh, registries of MCP servers that even guys from Master, our friends, created like registry of MCP server registries, right?

  29. 7:06

    Just to [laughs] make the sense of it, right? And obviously, Anthropic is also working on their own, uh, registry. And, uh, I think G- Google's A2A, they have like a DNS-based protocol with like well-known .agentjson way to, you know, publish the, the services on t- through DNS.

  30. 7:24

    So basically, there is like, you know, so many different servers you can now use from the agents, right? So does it mean with like... So many tools now support MCP, so does it mean like the agents can discover and access any of them on their own, right?

  31. 7:41

    Well, not really, because to use those services, your agents still need, uh, to have like API tokens to those services, right? So even if... Let's say if you use, uh, Zapier M- MCP that provides access to like 5,000 apps they have in their marketplace, you still need to connect those individual apps to your services, right?

  32. 8:00

    You know, to like GitHub or Slack or, you know, whatever. So Zapier on their- on its own is not able to provide access to this, uh, th- third-party services.

  33. 8:09

    You still need to, as a user, to facilitate it. So that, that actually means that, uh, the agents are not able to, like, find counterparts, uh, or like, uh, other agents or other tools to interact with on their own.

  34. 8:23

    They are still depending on the human, uh, developer who actually build the system, right? Who kind of like give those, those, those agents access to different tools, right? And if those agents are, you know, to replace all the people and all the jobs, right, they s- need to be able to, uh, find services to interact with.

  35. 8:41

    They can't just like, you know, do, do that. Like, it's like s- basic, basic thing that like, uh, a- anyone of us can do, right? Like to find service and purchase it, right?

  36. 8:51

    So I argue that like unless the, the, the agents are able to do that, uh,

  37. 8:57

    we will not be able to reach, you know, some higher level of, of intelligence of these agentic systems and behaviors, basically, uh, if the agents cannot purchase services, right?

  38. 9:07

    So how can we solve this problem, right? So first, like, sort of like naive approach would be let the agents subscribes, uh, themselves to the target services, right? So basically, in a way, like agents could have like email, maybe a credit card.

  39. 9:21

    They could like fill, you know, the subscription flow, maybe solve the CAPTCHA, you know, create an account, and so on. But you see, it's, it's not very practical, right?

  40. 9:28

    I mean, it's, you know... Well, they might need to also have the phone number, and so on. And quite often the services actually need to have like real person behind the account, right?

  41. 9:38

    So basically, this, this wouldn't really work, right? Uh, so second solution, uh, is central identity and payments provider. There are like couple of companies pursuing now that, like, there would be like a central authority where you can charge money, and then the agents can use that, you know, to buy services and, and provide them with their identity,

  42. 9:56

    right? For example, Vertify. Coinbase is now pushing their X402 standard. Uh, I think Stripe is working on this and MasterCard and Visa too, right? So I think this is gonna, this is gonna happen eventually, but running or launching new payment system is extremely complicated, right?

  43. 10:12

    Because you are facing like this chicken and egg problem of marketplaces, right? I think PayPal had to, uh, pay like $100 million per month just to buy the market.

  44. 10:20

    Uh, and like launching credit cards in the, in the '70s was like incredible challenge basically because nobody was accepting those cards, so why would people use them, and so on, right?

  45. 10:28

    So I think this will happen, but it will be long process basically to establish this, right? So let me offer the third approach, and it's like through a centralized, uh, marketplace of MCP services, like Apify Store basically, where you just need one API token or one authentication, one account to, to get access to all the other services.

  46. 10:47

    And basically, it works the way that the developers who publish these tools, these actors, actually they provide their credit card and their account to the third-party service and basically publish it, add monetization to it, like, uh, like how much does it cost to call this service?

  47. 11:02

    And then they are basically the owner of the service, and now they publish it on our marketplace, and suddenly it becomes available to the whole ecosystem of tools. And this way, actually, we can scale it rapidly and actually even without the target services knowing, right?

  48. 11:15

    So basically, this way, the actor can co- run the code itself or wrap an external API or just publish an external MCP server. Because the MCP servers, they can be actually nested.

  49. 11:25

    You can have like one parent server that provides actions or tools of the, like, nested MCP servers, right? So that's another, like, cool feature of, of MCP. You can really build this sort of ecosystem, you know, if you can facilitate the payments and monetization, right?

  50. 11:39

    So actors charges the user, and then it, its developer gets the money and pays for the external service. And anyone can publish su- such an actor even without the target service knowing, right?

  51. 11:51

    So time for demo. It's not live demo because the internet, uh, super flaky here. So what you can see here is Claude for desktop, uh, that has access to Apify MCP server.

  52. 12:03

    Uh, there is like 18 tools available now. And I'm asking like, "What is the venue of AI Engineer World's Fair in San Francisco? If possible, use Apify Actors." So it...

  53. 12:11

    You can see it searches the actors, uh, for a tool that can answer this question. It will find a tool or actor called RAG Web Browser. And so it's call- it's, uh, it's like a Google search with, uh, you know, fetch data.

  54. 12:25

    So basically it, it asks the query, like, uh, what is the venue and so on, and then it pr- parses the, the resulting page. So we can see it found, like, uh, SF Marriott Marquis.

  55. 12:35

    Uh, that seems all correct. Right? So now let's use an actor for scraping Twitter.

  56. 12:43

    So, uh, this actor is not available in the context, so, so the agent doesn't know how to use it. So it will... It searches actors on our store and finds an actor that can, uh, scrape Twitter, right?

  57. 12:54

    So it, it calls, it calls add actor, which is like a tool that adds new tool to the context. Uh, actually, Claude is very verbose, uh, describing a lot of things about it.

  58. 13:04

    And actually, there is, like, small box still in Claude Desktop that you need to, like, disable and enable a tool so that the, the tool, uh, list refreshes, and then the tools become available.

  59. 13:13

    I'm sure it's gonna be fixed in the next release. And now let's use that actor to, uh, get last tweet of AI engineer conference. All right? So it calls the actor on Apify.

  60. 13:23

    Uh, it knows the, the Twitter handle, probably from, from the, from the website. And now you can see that, uh, it found result and the last tweet from, uh, this morning was, uh, something about workshops.

  61. 13:36

    That seems about right. So now what? So we, we have, we have seen how we can use existing tools in, in, in our store, but, like, let's say, uh, uh, one of our competitors, a company called Browserbase.

  62. 13:52

    Hey, Paul, if you're here. Uh, they r- certainly haven't published, you know, uh, an actor in our store, but we did. So we created an account on Browserbase, added our API token there, and published, like, basically their MCP server on our store without actually them even knowing.

  63. 14:09

    And now anybody can actually use Browserbase MCP through Apify's ecosystem, right? Even without them having to do anything or knowing about it, right? So now let's use Browserbase to fill in the email subscription form on the AI engineer website.

  64. 14:25

    Fill email, uh, [REDACTED:email_address]. And now let's see what happens, right? And actually we'll see that, uh, that the, that the agent will actually call Browserbase MCP through, you know, an actor published, published, you know, by us on our, on Apify Store, and perform the actions on the web, right?

  65. 14:43

    And actually, this way we can easily, like, uh, bring a lot of, lot of existing MCP servers to our store and, you know, expand the ecosystem rapidly without, you know, having to ask for, for, you know, cooperation of those third parties, right?

  66. 14:58

    So that's actually what we're doing now. Uh, we want to scale this marketplace rapidly. And now, okay, so now it's evaluating, you know, the screenshots, looking for the field, and so on, you know.

  67. 15:09

    And eventually it will manage to, uh, fill the form and, and basically succeed in the task, right? I can maybe skip this, uh, to save time. It takes some, some, some time to basically, uh, for the agent to, to find a form and so on.

  68. 15:26

    But, uh, yeah. It succeeded. It completed the email sub- sub- subscription, and

  69. 15:34

    this way you basically see that, uh, you can plug

  70. 15:40

    our, our ecosystem of actors into, into, uh, any AI a- agents that, that actually support tool discovery, right?

  71. 15:47

    All right. And... So this means now anyone can publish tools or, you know, agents on Apify Store and monetize them and immediately get access, you know, to all the AI clients that already, like, integrated with Apify and all the ecosystem of tools, right?

  72. 16:08

    And actually people can ma- make money on it. Like, just last month we paid, uh, more than a quarter million dollars to our creators, and actually the, the, the...

  73. 16:16

    this number is, is growing rapidly. You know, overall the actors generate more than one and a half million dollars per month now. Uh, we have, like, uh, one million monthly visitors to the whole ecosystem, and now we're really in the process of, like, scaling this ec- ecosystem.

  74. 16:29

    So, um, if you're looking for ways to monetize your tools or agents, you know, just, uh, talk to us and publ- or pub- Apify Actor, Apify Store and get access to this ecosystem of developers and this visibility.

  75. 16:44

    And there are some open questions obviously, uh, that remain. So will this autonomous tool discovery provide real value? I mean, like, everybody who builds agentic systems knows that, you know, like, making sure that the system works as expected is tricky, right?

  76. 17:02

    Even if it's fixed. So if we add this, like, you know, variables that, like, well, uh, if the agents can discover new tools, uh, will it actually work? Well, currently it might, it might be a bit flaky, right?

  77. 17:14

    I think we're still, still, still, still... We, we're still fairly early. But as the models get better,

  78. 17:20

    I think, uh, even with the discovery, suddenly the, the, the agents will be, will be able to provide, you know, valuable and w- reliable result basically, right? So it just r- this remains to be seen, but I'm optimistic that, like, as the, as the LLMs will get better, we'll actually get there, that the tool discovery will actually

  79. 17:39

    provide real value. Well, there's a big question of, like, how can agents trust tools or other tools... Or, sor- sorry, or each other, right? We know it, like, you only interact with people you trust.

  80. 17:49

    So how can agents do that? We'll see. And can autonomous agent interaction enable AGI? Well, we'll see. Thank you very much for your attention, and, uh, feel free to try it, uh, mcp.apify.com. [outro music]