Create an agent

Turn one business outcome into a small, valid Dino agent source tree.

Write the brief first

Define these items before editing files:

• caller and organization identity;
• one primary call objective;
• success and failure conditions;
• information the agent can use;
• information the agent must collect;
• terminal business dispositions;
• external systems that the call must read or update;
• language, voice, and region.

Build in one working layer

[1] Brief ──▶ [2] Example ──▶ [3] Adapt ──▶ [4] Validate ──▶ [5] Render

Start with the example catalog. Open the selected source tree through the installed dino-ping skill. Use a new scaffold only when no example is a useful base.

Prompt your AI agent

Recommended

Use the `dino-ping` skill to create an agent for this brief: <brief>.
Inspect the source-complete examples before you edit anything.
Select the smallest matching example and work from a copied source tree.
Ask me for missing outcomes, data, language, voice, or integration decisions.
Keep the first version focused on one end-to-end outcome.
Validate after each material edit and render the final flow.
Do not publish or place a call.

Use the Dino CLI directly

# After you approve the local write:
dino agent scaffold --name <agent-name> \
  --confirm-mutation agent.scaffold

dino agent validate --agent-dir <absolute-agent-dir>

# After you approve the preview write:
dino agent render --agent-dir <absolute-agent-dir> \
  --output <absolute-agent-dir>/preview.png \
  --confirm-mutation agent.render

Source ownership

Keep these items together in the agent directory:

agent/
├── agent.toml
├── flow.json
├── src/
│   ├── greeting.opus
│   ├── idle_warning.opus
│   ├── time_limit.opus
│   └── error.opus
├── integrations/       optional source
└── plugins/            generated; do not commit

Gotchas

• Keep the agent description concise and business-specific.
• Declare every [[placeholder]] in agent.toml and use each declaration.
• Keep model-visible placeholders separate from private integration context.
• Treat validation failure as a hard stop.
• Build a complete narrow use case before you add optional branches.

Next

Use Design the conversation to define stages and tools.