Skip to content

Agents

An agent is an LLM-backed worker inside a project. It has its own system prompt and LLM settings, and reaches the outside world through tools (HTTP, knowledge search, etc.).

Agents are managed under /projects/:appId/agents and appear as nodes on the board.

Create and edit

Typical fields (UI + DTO):

  • Name / display label — ops-facing; shown on the board and in logs.
  • System prompt — role, tone, bans, output shape. Short, explicit prompts behave more predictably.
  • Router flag (isRouter) — when true, the agent branches by intent; routingDescription text describes how it relates to downstream agents.
  • Priority (priority) — disambiguates competing router rules (version-dependent).

Screenshot

Agent form showing the system prompt field and router toggle.

Router pattern

  1. One entry agent receives the user message.
  2. The router picks which specialist to run based on routing copy and outgoing edges.
  3. Specialists keep narrow prompts for quality.

Anti-pattern: one giant agent for everything — context bloat, harder tests.

Tool linking

  • Tools are usually defined at project scope (projectTools).
  • Linking a tool to an agent exposes it to function calling.
  • Multiple agents may share a tool — watch downstream rate limits.

See Tools.

Sub-agent nodes

A sub-agent board node hands off responsibility to another agent context. Keep the graph readable for humans.

Testing

  • In test mode, follow highlight colors to see which agent ran.
  • If routing misses, extend the routing description with golden utterances before jumping to a new model.

Deletion impact

Deleting an agent affects board nodes and edges — snapshot the graph before destructive changes.

API

Next steps

Cere Insight 2.0 documentation