# 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.

> If a routine runs unattended, pre-approve only the read-only tools it needs. A routine that cannot ask for approval should stop and report a recommendation rather than attempt a write.