AiHummer docs
v1.0.x ▾
v1.0.x stable
RU EN
Core concepts /Agents & personas

Agents & personas

v1.0.x · updated 2026-06-26

An agent is the unit AiHummer puts in front of a conversation. Each agent has a persona, its own model, a structured prompt and a set of skills, and every change to it is versioned. Agents are managed from the web admin UI and through the admin API under /v1/admin/agents/*.

This page covers what an agent is made of, how the structured “G3” prompt is assembled, and how an agent can safely edit its own profile.

The agent registry

The registry is a full CRUD catalogue of agents. For each agent you define an identity, a persona, the model it runs on and the skills it can use. Because the gateway is multitenant, agents live inside a workspace and are isolated like any other tenant data.

  • Persona — the voice and behaviour of the agent, rendered into a stable, cache-friendly layer of the system prompt.
  • Per-agent model — each agent can pin its own model and provider, so a cheap agent and a flagship agent can coexist in the same workspace.
  • Skills — per-agent and shared skills render a “Skills” block into the prompt; they describe capabilities, not weights.

[!NOTE] A per-agent model is independent of routing. Model-tier routing (simple / standard / complex) chooses a model class for a turn, while the per-agent model is the agent’s own default. See Routing.

Versions, rollback and clone

Every meaningful change to an agent is captured as a version. This makes agent configuration auditable and reversible: you can review what changed, roll back to an earlier version, or clone an agent to use it as the starting point for a new one. Version and profile resources live under /v1/admin/agents/* (profile, sections, skills, versions).

[!TIP] Clone a working agent before a large persona or prompt rewrite. If the new direction does not pan out, the original is still one rollback away.

The structured “G3” prompt

Instead of a single free-text system prompt, AiHummer uses a structured agent profile (internally “G3”). The identity is decomposed into fields rather than buried in prose, and the rest of the prompt is built from named sections plus an onboarding block. The orchestrator renders these into the layered system prompt, keeping the stable parts (identity, persona, sections) in a cacheable prefix and appending volatile data last.

The structure makes a profile easy to edit field by field, easy to diff between versions, and predictable to render — there is no hidden prompt soup.

G3 profile
├── identity fields   (decomposed: name, role, ...)
├── sections          (named, ordered prompt blocks)
└── onboarding        (first-run guidance)

Self-editing behind an approval gate

An agent can be allowed to edit its own profile using self-edit tools — for example to refine a section or update its onboarding. This is deliberately guarded:

  • Self-edits go through the approval gate: a proposed change is recorded and must be approved by a human before it takes effect. A rejected change is never applied.
  • The change is captured as a new version, so a self-edit is as auditable and reversible as any manual edit.

[!WARNING] Self-editing is powerful. Keep it behind the approval gate so an agent cannot silently rewrite its own identity. Review proposed self-edits the same way you review any privileged change.

Mail passwords go to the vault

If an agent’s configuration includes mail credentials (for the mail tool), the password is written to the encrypted credential vault, not stored in the profile or rendered into the prompt. Secrets never enter the model context.

Admin API

Agents and their structured profiles are managed under the admin API, which is OIDC-gated and audited:

ResourcePurpose
/v1/admin/agentsList, create, update, delete agents (CRUD)
/v1/admin/agents/.../profileThe structured G3 profile (identity fields)
/v1/admin/agents/.../sectionsNamed prompt sections
/v1/admin/agents/.../skillsPer-agent skills
/v1/admin/agents/.../versionsVersion history, rollback and clone

Where to next