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