Vocion
docs/features/agents.md

Agents

An Agent is composed of a specific set of Skills and Workflows, with a system prompt that defines its voice and scope. The agent routes work to its skills; each skill carries its own logic, acceptance evals, and tool access.

What it does

An Agent is the thing a user talks to. When a user says "summarize my last discovery call," the Agent:

  1. Interprets intent (classification against the wired Skill catalog)
  2. Picks the right Skill(s) or kicks off a Workflow
  3. Gathers input via retrieval (ctx.retrieve across the tenant's Sources)
  4. Streams back the result, with citations back to the underlying documents and objects

Agents are named identities. Multiple agents can exist per tenant (a sales agent, a support agent, an internal-ops agent). Each sees only the skills + workflows it's wired to — you can safely give the sales agent write access to HubSpot without the support agent getting the same permission.

Agents also carry grouping fields — role (lead | specialist), agentType (mission | workflow | operational), and team — that let them form a Team: a Lead you brief, coordinating its specialists. See Teams.

Folder shape

workspace/<org>/agents/<slug>/
├── agent.yaml         # structured definition (required)
├── system-prompt.md   # voice, scope, guardrails (required)
├── evals.yaml         # conversation-level fixtures (recommended)
└── README.md          # optional — rationale, edge cases

agent.yaml

slug: sales-assistant
name: Sales Assistant
description: Reference sales agent — discovery, deal analysis, proposal drafting
active: true
model: gpt-5.4
skillSlugs:
  - discovery_summary
  - summarize_deal
  - draft_followup_email
  - search_everything
workflowSlugs:
  - discovery_followup

system-prompt.md

The system prompt — defines voice, scope, and guardrails. Free-form markdown. The LLM sees it verbatim on every conversation.

evals.yaml

Conversation fixtures — "given this user message, the agent should call skill X with args Y" or "output should mention Z." Catches regressions where a system prompt tweak silently changes which skills the agent reaches for. See Evals.

Inheriting from the base pack

Since vocion-v2.3.0 an agent doesn't have to be authored from scratch: vocion-core ships a versioned base pack (core@1.0.0) with default RevOps agents such as revenue-director and proposal-writer. A workspace opts in with extends: core@1.0.0 in workspace.yaml, activates agents under use: (their skills and object types come along transitively), and overrides an activated default by dropping a same-slug file marked extends: core — scalars replace, arrays take { $append: [...] } / { $remove: [...] }, everything unmentioned is inherited. An override can never flip a base operation's requiresApproval: true to false, and the drilldown shows the inherited file as a read-only core tab next to your override. Un-activated core agents appear on the Agents page as greyed "Core · not activated" cards (since vocion-v2.4.0). Omit extends and nothing changes.

Runtime

A user message routes to the Agent's chat.completions call with:

  • The Agent's system prompt
  • The wired Skills, exposed to the model as callable operations (each skill in turn calls its own tools)
  • Retrieval hits already folded into context

The Agent decides whether to answer directly, call a Skill, or start a Workflow. Every decision is a Langfuse trace; every Skill run stamps the active context SHA.

Chat responses can be rated (👍/👎) inline — see feedback + logs.

Connection to other resources

  • Teams — how agents group into a lead + specialists
  • Skills — the Agent's roles (its responsibilities)
  • Tools — the atomic capabilities each skill calls
  • Workflows — multi-step procedures the Agent can trigger
  • Objects + Sources — what the Agent grounds answers in

Next

Vocion
© 2026 Vocion. All rights reserved.