Recipes for agents

The two setups people actually want, written as the sequence of tool calls that completes them. Neither needs a dashboard and neither needs you to paste a credential into a conversation.

Give my app a database #

1. kraftify_ceiling()
2. kraftify_create_target(name: "app-db", kind: "postgres", size: "small")
3. kraftify_set_env(target: "app-db", key: "DATABASE_URL")
4. run your migrations against the connection string the agent already has

Step 3 is the one people leave out. Skip it and the app has a database it cannot reach.

Host the multiplayer game I just wrote #

1. kraftify_create_target(name: "my-game", kind: "minecraft", size: "medium")
2. kraftify_start(target: "my-game")
3. kraftify_logs(target: "my-game")   # streamed, never stored

The same three calls, the same ceiling, the same approval behaviour. That is the entire claim of the product: a database and a game server are two rows in one list, and an agent does not need to know which is which.

Put something else in a box #

1. kraftify_create_target(name: "api", kind: "container", size: "small")
2. kraftify_start(target: "api")

Rules worth giving an agent #

• Start read-only. Five tools, no writes, and you can see what the agent can see before it can do anything.
• Let it read the ceiling. An agent that knows the cap can tell you when a request is too big instead of discovering it by failing.
• Do not give it tokens:write. A token that can mint tokens is an agent that can outlive your session.
• Do not give it console write. We do not expose it, and that is not an oversight.