Talking to your agent
What to say to get what you want, what your agent can do on agenthost, and the few things it can't.
There is no command syntax here. You ask in your own words and your agent works out which tools to call. Still, some phrasings save a round trip — and it's worth knowing where the edges are.
Things that work
| What you want | What to say |
|---|---|
| Put something online | "put this online" — add "call it X" if you care about the name |
| Update what's live | "deploy that again" or "push the changes" |
| Check on it | "is it actually up? open the link" |
| Understand a failure | "read the agenthost logs and tell me what's wrong" |
| Your own domain | "put it online at app.mydomain.com" — say this when it's created |
| Keep it private | "only let anna@company.com and me open it" |
| Add a secret | "set STRIPE_KEY on the app to this value" |
| Tidy up | "list everything I have on agenthost", then "delete the ones from last month" |
| Bring in a colleague | "invite sam@company.com to my agenthost account as an admin" |
| Know who you are | "who am I on agenthost?" |
Be specific about two things
Which thing. If your agent has several projects open, name the folder or the app. "Put the
./landing folder online" is unambiguous; "put it online" after ten minutes of unrelated work is
not.
Public or private. Apps are public by default — anyone with the link can open them. If it matters, say so in the same sentence you ask for the deploy.
Ask it to prove it
The single most useful habit: don't accept "deployed" as an answer.
open the URL and tell me what it returns
A deploy can be queued, report as running, and still be crash-looping. A real HTTP response is the only pass condition, and your agent can fetch one. Agents connected to agenthost are told this, but asking costs you nothing.
What your agent can do
Everything agenthost offers is a tool call, and your agent has all of them: create and delete projects, create apps, deploy new versions, read status and logs, list the names of environment variables, control who can open an app, invite people to your account, and mint API tokens. The full list is the toolbelt.
What it can't do
Worth knowing so you don't ask twice:
- Change an app's address after it's created. Decide the domain when the app is made. To move an existing app, your agent deploys it again as a new app on the new address and deletes the old one. See Use your own domain.
- Add DNS records for you. Those live at your registrar. Your agent hands you the exact record to add, in plain terms.
- Roll back to an earlier deploy. There's no "undo" tool. Your files are on your side — if you keep them (or use git), redeploying an earlier copy is one more request.
- Restore something it deleted.
delete_appanddelete_projecttear things down for real. Deleting a project takes every app in it. - Switch to another organization mid-conversation. A connection belongs to one organization. To work on another, connect the client again and pick that one when signing in.
When it gets stuck
Agents guess at parameters that don't exist. The two that come up most:
- There is no start command and no port setting. How an app starts is fixed per runtime. If your agent is trying to pass one, point it at Runtimes.
- Passing an unknown field is silently ignored rather than rejected, so a wrong guess looks like it worked. If a deploy behaves as though a setting was ignored, it was.
You can also just hand it the docs: every page here is available as plain markdown at the same path
under /llms.mdx/docs, and /llms.txt indexes the lot.