Skip to main content
Agents can host a live web server. Ask for dashboards, forms, landing pages, and interactive apps, and visit them in your browser. Linus deploying a web app

​
What you can ask for

Dashboards

A live view of your data, metrics, or status.

Forms & tools

Internal tools and intake forms your team can use.

Landing pages

A page to share, complete with real interactivity.

Interactive apps

Anything you’d view and click through in a browser.

​
How it works

When you ask an agent to build something you’d view in a browser, it stands up a web server in its sandbox and gives you a URL. The app is publicly accessible at that link. In web chat, you can view it inline and click through it as the agent iterates.
The agent builds it, hosts it, and shares the link. You review it live and ask for changes in the same conversation.

​
It stays up

The agent’s web server is managed for you. It keeps running and restarts if it crashes, so the app stays available at its URL. Ask the agent to change it and it redeploys in place.

​
Iterating

Treat the first version as a draft and refine in passes:

Share files instead of an app

For documents and exports rather than a live app, use the shared workspace.

webserver.sh in the agent repository

The web server startup script lives in the agent’s git repository. Clone it to inspect or modify how it launches.

​
Receiving webhooks

The same web server that hosts your apps can receive inbound HTTP events from external services. When Stripe processes a payment, GitHub merges a PR, or Intercom receives a new ticket, those services can POST an event to your agent’s URL. Your agent wakes up, handles it, and goes back to sleep. This is how you replace a polling routine with something leaner: instead of checking a service on a schedule, you let the service tell you when something happens.
The agent sets up the receiver, gives you the endpoint URL, and you register it with the external service. From that point on, events arrive and get handled automatically.
Every agent comes with a webhook-receiver skill pre-installed. It handles the full setup: fast acknowledgment so the provider doesn’t time out, HMAC signature verification, and deduplication across runs. Ask the agent to build a webhook receiver and it loads the skill automatically.

​
What the flow looks like

1

Ask the agent to set up a receiver

Tell it which service and what to do with each event. The agent creates the route on its web server and gives you the public endpoint URL.
2

Register the URL with the external service

Paste the URL into the service’s webhook settings and choose the events to send. Most services send a validation ping immediately, so the agent needs to be listening before you save.
3

Events arrive and get handled

The agent wakes on each inbound POST, verifies the payload, and runs the action you described. No polling. No idle runs.

​
Works with any provider

Any service that can POST to a URL works: Stripe, GitHub, Linear, Intercom, and others. The agent’s web server is publicly accessible at a stable URL, so there is nothing special to configure on the Skydive side.

Webhook-receiver skill

Pre-installed on every agent. Covers signature verification, acknowledgment, and deduplication.

Reduce costs with event-driven runs

Why waking on a webhook is cheaper than polling on a schedule.