Configure

---
name: configure-590ec49c38c6
description: 'Use when the user wants to create, modify, or manage AI agents, custom tools, LLM configurations, or data source connections. Triggers: create agent, configure agent, clone agent, publish agent as tool, export agent, import agent, share agent, create HTTP tool, create SMTP tool, add tool, configure LLM, bring your own model, BYOM, add data source, create connection, parameter bindings, tool authentication, set up agent, set up tool, manage LLM credentials. Key signal: if "set up" refers to infrastructure (agents, tools, LLMs, connections), use this skill. If "set up" refers to scheduling or automation, use automate. Not for scheduling or workflows — use automate. Not for creating data products — use curate.'
---

# Configure

Create and manage agents, tools, LLMs, and data source connections.

## Routing

| User Intent | CLI Command | When to Use |
|---|---|---|
| Manage AI agents | `scripts/run-cli agent` | Create, clone, update, delete, publish, export, import agents |
| Manage tools | `scripts/run-cli tool` | Create HTTP/SMTP tools, update, delete |
| Manage LLMs | `scripts/run-cli llm` | BYOM setup, credentials, LLM configs |
| Manage data sources | `scripts/run-cli datasource` | Create, update, delete data source connections |

## Not This Skill

- User wants to **schedule or automate** workflows → use `automate`
- User wants to **query data** or chat with an agent → use `ask`
- User wants to **create a data product** → use `curate`
- User wants to **browse** data source contents → use `explore`

Key distinction: `configure` creates and manages the infrastructure (agents, tools, LLMs, connections). `automate` uses that infrastructure in workflows. "Create an SMTP tool" is `configure`. "Set up a daily email report" is `automate`.

## Agent Configuration

### Creating an Agent

1. **Define the agent's purpose.** What should it do? Be specific — "answer sales questions against the superstore dataset" is better than "answer questions."

2. **Identify the data and context it needs.** What data products, data sources, or domain knowledge will the agent work with? Some of this becomes fixed tool bindings (step 5), some goes into the agent prompt (step 6).

3. **Select tools.** Browse available tools with `scripts/run-cli tool list` and see `references/default-tools.md` for the selection matrix. Pick the combination needed for the agent's purpose. If a required tool doesn't exist (e.g., an HTTP or SMTP integration), create it first — see Tool Configuration below.

4. **Create the agent config** with the selected tools:
   `scripts/run-cli agent create < config.json`
   Tip: if a default agent is close to what you need, clone it as a starting point:
   `scripts/run-cli agent clone ID`

5. **Configure tool parameter bindings.** Bindings control how tool parameters get their values at runtime, constraining what the agent can do for reliability and consistency. For each tool parameter, choose a binding source:
   - **`fixed`**: The value is always the same. Use this to lock a tool to a specific resource like a `data_product_id`. The agent can't change it.
   - **`user`**: The caller provides the value when invoking the agent. Use for things like a recipient email or a `data_product_id` when the agent supports multiple products.
   - **`agent`**: The LLM decides the value based on the conversation. This is the default for most parameters — the agent interprets the user's message and figures out what to pass to the tool. For example, `data_product_id` can be agent-determined if the agent has a search tool and is expected to find the right product itself.

   Some parameters are hidden from the model (`x-hidden-from-model: true`) and must be `fixed` or `user` since the LLM can't see them to decide.

   See `references/bindings.md` for JSON structure, validation rules, and detailed patterns.

6. **Configure the agent prompt.** Describe the agent's high-level goal, its domain context, and when to use each of its tools. This is the agent's system prompt — it guides the LLM's behavior.

7. **Choose the LLM.** Pick a model powerful enough for the task. See `references/default-llms.md` for recommendations by use case.

8. **Test the agent.** Use the **ask** skill to send it a message and verify it works:
   `echo '{"message": "..."}' | scripts/run-cli chat send <agent_uuid>`

### Publishing as Tool
`scripts/run-cli agent publish ID` makes an agent callable by other agents.

### Exporting and Importing Agents

Export an agent's configuration as portable JSON that can be imported on another instance:

1. **Export:** `scripts/run-cli agent export ID` — outputs the agent config as JSON including LLM, tools, and parameter bindings.
2. **Import:** `scripts/run-cli agent import < export.json` — creates a new agent from the exported JSON. Resolves LLM and tool references to the current instance's equivalents.

Import returns warnings if any tool or parameter binding may need manual review (e.g., custom tools that don't exist on the target instance, or fixed parameter values that are instance-specific). Agents with warnings are created in DRAFT status.

## Tool Configuration

### Creating HTTP Tools
See `references/http-tools.md` for full guide. Key constraints:
- HTTPS only (no HTTP, no localhost, no IP addresses)
- Auth types: API_KEY, BEARER, BASIC, OAUTH2, NONE

### Creating SMTP Tools
See `references/smtp-tools.md` for provider-specific configs (SendGrid, AWS SES, Gmail, M365).

**Important:** Before creating a new tool, always list existing tools first with `scripts/run-cli tool list`. An SMTP or HTTP tool may already be configured.

## LLM Configuration (BYOM)

1. **Create credentials:** `scripts/run-cli llm creds-create < creds.json`
   See `references/credentials.md` for provider-specific formats (API_KEY, AWS, AZURE, GCP).
2. **Validate:** `scripts/run-cli llm creds-validate ID --provider PROVIDER --model MODEL`
3. **Create LLM config:** `scripts/run-cli llm create < config.json` referencing the credential ID. See `references/providers.md` for provider model details.

## Data Source Management

- `scripts/run-cli datasource list` / `scripts/run-cli datasource get ID` / `scripts/run-cli datasource create` / `scripts/run-cli datasource update ID` / `scripts/run-cli datasource delete ID`
- Note: connector setup, MDE, and QLI configuration require the Alation web UI.

## Common Mistakes

**Mistake:** Copying a data product's full spec into the agent prompt to "teach" it about the data.
Why it seems reasonable: the agent needs to know what data is available.
Instead: Set `data_product_id` as a `fixed` parameter binding on the agent's tools. The tools will fetch the product context at runtime. See `references/bindings.md` pattern 1.

**Mistake:** Creating a new SMTP tool when one already exists.
Why it seems reasonable: the user asked to send email.
Instead: Run `scripts/run-cli tool list` first. Look for existing tools with `tool_type: "SMTP"`.

**Mistake:** Asking the user for an API token or credentials during agent/tool creation.
Why it seems reasonable: auth might seem like a per-operation concern.
Instead: Authentication is handled automatically by credentials.local. If auth fails, direct the user to the `setup` skill.

**Mistake:** Guessing at agent, tool, or LLM config fields when the API rejects a payload.
Why it seems reasonable: the validation error usually hints at the fix.
Instead: Check the documented request schema via the `docs` skill before retrying.

## Next Steps

After finishing configuration, suggest next steps to the user — but don't proceed without their go-ahead unless their original request already implies it.

- **After creating an agent or tool:** Share the `url` from the CLI response so the user can view it in the Alation UI.
- **After creating an agent:** Always offer to test it by sending a message via the **ask** skill. Then suggest scheduling it with the **automate** skill if relevant.
- **After creating a tool:** Suggest adding it to an agent (using this skill) or wiring it into a workflow (using the **automate** skill).

## Red Flags
- "I'll add the product schema to the agent's system prompt" — use parameter bindings instead.
- "I need to create an SMTP tool" — check if one exists first.
- "What's your API token?" — credentials come from credentials.local, not the user.