DEV Community

Sebastian for epilot

Posted on

Building epilot Apps from your terminal, with a little help from AI agents

A few months ago we shipped the epilot CLI, and it quietly became one of my favorite tools. One command, npx epilot, gives you every single epilot API operation in your terminal: entities, journeys, workflows, pricing, files, permissions, 50+ APIs.

Interactive pickers if you're exploring, --json and --no-interactive if you're scripting.

It also turned out to be a perfect match for AI agents like Claude. Agents are great at driving CLIs: they discover operations, read the help, make calls, parse the JSON. No custom integration or MCP server needed, the CLI is the integration. And because handing an agent live CRM access is a scary idea, the CLI ships with two safety nets, both enforced server-side:

# A session that physically cannot write. The restriction is baked
# into the token, so the bearer can't turn it off.
epilot auth login --readonly

# A token that additionally gets all PII anonymized in every response
epilot access-token createAccessToken -d '{
  "name": "AI agent token",
  "read_only": true,
  "anonymize": true
}'
Enter fullscreen mode Exit fullscreen mode

Read-only plus anonymized means an agent can explore, analyze and report on your real org all day, and the worst it can do is read data it can't even de-anonymize.

Now we've made the CLI even better. On top of the raw API commands, we added app facades: a set of high-level epilot app commands that take you from an empty folder to a working app installed in your org. And that's what this post is really about, because apps are where the fun is.

What are epilot Apps?

epilot is very configurable out of the box: journeys, workflows, automations, pricing. But at some point every team hits a wall, something the UI simply doesn't offer.

  • A custom tab on the contact or opportunity page showing data from your own systems
  • A whole custom page in the epilot navigation
  • Your own block in the journey builder
  • A widget in the end-customer portal
  • A flow action that calls your API when a workflow step runs
  • An external product catalog or an API proxy to your backend

That's what Apps are for. They extend the platform with your own UI and logic, running right inside the product. Everything an app is (its components, configuration and assets) is described in a single manifest.json.

Until now, getting from "I have an idea" to "it's running in my org" meant a fair amount of manual manifest-wrangling. The App CLI turns it into four steps.

Step 1: Scaffold a project

epilot app init my-app
cd my-app
Enter fullscreen mode Exit fullscreen mode

You get a ready-to-go monorepo: the manifest.json, a components/ folder, build tooling already wired up, and a SKILL.md with instructions written specifically for AI agents (more on that in a minute).

Step 2: Add components

epilot app add-component
Enter fullscreen mode Exit fullscreen mode

An interactive picker lets you choose what to build:

  • Custom entity tab / widget (CUSTOM_CAPABILITY)
  • Custom page in the navigation (CUSTOM_PAGE)
  • Custom journey block (CUSTOM_JOURNEY_BLOCK)
  • Custom portal block (CUSTOM_PORTAL_BLOCK)
  • Custom flow action: sandboxed JS inside epilot, or an external webhook
  • Portal extension, external product catalog and API proxy as config-only integrations

Each choice lands as a working component from the epilot-dev/app-templates repo, registered in your manifest, ready to build.

Step 3: Develop against the real product

epilot app dev --component my-tab
Enter fullscreen mode Exit fullscreen mode

This is my favorite command: it serves your component from localhost inside the actual epilot UI. You edit code locally, hit refresh, and see your tab or widget rendered in the real product, with real data, next to real features. No deploy loop while iterating. When you're done, epilot app dev --off removes the override.

Step 4: Validate and deploy

epilot app validate
epilot app deploy --dry-run   # see what would change
epilot app deploy             # ship it
Enter fullscreen mode Exit fullscreen mode

deploy reads the manifest, creates or updates the app, uploads your built assets, and handles versioning for you. If the latest version is already public (and therefore locked), it automatically creates a new one. epilot app versions shows the history.

The best part: let an AI agent build it

Here's where the two halves of this story click together.

Remember the SKILL.md that epilot app init scaffolds? It teaches AI agents the project structure, the manifest format, and the full workflow. Claude Code picks it up automatically. So building an epilot App in 2026 actually looks like this:

epilot app init my-app && cd my-app
claude
Enter fullscreen mode Exit fullscreen mode

Then you describe what you want in plain language:

"Add a custom tab to the contact page that shows all meters linked to the contact, with their last readings in a table."

And the agent takes it from there:

  1. Reads SKILL.md to understand the project
  2. Runs epilot app add-component to scaffold a custom entity tab
  3. Uses the epilot CLI (with your read-only, anonymized token) to inspect your real entity schemas, so the code matches your actual data model instead of a guess
  4. Writes the component code
  5. Starts epilot app dev so you can watch it live inside epilot
  6. Finishes with epilot app validate and epilot app deploy

You review, the agent types. And this isn't just a developer workflow: colleagues who wouldn't call themselves engineers have shipped working apps this way. The CLI does the heavy lifting, the agent does the plumbing, and the human decides what to build.

Try it

npx epilot --help              # explore the CLI
epilot auth login --readonly   # safe mode for agent sessions
epilot app init my-first-app   # start building
Enter fullscreen mode Exit fullscreen mode

If you build something with it, or let Claude build something with it, I'd love to hear how it goes. 🚀

Top comments (0)