An agent is an LLM that interacts with the world through tools, memory, APIs, browsers, or computer environments.
2
Prosus Group tested more than 20 agent projects, but only two remained as standalone products or were merged into its general assistant, Tokkan.
3
Agents work better when their tasks have binary evaluation, fit user workflows, and save more time than they add through latency or cognitive load.
Summary
Demetrios Brinkmann, Paul van der Boor, and Floris Fok discuss how Prosus Group experiments with agents across its portfolio companies. Paul defines an agent as an LLM that interacts with the world, with memory, tools, planning, and critique added around the reasoning model. The conversation covers agent types, from API agents to web, computer-use, voice, and robotics systems. Floris describes more than 20 experiments, including the Tokkan general assistant and a SQL analyst that delivered value. Several projects failed because users faced extra steps, workflows were too slow, or the system lacked the context hidden in human processes. The guests explain why agent costs must be measured per completed answer or unit of intelligence rather than per token. They also discuss evaluation, prompt evolution, tool selection, security testing, and the need to understand what an agent cannot do. Their experience favors small, testable tasks and repeated experimentation over polished demos.
An agent connects an LLM to the world through memory, tools, and actions
Paul van der Boor describes an agent as "essentially an LLM that interacts with the world." A plain LLM is like a Raspberry Pi containing only the reasoning engine. An agent adds memory, tools, APIs, files, and the ability to plan, critique a result, revise a step, and act again. Tools give the model access to current or private data, and memory lets it retain useful information from earlier interactions. The complete system must work reliably when it reaches real users, rather than succeeding only in a demonstration.
API agents are easier to test than open-ended browsing or computer use
Paul says Prosus Group's production agents usually work with well-defined APIs. APIs have documented inputs and outputs, which makes testing and evaluation easier. Demetrios Brinkmann places these alongside computer-use agents, web agents, voice agents, and game characters. Paul describes a progression from APIs to browsing, desktops, and eventually physical-world interaction such as robotics. Each step gives the system more freedom, while creating more ways for latency, cost, changing interfaces, and unreliable integrations to cause problems.
Agent projects must earn their complexity through measurable user value
Paul argues that agents are useful because tools let AI handle more than question answering. At Prosus Group, possible applications include booking trips, ordering food, finding products, and making transactions easier. The group first identifies a real user problem, then looks for products or startups that can help solve it. Paul also says existing APIs and interfaces were not designed for agents and can change or break. A production system therefore needs to be affordable, safe, scalable, and connected to interfaces that can support its actions.
Token prices can fall while the cost of a completed answer rises
Paul explains that token price alone gives a poor picture of agent economics. Agents make more calls and use more tokens while completing more useful tasks. During one period, Prosus's internal assistant used 150% more tokens per question, while cost per token fell by about 50%. Token use per user also increased as people used the assistant more. The team measures model quality, cost, and time saved per question, then asks whether the return from each unit of intelligence justifies the higher system cost.
Most experiments fail when the agent adds a step users do not want
Floris Fok describes a verticalized cleaning agent that prepared data for a separate analyst agent. Although the separation seemed likely to improve accuracy and consistency, users preferred an analyst that completed the task in one pass most of the time. Floris says that extra step was not worth it. He also describes a research agent that took several minutes to produce a report. The same latency became more acceptable later when users expected asynchronous deep research, but the original Slack interface was designed for concise replies rather than long documents.
Human context and existing workflows can break an apparently successful agent
A Jira agent worked well in a controlled test, where the team created and managed tasks through the agent's own language. It failed against the real Jira board because people used acronyms, short descriptions, and shared background knowledge that was not written in the tickets. Floris says a future version could interview the team, turn that context into documents, and use it alongside Jira. Paul gives a related example from GitHub, where automatic comments created noise and cognitive load. A system can produce valid content while still making the workflow worse.
Users often want less input, so agent interfaces should reduce friction
The team tried making a conversational assistant for OLX, but users often typed simple requests such as "blue couch." The chat interface added work when the existing site already offered images and a search bar. Paul says agents can still help with queries such as "modern couch" or "light and healthy" because they can interpret less structured preferences and map them to an underlying catalog. Voice can reduce input effort further, especially for users who already communicate through voice messages in markets such as Brazil and India.
Agent testing works best when task completion is clear and failure boundaries are known
Floris recommends asking what an agent cannot do and moving its known failure boundary over time. For a multi-step task, the useful measure is whether the task completed consistently, rather than whether the internal path looked elegant. Data-analysis agents can also report the assumptions they made and the transformations applied, giving users a chance to catch a mistake before relying on the result. Paul says Prosus generally tries to make an agent work first, then make it fast and cheap, while continuing to measure whether the automation saves enough time to justify itself.
