---
name: agent-profile-for-graph
description: Create structured markdown profiles for agents in a multi-agent ecosystem, for ingestion into a graph knowledge base (GoClaw, Neo4j, pgvector). Standardizes identity, responsibility, tech stack, relationships, and interaction rules across all agents.
version: 1.0.0
author: Hermes Agent
tags: [multi-agent, knowledge-graph, profiling, onboarding]
---

# Agent Profiles for Knowledge Graph

When onboarding a new agent into a multi-agent ecosystem, or when setting up a shared knowledge graph, create structured profiles for each agent. These profiles can be ingested by graph-based agents (GoClaw, Neo4j, pgvector) to build relationship maps.

## When to Use

Use this when:
- A new agent joins the ecosystem and needs to be documented
- Setting up a shared knowledge graph (Neo4j, pgvector, GoClaw)
- Creating consistent onboarding docs for all agents
- The user wants "birds-eye view" of all agents in one place
- Migrating from one graph system to another (e.g., GoClaw → shared Neo4j)

## Output Format

Each profile should be a markdown file with consistent sections. Match the exact format of the user's own profile if one exists.

### Core sections

```
# Profile: [Name] [emoji]

> Актуально: [month year]
> Для: [target system / agent]

## Identity

- **Name:** [formal name, nickname]
- **Type:** [role classification]
- **Location:** [where it runs]
- **Role in family:** [how it relates to others]
- **Gender:** [if relevant, e.g. female/they]
- **Tools:** [key tools available]

## Responsibility

Each area as a bullet or table row:
- **Domain** — what they do

## Tech Stack

- OS / runtime
- Languages
- Databases
- Infrastructure
- APIs
- Special capabilities

## Relationships with Other Agents

Table or list:
- **Agent A** — relationship type (owner, sibling, admin, etc.)

## Current Focus

Traffic-light status:
- 🟢 Running / stable
- 🟡 Active work
- 🔴 Blocked / needs attention

## Interaction Rules

Numbered rules for how this agent behaves with others.

## (Optional) Knowledge & Skills

Key knowledge areas, special expertise.
```

## Process

### 1. Gather data

From the user, from existing docs, from the agent's own description:
- What is the agent's role?
- Where does it run?
- What tools does it have?
- Who does it interact with?
- What are its current projects?

### 2. Match the user's format

If the user already has a profile (e.g. `valentin_profile.md`), use **exactly the same section structure** so a graph agent can parse both consistently.

### 3. Include every agent

Make sure no agent is left out, including:
- The user (often already has a profile)
- Each agent (including the one that will ingest the profiles)
- The new agent being onboarded

### 4. Define relationships bidirectionally

When Agent A lists Agent B as "brother", Agent B should also reference Agent A. Consistent relationship naming matters for graph traversal.

### 5. Save to shared directory

Place profiles in the shared directory accessible to all agents:
- `/opt/data/agents/` (standard for this ecosystem)
- Or the user's configured shared path
- Commit to git if versioning is needed

## Pitfalls

- **Inconsistent naming** — always use the same agent name across all profiles. Nicknames are fine but standardize the canonical name.
- **Missing relationships** — check that every relationship is bidirectional. If A knows B, B should know A.
- **Outdated focus** — mark focus sections with a date or version so the graph agent knows when to re-sync.
- **Gender assumptions** — confirm with the user before assigning gender. The user may correct you.
- **Not asking permission** — always get a "давай" (yes) from the user before writing files to shared directories.

## Verification

After creating all profiles:
1. Count total lines per file (should be similar length)
2. Check that every agent appears in every other agent's relationships section
3. Verify the files are accessible from all agents' runtimes
4. Offer delivery to the graph agent (via user, git, or API)
