Skip to main content
You don’t have to hand-write agent YAML. Describe what the agent should do and DinoAI drafts it, or pick a template, or start from scratch. Then review the agent in the builder and deploy. When you deploy, you choose where the agent lives: saved to the workspace only, or written to your repo as .dinoai/agents/<name>.yml through a pull request.

​
The Agents page

Open DinoAI Agent from the left navigation and select Agents. The list shows every agent available in the workspace, whether it was built here or defined as YAML under .dinoai/agents/ in your repo. Each row shows the agent’s role, model, tools, squad, whether it was Deployed from UI or Deployed from Git, and when it last ran. Use Search agents… to filter by name or role. From this page you can:
  • New agent: describe a new agent, or pick a template.
  • Chat: start a new interactive session with that agent. Your first message starts the run; the agent clones the repository and works from there.
  • Schedule: jump straight to a new Bolt schedule with the Run DinoAI Background Agent command already added and the agent pre-selected, so you only need to describe the task. See Triggering from Bolt.

​
Describe the agent, or start from a template

The new agent page asking What should your agent do?, with a box to describe the agent, connected tool icons, and templates below under Or start from a template
Clicking New agent opens What should your agent do?. Describe the job in plain words and press Enter, for example: when a Bolt run fails, read the logs, find the model that broke and post the cause in #data-alerts. DinoAI drafts the agent and opens it in the builder with Name, Role, Goal, Backstory, and Allowed tools filled in. The tools come from the integrations your workspace has connected, including tools from your MCP servers. If the job needs an integration that isn’t connected yet, a notice in the builder names it, with a link to Connect integrations. Nothing is saved until you deploy, so review the draft and change anything you need first. Drafting uses your DinoAI credits. If the draft fails, the builder shows the reason DinoAI gave. Under Or start from a template, templates pre-fill the agent’s identity for you and are grouped by category (Reliability, Quality, Cost, Code review, Documentation, Analytics). They include ready-made starting points like bolt-pipeline-healer, incident-responder, freshness-watchdog, test-failure-analyst, warehouse-cost-optimizer, dbt-model-reviewer, docs-writer, and analytics-responder. Pick Start from scratch for a blank agent where you write the role, goal, and backstory exactly how you want.

​
The builder

The builder walks you through the same fields you would otherwise write in YAML. A checklist in the left rail tracks which sections still need attention.

​
Identity

  • Name: becomes the filename under .dinoai/agents/ and how you invoke the agent from Bolt, the API, or chat.
  • Role: who the agent is, in one line.
  • Goal: what a successful run achieves.
  • Backstory: context and instructions for every run, such as who to add as Jira watchers when creating issues.

​
Model

The Model section of the DinoAI agent builder listing model presets with their relative cost, and the selected OpenAI preset showing its main, sub-agent, and planning models
Pick the model preset the agent runs on, called a model family in the agent YAML and the API. A preset is a named set of three models: one for the agent’s main turns, one for the sub-agents it spawns, and one for planning. Each row names the preset and its cost tier, Economy, Standard, or Premium, taken from its main model; selecting one shows the three models it maps to. Presets are named by provider, such as Anthropic, OpenAI, or Grok, or by intent, such as Fast, Deep, or Open weights, so you can choose on capability or on price. See Model families for the current presets. One preset is marked Default: leave it and the agent follows the workspace default as the lineup changes; pick another and the agent is pinned to it. Workspaces with no presets configured see a single Auto option instead, and Paradime picks the models. The family is resolved when a session starts, so editing an agent while a run is in flight cannot move that run onto different models. Each session’s header shows which family it actually used. A run triggered over the API can override the agent’s family with a modelFamily argument. An unrecognized family never fails the run: it starts on the workspace’s default family instead, and the mutation returns a warning saying which family it used.

​
Environment

Pick the Agent environment the agent runs in. An environment carries a warehouse connection, a dbt™ version, and a partial parsing setting, so this decides what the agent connects to and what it runs dbt™ with. Leave it on Workspace default and the agent follows the workspace’s default Agent environment, writing no environment field to the YAML. Pick a named environment and the agent is pinned to it, which is how you hold one agent on a newer dbt™ version than the rest of the workspace, or point it at a warehouse role scoped for agent work. Its SQL tools run through the same connection. The environment is resolved and pinned before the agent’s runtime starts, so the dbt™ version takes effect for the whole session. A session already in flight keeps the environment it resolved, so editing the agent mid-run cannot move it.
An environment that no longer exists is treated as an error, not a fallback. The builder blocks the deploy until you choose another, and a session whose environment slug cannot be resolved fails at startup rather than quietly running somewhere else. This is stricter than the model preset, which does fall back to the default and warn.
Manage these under Settings → Environments → Agent, where each environment carries its own connection, dbt™ version, and dbt™ partial parsing toggle. See Agent environment.

​
Tools

Control which tools the agent may reach for:
  • Allowed tools: only these, everything else is refused.
  • Denied tools: everything the workspace allows, except these.
  • Leave both lists empty and the agent inherits the workspace’s tool permissions.
The picker lists the agent runtime’s actual tools, grouped by area (dbt™ Discovery, Orchestration, Repositories, Slack, your connected warehouse, and more), and only offers integrations your workspace has connected. A set of core tools (file reading, code search, skills, sub-agents, plan mode, and the Paradime docs tools) is always available, so the builder shows them as fixed rather than offering them as a choice. Each connected MCP server has its own group in the picker. Its first option, such as All Looker tools, covers every tool on that server, and the options after it pick single tools. If the agent’s definition still has a separate mcpTools list, the section shows a notice with a Remove button. That list keeps limiting the agent’s MCP tools until you select Remove and deploy, so add the MCP tools the agent needs to the lists above first. See the Tools Reference for what each tool does.

​
Change the agent with a prompt

The box under the form takes a change in plain words, such as also check source freshness first. DinoAI updates only the fields the change needs and marks each changed section with a dot (Updated by DinoAI). Select Undo to put back the fields you haven’t edited since.
  • While DinoAI works, the fields and Deploy are locked.
  • DinoAI doesn’t change the agent’s model, environment, output channel, or squad, and it keeps the agent’s name once it has one.
  • It changes tools only when the agent already has an Allowed tools list, or when the form is blank.
  • DinoAI reads the agent as it is in the form, unsaved edits included, so a change builds on your latest version.
  • Each change uses your DinoAI credits. There is no length limit on the prompt or the agent.
  • If a change fails, the builder shows the reason DinoAI gave.

​
Output (optional)

Pick a Slack channel the agent posts its results to. Leave it empty and the agent replies wherever it was invoked (the Bolt run log, the API session, or the chat).

​
Squad (optional)

Select other agents this one can delegate to. Each sub-agent runs in its own session and reports back. See Agent-to-Agent Delegation.

​
Deploy

Click Deploy and choose where the agent lives:
  • Just here: the agent is saved to this workspace and is live straight away, with no file in your repo. You can deploy it as YAML later to put it under review.
  • Open a pull request: Paradime commits .dinoai/agents/<name>.yml to a branch and opens a pull request against your default branch. The agent starts working once the change is merged, and from then on it is version-controlled alongside the rest of your project, exactly as if you had written the file by hand.
  • Download the YAML (shown when GitHub isn’t connected): download the file and commit it to your repo yourself.
Choose Just here to iterate quickly, and the pull request route when you want the agent governed as code with review. Both kinds appear in the same agent list and are equally selectable everywhere agents can run, including the Bolt command picker.

​
Run the agent

Once the agent exists you can trigger it from any surface:
  • Chat: click Chat on the agent’s row for an interactive session in the app.
  • Bolt: click Schedule on the agent’s row, or add the Run DinoAI Background Agent command to any schedule. Runs natively, no API keys needed. Give the schedule an incoming webhook to start the agent from another tool’s event, with the request body in its task. See Triggering from Bolt.
  • API, SDK, or CLI: for workflows you orchestrate yourself. See the API Reference.
Sessions from every surface land in the sessions list on the Agent page, labelled by source (Bolt, Slack, API, or chat). See Agent Sessions for following runs, transcripts, and continuing a chat.