agentify

Files (1)

• SKILL.md

SKILL.md (first lines)

## Agentify

Turn a workflow, task, or idea into a deployed agent on belt. Agents get a model, system prompt, optional MCP tools, skills, and callable API tools — then run via `belt agent run` or the inference.sh API.

### When to use

- The user wants to create a new agent from scratch
- A working workflow should become a persistent, callable agent
- The user says "agentify", "make an agent", "create an agent", "build a bot"
- A skill or manual process would benefit from tool access (APIs, MCP, integrations)

### Key concepts

**Context variables** are runtime inputs passed via `--context key=value`. They appear in the agent's conversation as structured context the model can read. Use them in `call` tool URLs with `{{context.var_name}}` template syntax. In system prompts, just reference them by name — the model receives them automatically.

**Internal tools** default to all OFF when omitted from the YAML. Set explicitly:
- `memory: true` — agent can store/recall knowledge across conversations
- `plan: true` — agent can create and track execution plans
- `widget: true` — agent can render UI widgets

**MCP tools vs call tools**: MCP tools connect to external services via OAuth (Todoist, Linear, Slack). Call tools are direct HTTP requests to any API with bearer auth.

**Client tools** (`type: client`) are declared by the agent but executed by the frontend — for acting on live UI state the server cannot see. See the client tools section below; the schema nesting there is easy to get wrong and fails silently.

### Process

#### 0. Analyze the conversation first [MANDATORY]

Before asking anything, review what happened in this conversation. Look for:
- Multi-step workflows that were executed (API calls, deployments, configurations)
- Repeatable patterns that could run autonomously
- Tool sequences that could be packaged into an agent

If you find workflow candidates, present them to the user:
> "Based on this session, here's what could become an agent:
> 1. **<name>** — <what it would do>, triggered by <what>
> 2. **<name>** — <what it would do>, triggered by <what>
> Which one should we build? Or describe something different."

Only ask "what kind of agent?" if the conversation has no workflow context.

#### 0.5. Learn from a working agent [recommended]

Pull an existing agent to see what real YAML looks like:

```bash
belt agent list
belt agent pull <namespace/agent-name> --save /tmp/reference-agent.yml
```

Read the YAML — it shows the exact field names, structure, and how tools are defined.

#### 1. Define the agent's purpose

From the conversation analysis or user input, pin down:
- **What does this agent do?** One sentence.
- **What inputs does it need?** These become context variables.
- **What tools does it need?** MCP servers, API calls, or built-in tools.
- **What model should power it?** List the catalogue — `belt app store -c chat` (add `--new` for newest first, `-q claude` to filter, `belt app get <ref>` for context window and pricing). Do not work from a remembered ref: models ship faster than any written list stays true. Use the provider's own namespace — `anthropic/*` and `google/*` are direct API apps, and reaching the same Claude model through `openrouter/*` only adds a third party; OpenRouter is for the open-weight families (GLM, Kimi, Qwen) that have no first-party app. Refs are not guessable from the marketing name — `anthropic/claude-haiku-4-5` and `anthropic/claude-haiku-45` both exist, and suffixes vary between `-4-8` and `-46` styles, so copy the ref from the listing.

#### 2. Check for existing agents

```bash
belt agent list
```

If a similar agent exists, pull and review it:
```bash
belt agent pull <namespace/name> --save /tmp/existing-agent.yml
```

#### 3. Set up tools

**For MCP tools** (Todoist, Linear, Slack, GitHub, etc.):

First, connect the MCP server. This opens a browser for OAuth:
```bash
belt mcp search "todoist"              # find the server
belt mcp connect <server-slug>         # opens browser for OAuth
```

After connecting, get the integration ID — you'll need it for the YAML:
```bash
belt integrations list --json          # find the "id" field for your integration
```

The `id` field (e.g. `46e8a4bqj9ddx8gmana01b2shq`) is what goes in the YAML as `integration_id`.

Then list available tools:
```bash
belt mcp tools <server-slug>           # only works after connecting
```

**For call tools** (direct HTTP APIs):

Set up secrets for API authentication:
```bash
belt secrets set my_api_key sk-12345
```

No connection step needed — call tools are just HTTP requests defined in the YAML.

**If `belt mcp connect` requires a browser** and you're in a headless environment, tell the user they need to run `belt mcp connect <slug>` in their local terminal first.

#### 4. Write the agent YAML

**Minimal agent** (no tools):

```yaml
name: my-agent
description: what it does in one line
core_app:
  ref: anthropic/claude-sonnet-5   # example only — list the store for current refs
system_prompt: |
  You are a helpful assistant that does X.
  When the user asks Y, do Z.
```

**Agent with context variables**:

From belt-sh/skills, MIT.

More from belt-sh/skills