How to Be the Default App of the Future: Building for AI Agents

How to Be the Default App of the Future: Building for AI Agents

The new workforce is going to be AI agents. I've been building products for more than 4–5 years now, and I'm now focusing on making my products usable by AI agents so they can call them, not just humans. Along the way I've learned a few things that I wish I'd known earlier. This post is so you don't have to face the same friction—you can get a head start.

Here’s what I’ve learned about making your product the one agents choose by default.

1. Whatever Your Product Is, Give It a CLI

A CLI turns your product into something that can be run from the terminal. For most products, that means publishing an npm package. Once you do that:

  • People can use your product via terminal commands.
  • On Windows, they can call your product from scripts and automation.
  • Claude Code and other agents can invoke it directly instead of having to “use the browser.”

So step one: create a CLI for your product. If your product is web-only, agents have to simulate clicks and forms. If it’s a CLI, they run one command and get a result. That’s the future you’re optimizing for.

2. Create a Skills File and Get Listed on skills.sh

When your product has a CLI, the next step is to make it discoverable and installable for agent users. That’s where skills files and skills.sh come in.

  • You can literally prompt Cursor or Claude Code with something like: “I’m trying to create a skill for the skills.sh platform—convert this CLI into a skill.” It will generate the right files for you.
  • Then run the commands they give you (e.g. npx skills ...) to get your CLI listed on skills.sh.
  • Once it’s listed, share it with friends and early users and ask them to install it. More installs help you show up in the “hot” or “top” lists, which drives more agent usage.

Think of skills.sh as the place agents (and their users) look for tools. Being there, with a clear skill definition, is part of being the default app of the future.

3. One Shot, Not Step-by-Step: Single-Command CLI

A lot of CLIs work like wizards: they ask “What is the name?”, “What is this?”, “What is that?” in a step-by-step flow. That’s terrible for agents.

Avoid:

  • Step-by-step prompts (like npx create-next-app or some npm init flows).
  • Anything that requires multiple back-and-forth answers.

Do this instead:

  • Make your CLI flag-driven: -key value (or --key value) so that everything can be passed in one command.
  • Example: one call with topic, format, and output path—no interactive prompts. Claude Code and other agents can then call it with a single query and get the result without “figuring out” the browser.

Our whole goal is to make the CLI easier and faster for agents to use than opening a browser and clicking through your UI. Single-command, non-interactive usage is how you get there.

4. Surface Your CLI Where AI Can Find It: Your Website

If you already have a website with some traffic and indexed pages, use it to signal that your product has a CLI. I’ve started listing my CLIs clearly on my site (e.g. Ask Video (askvideo.ai), Magic Slides CLI (magicslides.app), Slide Downloader (slidedownloader.com)) so that:

  • Humans can find and copy the install commands.
  • In the long run, crawlers and AI might use that same information to discover and recommend your tool.

I don’t have hard data yet that “AI reads my site and uses the CLI more,” but it’s low effort and aligns with making your product the default: if you don’t share the CLI, nobody—human or agent—will use it. So add a section or page that shows:

  • What the CLI does.
  • How to install it (e.g. npx your-package or global install).
  • One or two example commands.

You can grab the HTML/component structure from my site, paste it into Claude Code or Cursor, and ask it to recreate a similar block for your product. The main thing is: make the CLI visible and shareable.

5. Expose Your Core Features Through the CLI

A CLI that only does one tiny thing is better than no CLI—but to become the default app for a use case, agents need to do the main jobs your product does, from the terminal.

For example, for MagicSlides, the CLI should support at least:

  1. Create presentations (e.g. from topic, URL, or file).
  2. Edit presentations (update slides, content, etc.).
  3. List presentations (so agents can choose which one to edit or share).
  4. Account lifecycle: sign up (e.g. email + password), delete account.

A few implementation notes that bit me:

  • Sign up via email/password: If you use something like Supabase, turn off the “require email verification before login” option (or provide a way for the CLI to work with unverified signups during development). Otherwise agent-driven signups get stuck waiting for a verification email.
  • Credit limits: If you have free vs paid usage, enforce credit limits in the API/CLI so that free usage is limited and paid usage is clear. One of my products (Slide Downloader) has near-zero marginal cost, so I offer unlimited free use; for MagicSlides I use credits. Either way, handle limits explicitly so people (and agents) can’t accidentally overuse and so you can monetize later.

The principle: whatever the main actions are in your product, the majority of them should be available through the CLI. Then agents can replace “open the app in the browser” with “run the app from the terminal.”

6. Make Your Code Safe for Public Consumption (Especially on npm)

When you publish to npm, your package page often links to your GitHub repo. Many developers (and future tooling) will look at that repo. So:

  • Make the repo public (if you want maximum discoverability and trust).
  • Treat the code as public from day one: no API keys, no secrets, no internal URLs or credentials. I wrote a lot of my CLI code with AI and then had Cursor (or another tool) check: “Is this code ready for public consumption? Any private information?” I fixed what it found before pushing.

You don’t have to be an expert in every line—I’m not—but you do need to be sure nothing sensitive is in there. One leak can hurt trust and security; clean, public-ready code helps you become the default app agents recommend.

7. Share the CLI Everywhere

Creating a CLI is useless if nobody knows it exists. So:

  • Website: Install instructions and examples (as in point 4).
  • Documentation: Same commands, plus maybe a “Quick start for agents” section.
  • Community: Post in relevant dev/indie/agent communities (e.g. Reddit, Indie Hackers, X/Twitter) with a clear one-liner: “You can now use [Product] from the terminal and from Claude Code.”
  • skills.sh: Already covered—get listed and encourage installs so you rank better.

The goal is: when someone (or an agent) thinks “I need to do X,” your product’s CLI is easy to find, install, and run in one command.

Summary: How to Be the Default App of the Future

  • CLI first: npm package, terminal-usable, so agents can call you without the browser.
  • Skills file: Get on skills.sh, get installs, get into the “hot” list.
  • Single-command UX: Flags, not wizards—so agents can use you in one shot.
  • Website: List your CLI and install steps where your traffic already is (and where crawlers/AI might see it).
  • Feature parity: Major actions (create, edit, list, sign up, delete, etc.) available via CLI; handle signup (e.g. Supabase email verification) and credit limits so agents don’t get stuck.
  • Public, clean code: Repo ready for npm/GitHub—no secrets, no private info.
  • Share everywhere: Docs, site, community, skills.sh—so humans and agents can find and use your CLI.

The new workforce is AI agents. Build so they can use your product in one command—and you’ll be much closer to being the default app of the future.