Many modern Android applications are highly advanced and operate in sensitive domains like banking, money transfers, and other critical services people rely on daily. A rooted environment gives attackers elevated access to the device, which they can abuse in order to bypass the app’s restrictions, extract sensitive data, and interfere with the app’s behavior.

To counter these threats, many apps implement protections against common tools and techniques used in reverse engineering. These include anti-root, anti-hook, and anti-debug mechanisms, which are designed to make an attacker’s job significantly more difficult—often requiring considerable effort and creativity to bypass.

A practical look at protection mechanisms

This article provides other security researchers with a practical look at how some of these protection mechanisms are implemented and how they can be bypassed during penetration testing or security research.

Additionally, by understanding how these protections work, developers can build stronger, more resilient security mechanisms into their apps and even extend these ideas to develop more advanced and effective techniques.

Furthermore, during this research, an application called TamperLab was created. It includes various protection mechanisms to detect whether a device is rooted, whether any hooking is in place, or whether the application is being debugged. The project is fully open-source, and contributions are welcome.

It can be found on the following GitHub page for you to check out:

Anti-Root Protections

In this section, we will look at some commonly used root detection techniques and their implementations, and immediately follow each one with an example of how it can be bypassed during testing or reverse engineering.

The “One Function” Folly

The most common way of implementing protection measures such as anti-root, anti-hook, and anti-debug is by placing all checks inside a single function. This is a common mistake, as it gives attackers the opportunity to bypass all protections within seconds.For example, in the following scenario, the RootBeer library is used to quickly demonstrate why placing all checks in a single function can be problematic. As shown in the code snippet below, the isRooted() function is called.

Such a function includes various methods to detect if the device is rooted.

Although the function includes many ways to detect if the device is rooted, it is not sufficient because the isRooted() function itself can be hooked, allowing an attacker to bypass all detections with a single hook.

Using the following simple Frida script, we can do exactly that. We obtain a reference to the RootBeer class and hook the isRooted() function, immediately returning false.

Using the following command, the targeted application can be started with the hook applied.

As shown in the following image, the previously created script successfully bypasses all the checks because they are contained within a single function.

Testing this inside TamperLab shows that we successfully bypass the protection measure, and a green checkmark is displayed.

SU Binary Check (Shell)

All rooted Android devices contain the su binary, and any application requiring root access must use su to elevate privileges and perform privileged actions on the device.

When present on a device, applications can detect the existence of the binary and conclude that the device is rooted. A quick way to check for it is by programmatically executing the which su system command.In my application, I created a simple HelperClass that contains various functionalities and detection methods. One of its purposes is to execute system commands.

The executeCommand() function essentially passes the given command as an argument to the exec() function, which executes it on the device.

If the su binary exists, the command will return its full system path, otherwise, an error code will be returned.

Using Frida, we can bypass this technique by hooking the exec() function itself. If we detect a command such as which su, we can replace it at runtime with another non-existent command.

As demonstrated, by using this technique, we can target specific exec() parameters after reverse engineering the application and bypass the detection mechanisms in place.

SU Binary Check (Native C/C++)

Another way developers may check for the su binary or for rooted devices in general is by writing native C/C++ code using JNI. In case you are unfamiliar, JNI (Java Native Interface) is a framework that allows Java code running on the Android platform to interact with native applications and libraries written in C or C++.

For example, we can check for the su binary by iterating through common system paths where it might exist, and then using the std::ifstream function to check if the file can be opened.

A small Java class is then created to serve as a bridge between the Java code and the native C/C++ code in the application. It uses JNI (Java Native Interface) to perform the native task.

Under normal circumstances, you wouldn’t have access to the source code. However, a common way to reverse engineer the application is by decompiling it using JADX, which can be done with the following command.

Once decompiled, your application may contain various libraries. You can easily filter through them by searching for files with the .so extension, which indicates native libraries.

To reverse engineer the library, tools such as Ghidra or IDA Pro can be used. In this case, Ghidra was used.

The decompiled code shows that ifstream is first used (1) to check whether the file exists. Based on this check, the function returns \x01 (JNI_TRUE) (2) if the su binary is found, otherwise, it returns \x00 (JNI_FALSE) (3).

Since this is a JNI function and is exposed using extern “C”, it appears in the symbol table with the exact name observed in Ghidra.

Bypassing such checks is relatively straightforward. To hook a native function using Frida, we use Interceptor.attach() and specify the target function using Module.findExportByName().

Since we are intercepting a function from the native library, we need to attach to the process while it is already running by using the -n parameter with the following command.

As shown in the script’s output, we successfully bypass the check even though it resides within JNI code.

Another clever approach is to hook the open() function instead of the entire native function implemented in the application.

Since std::ifstream() ultimately invokes the open() system call, we can hook open() to intercept any attempt to access a binary whose path contains “su”. We can then substitute that path with a fake one to bypass the check.

As shown in the image, this technique effectively bypasses native checks early by using the -f flag to hook before execution, unlike the -n flag, which attaches the hook while the process is already running.

Spoofing /proc/mounts

Nowadays, many Android devices are commonly rooted using Magisk, which comes with a variety of built-in features.

The /proc/mounts file contains a list of all currently mounted filesystems on the device. Additionally, when a device is rooted using Magisk, it modifies the boot image and mounts partitions dynamically by default, so you may find traces of Magisk there as well.

An implementation to detect this might look like the following, where an application reads the contents of /proc/mounts in search of Magisk.

To bypass this, we can create a script like the following, where we define a list of mounts that don’t contain Magisk traces or any other suspicious entries, for that matter.

The first interceptor hooks the open() system call to capture the file descriptor used when accessing /proc/mounts.

The second interceptor hooks read(), checks if the file descriptor corresponds to /proc/mounts, ensures the content hasn’t already been spoofed (to prevent repeated modifications and potential crashes), and finally replaces the buffer with our fake mount data defined at the top.

By running the hook, we successfully spoof the contents of /proc/mounts with our fake data, effectively bypassing the detection check.

It’s important to note that these techniques can be implemented and bypassed in various ways. Consequently, multiple solutions and countermeasures exist to address them.

Anti-Hooking Protections

Hooking is a powerful technique used during mobile penetration tests because it allows intercepting, modifying, and monitoring an application’s behavior at runtime. It provides direct access to function calls, arguments, return values, and the internal logic of methods.

To perform such attacks, Frida is a widely used tool that enables pentesters and attackers to bypass security controls or extract potentially sensitive data.

Frida Port Detection

A common way to detect Frida is by checking for open frida-server ports, since Frida communicates using WebSockets. Simple checks often look for ports like 27042 or 27043, which are the default ports used by Frida.

Such checks can be easily bypassed by simply starting the Frida server on a different port using the following command.

A more advanced detection method involves scanning all ports by sending specific HTTP requests and checking for a 101 Switching Protocols response, which indicates the presence of a Frida server.An example of such native code would involve sending a WebSocket upgrade request to every open port on the device. If the response contains 101 Switching Protocols, it confirms that a Frida server has been successfully detected.

This check can be bypassed by hooking the read() calls and inspecting the buffer content after the call completes. If the buffer contains 101 Switching Protocols, indicating a Frida server query, we can modify the response to something benign such as HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n to evade detection.

As demonstrated, once the hook is executed, the check is successfully bypassed.

Frida Threads Detection

In Linux-based environments (including Android), each process has a task directory located at /proc/self/task, containing a subdirectory for each thread within the process. Each of these subdirectories includes a comm file that holds the name of the corresponding thread.

When Frida is injected into a process, it typically creates several threads for its internal operations. These threads often have distinctive names such as frida, gum-js-loop, gmain, gdbus or some other which can be used to detect Frida’s presence.

To better understand this, we can run the following command on the device to retrieve the names of all threads for a specified process.

As shown in the following snippet, this is the output of the thread list when no Frida hooks are active.

When a Frida hook is applied to the process, threads named gmain and gdbus appear both associated with Frida’s runtime. This allows us to detect Frida based on the presence of these thread names.

To detect this, we can use C++ code like the following, which loops through each comm file in the /proc/self/task directory to retrieve thread names and checks them against a list of common thread names used by Frida.

One intriguing approach to evade detection is to patch the entire frida-server binary by replacing all occurrences of strings like gmain. By searching for gmain in Ghidra, we can observe the following results.

By selecting one of the instances, we can examine the disassembled code to pinpoint its exact location.

We can now use Ghidra’s built-in hex editor to modify these strings, replacing gmain with another string, such as hackr.

After injecting the Frida hook, we can see that we have successfully bypassed the detection, as it no longer identifies Frida’s threads.

If we loop through the thread names again for the application we are attacking, we can see that it now successfully contains the hackr thread name.

Of course, there are other detectable strings, but this simple example demonstrates one way to bypass detection by directly patching the frida-server binary yourself. This way you could build an entirely different frida-server to avoid detections or modify the original source code as well.

Anti-Debug Protections

Anti-debug protections are another way to protect your Android application from reverse engineering. These mechanisms aim to detect or prevent debugging attempts, stopping attackers from stepping through the app’s code instruction by instruction to understand its internal logic.

Like most security measures, anti-debug mechanisms can also be bypassed using Frida hooks. However, I want to show you how you can defeat these protections using a debugger itself.

Defeating Anti-Debug using Debugger

isDebuggerConnected()

This is a simple, ready-made function that checks if a debugger is connected to the application. It returns true if a debugger is detected, otherwise, it returns false.

Implementing such a function is straightforward, and you can call it as follows:

To use the debugger and bypass this check, we can utilize JADX’s integrated debugger. Before launching it, ensure the application is already running.

Another way to start an application is by using the following ADB command, which will launch the app but pause and wait for the debugger to attach.

As shown, when you launch the application, it will display a message indicating that it is waiting for a debugger.

In my case, it doesn’t work, but I can open the application without it waiting for the debugger. However, your application might require this behavior, so it’s important to test both methods.

Additionally, whenever you’re done or close the application, make sure to run the following command to remove the app from waiting for a debugger.

Once ready, you can open JADX and load the APK file of the target application. You can also pull the APK from your device using ADB.

Once loaded into JADX, select the green bug icon, which opens a dialog prompting you to choose the application to debug along with its process ID.

After the debugger attaches, the application’s execution is automatically paused inside the MainActivity. You can then press the green play button to continue running the application.

Once you find the correct position to set a breakpoint, you can do so by pressing the F2 key. For this example, I set the breakpoint exactly where the isDebuggerConnected() function is called.

The following instruction essentially calls the isDebuggerConnected() function using the invoke-static opcode.

Then, the move-result instruction moves the return value of the function (either true or false) into the v0 register.

By stepping over these two instructions, we can observe that the v0 register contains the value 1, indicating that a debugger has been detected.

To bypass this check, we can simply set the value to 0 using the debugger, as shown below:

Continuing the application’s execution, we successfully bypass the check by manipulating the variables during debugging.

Detection via USB & ADB

Another interesting way to detect debugging is by checking if the device is connected via USB with ADB enabled. While this isn’t a direct debugger detection method, it remains a useful check nonetheless.

A simple implementation might look like the following, where the app dynamically listens for the USB_STATE broadcast and parses the connected and adb boolean extras from the received intent.

We can also bypass this check by using the debugger to place breakpoints at the appropriate locations.

In this case, I set a breakpoint on the if-eqz instructions, which checks whether the values in registers v0 and v2 are equal to zero. These registers correspond to the connected and adbEnabled flags.

When the breakpoint is hit, we observe that both values are set to 1 (true), indicating that USB is connected and ADB is enabled.

We can now simply set these two values to 0 (false), causing the check to fail and allowing the app to continue execution.

Conclusion

We have explored several common anti-root, anti-hook, and anti-debug techniques and demonstrated how each can ultimately be bypassed. However, it is important to recognize that these protections still play a critical role in Android security.

No protection is entirely foolproof. Given enough time and the right tools, a determined attacker can often find a way around most defenses. However, the goal of these mechanisms isn’t to create an unbreakable application, but rather to increase the complexity of attacks. This raises the time, effort, and skill required for an attacker to compromise the application, which can deter casual attackers and slow down more advanced ones.

In short, while these security checks can be bypassed, they remain a valuable part of a defense-in-depth strategy. Labs like TamperLab that we have created, provide a practical environment where you can practice implementing these detection mechanisms and learn how to bypass them. It’s about making it hard enough that breaking the security is no longer worth the effort.

At Infinum, we help you stay ahead with tailored cybersecurity services, including penetration testing and security assessments. Whether launching new products or protecting existing ones, we identify weaknesses before attackers do so you can focus on what matters. Learn more about how we keep your digital world secure on our cybersecurity page.

Snapshot Testing has become a commonly adopted technique for testing user interfaces. The popularity stems from its ability to address the unique challenges of UI testing and the simplicity of setup.

Despite its success in UI testing, snapshot testing hasn’t gained much traction in other areas of software development. This lack of adoption is unfortunate, as many challenges in software development mirror those encountered in UI testing: hard-to-define outputs, complex interactions, and the need for reliable, repeatable tests.

This is especially relevant in the age of AI, where a feedback loop is crucial for autonomous agentic development.

But snapshot testing can be extended beyond UI and applied effectively to audio development. Enter AudioSnapshotTesting, a library developed in collaboration with AudioKit, designed to simplify and streamline the testing of audio processing workflows.

The idea of snapshot testing was popularised in the iOS community by Facebook’s FBSnapshotTestCase, later renamed and maintained by Uber as iOSSnapshotTestCase. The API of those libraries was constrained to UI testing. Later on, a “delightful” Swift Snapshot testing library has gained popularity. While swift-snapshot-testing made a significant step in generalising the idea of snapshot testing – by providing strategies to “Snapshot Anything” – in practice, companies mostly use it for UI testing.

Snapshot Testing, Golden Master Testing, Characterization Testing, Approval Testing and Reference Testing all describe the same fundamental idea – verifying that software behaviour remains consistent over time. Unfortunately, terminological fragmentation creates artificial barriers, leading to missed opportunities.
To explore Snapshot Testing outside of the UI domain, we will work on a simple metronome app.

Testing Metronome

Building a metronome seems straightforward: generate periodic audio clicks at a specified tempo?

However, when we start implementing one, questions arise quickly:

The traditional approach is tedious: build the app, run it and listen carefully. Maybe export audio and inspect it in a third-party tool. Repeat for every change.

Snapshot testing offers a different workflow. Here’s a simple test for our metronome’s audio output:

Running this test with record: true saves the audio buffer to disk as a lossless ALAC-encoded file. The ALAC format produces significantly smaller files than WAV while maintaining audio fidelity. Additionally, while in recording mode, the library generates a waveform visualization that allows us to iterate on our metronome implementation and see changes in the generated image.

Once we have a reference we are confident in, we switch to record: false.

Now the test compares the current output against that reference audio file, failing if anything changes.

This workflow transforms audio development. Instead of rebuilding and running our app dozens of times, we run our test suite. Each test runs quickly and provides the iterative feedback we (or AI agent) need to implement our audio features.

The real power emerges when refactoring. Want to optimize your audio rendering or change your DSP algorithm? The expected output is now covered by tests. If the visual output remains identical, we haven’t broken anything. If it changes, we can immediately see what changed and decide if it’s intended or a bug.

A picture truly is worth a thousand tests

AudioSnapshotTesting Library

AudioSnapshotTesting is designed to work seamlessly with Swift Testing framework, providing specialized support for snapshotting AVAudioPCMBuffer’s with various visualization strategies.

Waveform: Time-Domain Visualization

The waveform strategy provides the familiar amplitude-over-time view. It’s perfect for spotting timing issues, clipping, unexpected silence, or amplitude problems:

Want to compare two audio buffers visually? The waveform strategy automatically overlays multiple buffers:

This renders the first buffer in red, the second in green, making differences immediately obvious.

Spectrum: Frequency-Domain Visualization

While waveforms show what happens over time, spectrum analysis reveals frequency content. This is invaluable when testing filters, equalizers, or any DSP that operates in the frequency domain:

Spectrogram: Time-Frequency Representation

The spectrogram strategy combines time and frequency analysis, showing how spectral content evolves:

Spectrograms are particularly useful for analyzing complex signals, transient events, or any audio where frequency content changes over time.

Streamlined Workflow

For an even smoother development experience, the library offers the autoOpen parameter. When enabled during recording, it automatically opens visualizations in Preview (on macOS), eliminating the need to manually locate and open files:

This is particularly useful when iterating on DSP algorithms—run the test, and the waveform appears instantly for visual verification.

Why a Standalone Library?

While swift-snapshot-testing is an excellent library, we wanted a specialised approach. Audio is about samples—raw numeric data representing sound waves. In AudioSnapshotTesting, sample-by-sample comparison is the source of truth. Visualizations are secondary, generated only on failure or during recording as debugging aids. The audio files are always preserved, allowing inspection in any audio editor.

Try it out

In this article, we’ve shown how snapshot testing serves dual purposes: providing rapid feedback during development and acting as a comprehensive regression suite. The techniques we’ve explored—waveform visualization, spectrum analysis, and spectrogram generation—aren’t new, but integrating them into your test suite transforms them from manual verification tools into automated quality gates.

With audio files always preserved for detailed inspection, configurable bit depth for balancing file size and precision, and workflow enhancements like auto-opening, AudioSnapshotTesting makes audio testing both powerful and practical.

As long-term AudioKit users, we’ve benefited immensely from the community’s contributions to audio development on Apple platforms. We’re thrilled to give back with this tool and hope it helps others build more reliable audio software.

The library is open source and available on GitHub, and we welcome contributions from the community:

Businesses are enthusiastically adopting artificial intelligence, with McKinsey reporting that 78% of companies now use at least one AI tool. Not surprisingly, the adoption rate is even higher in tech companies. 

With this information in mind, it is only natural that AI automation is a much sought-after innovation.

Of course, you might want to understand it better before you decide you need it for your operations. We are here to help you with that.

What is AI automation?

AI automation is the process of using advanced technologies to make standard automated operations smarter and context-aware. It reduces the manual effort your team needs to put in by using AI and intelligent automation for tasks such as data analysis, report generation, and workflow optimization.

AI automation uses a mix of software, data, and decision logic to quickly and automatically execute tasks that normally require time and human judgment.

The specific technologies involved depend entirely on the business case: sometimes it’s simple rules, sometimes it’s document processing, and in certain cases it can include machine-learning or NLP models. The goal is always to make a workflow faster, more consistent, and less manually intensive.

Instead of predicting the “right” action on its own, AI supports the decisions that have already been defined. It can classify information, extract meaning from text or images, or surface relevant insights so that the system can follow the workflow the business has set.

When conditions change, the model can adjust its behavior within those boundaries, which makes it more flexible than fixed, step-by-step scripting.
As the system is used, its components can be refined through controlled cycles of periodic updates or retraining based on new data. 

In short, AI automation expands what traditional automation can do by helping systems understand inputs and choose the right path in a defined workflow, all within clear business rules and oversight.

Since the process is still responsive, AI automation can be very useful in areas where you want constant monitoring. In cybersecurity, it can spot suspicious behavior and trigger alerts instantly. In fraud detection, it can analyze transactions in real time to prevent losses.

Similarly, it can also be very useful for initial screening tasks, where the technology can decide who to send the problem to. For example, AI can be used to scan medical test reports and X-rays to make initial diagnoses, significantly reducing manual effort. They then forward it to the specialists who verify it and recommend treatment. 

This makes the process of getting healthcare quicker for patients and frees up healthcare providers to focus on the people who need them most.

How is AI automation different from traditional automation?

Traditional Automation, without AI, is a mechanical process that follows fixed and predefined rules. For example, a conveyor belt is automated: You flip a switch, and it starts moving. It might be programmed to stop if there is no weight on it, but it cannot react to a situation for which it was not explicitly programmed.

In contrast, AI-driven process automation can adapt its behavior based on input: it can interpret unstructured text, classify information, or extract relevant details, allowing the workflow to respond appropriately without manual intervention. The automation still follows defined steps, but the AI components enable the system to process a wider range of human input, formats, and real-world variability.

A simple example is a smart chatbot. The user enters a query using natural language, and the tool interprets the intent to create an appropriate response accordingly, leveraging large language models.

At a slightly more advanced level, AI agents take this a step further. Agentic AI can autonomously or semi-autonomously automate entire processes rather than individual tasks. They can plan, reason, and even collaborate with other systems or humans to achieve their goals.

Intelligent automation: Taking AI automation further

Intelligent automation (IA) is the next level of AI automation. Here, instead of tasks or processes, entire ecosystems are automated. They can run, adapt, and improve over time, all on their own.

There are three key technologies that power these digital workers:

How AI automation works

To create AI automation, you need to integrate processes with artificial intelligence. The processes create the framework around which algorithms are built.

These algorithms use the same decision-making logic that a person would, and are trained on business data. This informs them of the type of information and the patterns to expect. 

The logic built into them allows them to use new data to spot these patterns and make predictions. Meanwhile, ML allows them to learn from it, so the systems continuously refine and improve their results.

Here is a quick overview of the parts that come together to make this technology work: 

Benefits of AI-powered automation in your business

We already know that AI automation can free up your human workers by taking over routine tasks. Let us take a look at how this can benefit your business:

AI automation use cases

Reading about benefits in an abstract sense does not paint a very clear picture. Here’s how businesses across industries are applying AI automation to solve their challenges:

Challenges of implementing AI automation

Implementing AI workflow automation solutions can be a great way to optimize your operations. However, the process requires careful planning, or it will not increase efficiency.


Here are some caveats to consider:

Automate your business with the right partner

Several of the above challenges can be mitigated by working with the right technology partner, such as Infinum.


We have the experience that allows us to develop solutions tailored to your needs, so they can integrate easily with your existing technology and workflows. 


Most importantly, our methods, reporting, and internal processes meet strict, internationally recognised security standards. With Infinum, the security of your AI automation solution will be in safe hands.


We have a large team that can help you navigate strategy development, data engineering, model building, deployment and integration, as well as ongoing monitoring and maintenance.


Interested in learning more about how we can help you with your AI automation journey? Talk to us!

There are moments in tech when everything changes: the rise of the web, the move to the cloud, the boom of app stores. We believe we’re witnessing the next one: apps inside ChatGPT.

OpenAI’s new Apps SDK allows developers to build native apps that live inside the ChatGPT interface, enabling users to transact, explore, and interact through natural language.

Instead of asking users to visit your site, download your app, or fill out a form, you’ll be able to meet them where they already are: inside ChatGPT, right in the flow of conversation.

Tech entrepreneur and AI agent whisperer, Ivan Burazin, appears in our event series Delivered to discuss how to prepare your business for the agentic AI revolution.

AI is no longer optional, it’s a baseline expectation. That was the message behind a now-famous leaked memo from Shopify’s CEO, and it’s a sentiment echoing across industries. But just as businesses began adapting to generative AI, along came their smarter, more autonomous cousins: AI agents.

Some businesses are already seeing major productivity gains, while others are simply burning money. The difference lies in knowing where AI agents can add value.

Appearing as a guest on our show Delivered, tech entrepreneur and AI agent expert Ivan Burazin, broke down how AI agents work, where they truly add value, and how to avoid the hype.

From passive assistants to true teammates

For a while, generative AI felt like magic: tools that could summarize, translate, draft, and debug. But at its core, generative AI is reactive. You give it a prompt, and it responds accordingly. AI agents, on the other hand, don’t just respond to prompts; they act on behalf of the user.

The key distinction between generative and agentic AI lies in understanding the roles of models vs. agents. A large language model, like GPT-4, is the brain. It processes information and generates responses. But on its own, the model is inert. It doesn’t have an interface, memory, or the ability to interact with external tools. That’s where agents come in.

An agent is the piece of software that acts as the bridge between the user, the model, and any external tool. When you use ChatGPT in a browser or mobile app, that interface is the agent. It handles user input, sends prompts to the model hosted elsewhere, receives responses, and presents them back to you. But more advanced agents go further: they invoke external tools to enhance the model’s capabilities.

Take ChatGPT’s “Operator” mode, which can book a restaurant reservation on your behalf. That’s not just a model responding to a prompt. It’s the agent invoking a browser tool, navigating a site, and performing an action. Without tools, an agent is like an employee with no computer: technically capable, but unable to do much. With tools, it becomes useful. And with context and autonomy, it becomes powerful. This is where AI shifts from being just a passive assistant to something closer to a true digital teammate, explains Ivan.

Are AI agents ready to take over, or still in training?

With all the media headlines proclaiming the end of every profession as we know it, it’s easy to believe that AI agents are ready to replace humans. Remember those viral “Stop hiring humans” billboards? They came from a startup called Artisan, which claimed its CEO was stepping down to let an AI agent take over. A catchy PR stunt. But according to Ivan, we’re not quite there yet. 

AI agents can be impressive, especially in demos where everything is perfectly controlled. When these agents are exposed to the unpredictable, messy real world, their limitations become apparent.

Right now, agents are great at simple, repetitive tasks with clear rules and predictable outcomes. But ask them to handle something vague or complex, and they’ll quickly get lost.

Ivan shares a simple example: asking an agent to organize a meetup in a foreign city without providing any specifics, like the date, venue, or number of guests, will likely lead to failure. But give it exact instructions, and it can execute flawlessly. For now, the narrower the task, the more effective the agent.

Another important limitation? Agents can’t create anything truly new. They can replicate, remix, and automate, but not invent. An AI can build you a clone of Airbnb, but only because Airbnb already exists, says Ivan.

Then there’s the human element. In a world where every competitor has an AI-powered sales rep spamming inboxes, the person who actually shows up, makes eye contact, and builds a real relationship? That’s the one who stands out. Whether it’s sales, therapy, or hospitality, human connection still matters, and always will.

The future of software is agent-native

We’re currently in a transitional phase where most companies are adding AI to existing tools, hoping for smarter results. In reality, most of today’s AI integrations are just chatbots bolted onto SaaS products, explains Ivan. But the real opportunity lies in building agent-native products — software designed from the ground up to let AI agents take action on behalf of users.

Just like Uber and DoorDash only became possible once smartphones with GPS hit the mainstream, agent-native apps will thrive in a world where software can not only respond but act. 

The timing is right. According to Y Combinator, 37% of startups in their latest cohort are building with agents. And since the winners in this space don’t exist yet, there’s a massive opportunity for companies to claim leadership in their domain by being early builders. 

Getting your organization AI-ready

When it comes to preparing your business for AI agents, there’s no one-size-fits-all solution or universal blueprint, because the rules are still being written. As Ivan explains, the AI landscape is evolving too rapidly for any one vendor or consultant to have all the answers. 

Instead of waiting for a perfect product or roadmap, companies need to stay actively informed, experiment with AI tools, and pay close attention to how the field is progressing. In industries further removed from Silicon Valley, the impact of AI agents may not have reached day-to-day operations yet, but it will. 

The key is to avoid the trap of dismissing immature tools too early, because what doesn’t work today might be a game-changer in three months. And if your competitors embrace that shift before you do, the productivity gap could widen fast, warns Ivan.

For more insights on where we stand with AI agents and where we are heading, watch or listen to the full conversation with Ivan. And if you’re looking to build and AI product and need expert support, check out our AI business solutions page.