Skip to main content

​
Naming and finding agents

Either works. Paradime looks the agent up by slug first, then by name, case-insensitively.
  • The name is what you see in Agent → Agents, so it is usually the easier one to use.
  • The slug is in the agent’s URL. Open the agent and the address reads /agent/builder/edit/<slug>?uuid=…; the path segment is the slug.
Do not try to derive the slug from the name. It is truncated and carries a random suffix, so an agent called DinoAI PR Review might be dinoai-pr-re-18cda0. Copy it from the URL, or just use the name.The slug is minted once and never changes, which makes it the safer reference in anything long-lived.For an agent written as YAML, the name, the slug and the file name under .dinoai/agents/ are all the same string, and the agent refuses to run if its name: field disagrees with its file name.
In one of two places, and both work everywhere an agent can be named:
  • Built in the app — deployed with Just here, the agent is saved to the workspace and is live immediately. There is no file in your repository.
  • Written as YAML — committed to .dinoai/agents/ on your repository’s default branch, either by hand or by deploying from the builder with Open a pull request.
When both exist for the same reference, the workspace copy wins; the repository is the fallback.
So that a branch cannot change the agent that acts on it. For a reviewing agent this is the whole point: a pull request cannot rewrite its own reviewer to be lenient. An agent that exists only on a feature branch is invisible to a run.
The slug does not change, so anything referring to the agent by slug keeps working. If you refer to it by name — in a schedule, an API call or a GitHub workflow — update the reference to the new name, or switch it to the slug so it cannot drift again.
Yes, for YAML agents. One at .dinoai/agents/team-a/pr-reviewer.yml is referred to as team-a/pr-reviewer, and that whole path is what you pass. Useful when several teams keep agents in one repository.
Three things to check:
  1. The reference matches. Compare it against the agent’s name in Agent → Agents. Names are matched case-insensitively, but not fuzzily.
  2. It is deployed. An agent still in the builder, or a YAML agent that only exists on a feature branch, is not visible to a run.
  3. Two agents share a name. An ambiguous name fails rather than picking one, and the error names the slugs so you can pass one of those instead.
Callers differ in what happens next: the DinoAI GitHub Action reviews with its built-in reviewer when you have named no agent at all, but a name that resolves to nothing fails the run rather than quietly substituting something else.

​
Running agents

An agent definition belongs to the repository it lives in, and a run belongs to one workspace. With an account API key you can trigger runs across workspaces with a single key by naming the target workspace per request, but each workspace resolves the agent from its own repository.
Whatever you pass as base_branch: a branch, a tag or a commit SHA. It defaults to the repository’s default branch. Passing an exact commit pins the run to that tree, which is how the GitHub Action reviews precisely the commit under review rather than wherever the branch has moved to.
With the tools allowlist — see the Tools Reference. If the tools block is omitted the agent has every tool. An allowlist is worth it for agents that run unattended, and read-only agents such as reviewers are the obvious case.

​
Next steps

Quick start

Build and run your first agent.

YAML configuration

Every field a definition supports.

Tools reference

What each tool does.

Agent sessions

Track and debug runs.