Skip to main content
Agents are defined as YAML files committed to your repo under .dinoai/agents/. Each file defines one agent.
The agent builder in the app writes this same format: when deploying from Creating Agents in the App you choose whether the agent is saved to the workspace only or committed to your repo with this schema through a pull request.

Full Example

To review pull requests with an agent like this one, pick it as a custom reviewer in DinoAI Code Review. Give it its own name: pr-reviewer is the name of the reviewer that Paradime manages. Either way, Paradime posts the review, so the agent doesn’t need Slack or a GitHub Actions workflow.

Field Reference

Slack output

When slack.channel is set, two optional fields decide how the agent posts there. You can also set them on the Output step of the agent builder. slack.answer_in decides where the agent answers:
  • thread (default): the run opens a thread with a “Starting agent” message, and the agent answers in that thread.
  • channel: there is no starter message. The agent’s first message is posted to the channel as a message of its own, and later messages go into its thread. Mention @Paradime in that thread to follow up. Use this for agents whose answer is the news, such as a daily report.
slack.updates decides what the agent posts:
  • all (default): the agent posts its progress as it works.
  • final: the thread shows one “Working on it” status, then only the agent’s last message of the turn. Questions, approval requests, and notices that a run failed or stopped still post. Warnings stay out of Slack.
The agent’s Slack thread tools, find_slack_thread and attach_session_to_slack_thread, work only in the agent’s own channels: the one in slack.channel, and the channel its session is bound to. An agent with neither can use them in any channel the Paradime bot is in.
Important: If the tools block is omitted entirely, the agent has access to all available tools. Use an allowlist for production agents to limit blast radius.

Tool Modes

allowlist — only the tools listed are available to the agent. Recommended for production agents.
denylist — all tools are available except the ones listed.
A small set of core tools is always available regardless of mode: an allowlist does not need to name them, and a denylist cannot remove them. See Always-available tools. Sub-agents started with run_subagent inherit the parent agent’s tool gating.

MCP tools

List tools from external MCP servers under tools, like any other tool. MCP tool names look like mcp__<server>__<tool>, and mcp__<server>__* matches every tool from one server. Without a tools block, or with a denylist that doesn’t name them, the agent gets every MCP tool its server and environment allow. The separate mcpTools block that agents used to limit MCP tools is deprecated. If an agent still has one, it keeps limiting the agent’s MCP tools on top of tools.