I couldn't get an AI agent to use my own product

I've built over 24 products at this point. MagicSlides alone has over a million users. BlurWeb, BlurScreen, MagicForm — I've been shipping stuff under IndianAppGuy Tech for years. I started out in a call center, taught myself to code, moved to Delhi with basically no plan, and figured it out from there. Taught over 100,000 developers on YouTube along the way. I'm not saying this to flex. I'm saying it because when I tell you I ran into a problem I couldn't solve with any of my existing products, that should mean something.

A few months back I was messing around with AI agents. Trying to string together an automated workflow — research a topic, generate a presentation, send it off. Standard stuff that everyone's experimenting with right now. The research part worked fine. The send part worked fine. The "generate a presentation" part? The agent couldn't do it.

Not because the AI was dumb. Because MagicSlides — my own app, the one with a million users — has a login page, a form on /create, a button to click, a loading screen to wait through. The agent couldn't deal with any of that. My product was invisible to it.

And that felt like a real problem. Not just for me. For anyone building a web app.

Sanskar Tiwari, founder of Browsing Bee, presenting "The future of interface is chat" to an audience
Sharing the idea behind Browsing Bee — the future of interface is chat.

Everyone building agents hits this

I talk to a lot of developers. On Discord, on Twitter, at meetups. The people actually building agent systems right now all have the same complaint. The AI can write a 10-page report, but it can't click a submit button on a web app. The bottleneck is never the intelligence. It's always the interface.

Your SaaS has forms and dashboards and auth flows that humans deal with unconsciously. Agents can't navigate any of it. So they just... don't use your product. They use whatever has an API, or they fail the task entirely.

What I built

Browsing Bee lets you define a "skill" for your product. A skill is the steps a human already takes when using it. For MagicSlides, I wrote it out like this:

  1. Go to the app
  2. Navigate to /create
  3. Type in a topic or upload a file
  4. Hit continue
  5. Wait for slides to generate
  6. Download or grab the URL

That's it. I defined those steps in Browsing Bee, and now any agent can run browsingbee run <skill-id> and the whole thing happens through browser automation. No API to build on my end. No SDK to maintain. The agent just uses MagicSlides the way a person would.

Is browser automation a little janky? Yeah, sometimes. But the alternative is building a dedicated API for agent consumption, and I've shipped 24 products — I know I'm not going to maintain 24 separate agent APIs. Nobody will. So you work with what's practical.

The part where this gets interesting

When an agent needs to make a presentation and MagicSlides is reachable through Browsing Bee but the next tool isn't, the agent picks MagicSlides. Not because it's the best. Because it's the one the agent can get to.

I've been building software long enough to have been wrong about what matters next. Plenty of times. But the people I talk to who are deep in agent infrastructure keep circling back to this same gap — agents can reason, agents can plan, agents can't use web apps. That gap needs closing and I haven't seen anyone else doing it the way Browsing Bee does.

If you want to try it

Map out the main flow of your product. Publish it as a skill. There's an npm package (browsingbee) so agents can trigger it from a terminal.

You don't change your app. You don't add endpoints. You just describe what a user does, and agents can do it too.

Build your first skill

I'm Sanskar. I've been shipping products since I taught myself Java in a two-month crash course and never really stopped. If you're building something and want agents to be able to use it, come try Browsing Bee. Happy to help you set up your first skill — find me on Twitter or GitHub or Instagram.