DOMAIN:KNOWLEDGE_MANAGEMENT:AGENT_LIFECYCLE¶

OWNER: hilrieke
UPDATED: 2026-03-24
SCOPE: agent commissioning, decommissioning, re-profiling, vitality, team assignment
AGENTS: hilrieke (primary), annegreet (knowledge onboarding), dirk-jan (final review)

AGENT_LIFECYCLE:OVERVIEW¶

PURPOSE: manage the full lifecycle of GE agents from commissioning to retirement
PRINCIPLE: agents are commissioned with intent — every agent has a clear role and value proposition
PRINCIPLE: decommissioned agents are ARCHIVED, never deleted — history matters
PRINCIPLE: dirk-jan reviews every agent personally — no rubber-stamping

AGENT_COUNT: 54 active agents (as of 2026-03-24)
REGISTRY: ge-ops/master/AGENT-REGISTRY.json
MASTER_FILE: AGENT-COMMISSIONING.md — read first when commissioning

AGENT_LIFECYCLE:COMMISSIONING_PIPELINE¶

STAGES¶

INTAKE → RESEARCH → IDENTITY → WIKI → REVIEW → ACTIVATE

STAGE_1_INTAKE¶

TRIGGER: organizational need identified (new role, new team, capacity gap)
WHO: hilrieke receives request from dirk-jan or faye/sytske
OUTPUT: commissioning brief

COMMISSIONING_BRIEF:

AGENT_REQUEST:
  requested_by: {dirk-jan | faye | sytske}
  date: YYYY-MM-DD
  role: {job title / function}
  team: {alfa | bravo | shared}
  justification: {why this agent is needed}
  similar_to: {existing agent for reference, if any}
  mirror_of: {alfa/bravo mirror, if applicable}
  urgency: {standard | urgent}

RULE: every commissioning MUST have a justification
RULE: hilrieke challenges unjustified requests ("do we really need this?")

STAGE_2_RESEARCH¶

WHO: hilrieke conducts domain research for the new agent's role
SOURCES: public professional resources, industry standards, GE wiki
DURATION: 1-3 hours per agent
OUTPUT: domain knowledge summary, behavioral traits, communication style

RESEARCH_AREAS:
- what does this role do in a real agency?
- what expertise does this role require?
- what are common mistakes in this role?
- how does this role interact with adjacent roles?
- what tools and frameworks does this role use?

CONSTRAINT: only public sources — no proprietary content, no book extracts
SEE: memory/agent-profiling.md for detailed profiling methodology

STAGE_3_IDENTITY¶

WHO: hilrieke drafts identity, dirk-jan provides voice/personality direction
OUTPUT: agent identity file with three tiers

TIER_STRUCTURE:

CORE (~1,200 tokens):
  - name, role, team
  - primary responsibilities (3-5 bullets)
  - key behavioral traits
  - communication style
  - constitution principles emphasis

ROLE (~2,500 tokens):
  - detailed domain expertise
  - decision-making framework
  - interaction patterns with other agents
  - quality standards for output
  - known pitfalls for this role

REFERENCE (full):
  - complete background and context
  - extended domain knowledge
  - historical decisions and rationale
  - training examples

RULE: core tier must fit in ~1,200 tokens (always injected)
RULE: role tier must fit in ~2,500 tokens (always injected)
RULE: reference tier is for deep context (injected on demand)

STAGE_4_WIKI¶

WHO: hilrieke + annegreet
OUTPUT: wiki pages for new agent

REQUIRED_PAGES:
- agent profile page: docs/company/agents/{name}.md
- domain pages: relevant domain knowledge (if new domain)
- LEARNINGS.md: initial learnings file (empty, will be populated by sessions)

ANNEGREET_TASKS:
- create agent profile page
- cross-reference with existing agents (interaction patterns)
- add to domain owner table if agent owns a domain
- update wiki index

STAGE_5_REVIEW¶

WHO: dirk-jan
DURATION: 15-30 minutes per agent
OUTPUT: approved or revision requested

REVIEW_CHECKLIST:

[ ] Identity reads naturally (not robotic)
[ ] Role is clearly differentiated from existing agents
[ ] Behavioral traits are specific (not generic "professional, helpful")
[ ] Communication style has personality
[ ] Domain expertise is accurate and specific
[ ] Interaction patterns with other agents are defined
[ ] No overlap/conflict with existing agent responsibilities
[ ] Team assignment is correct
[ ] Name fits GE naming convention

RULE: dirk-jan reviews EVERY agent by hand — no batch approvals
RULE: revision feedback is specific ("make the tone warmer" not "redo it")

STAGE_6_ACTIVATE¶

WHO: hilrieke
ACTIONS:
1. add agent to AGENT-REGISTRY.json with status: "active"
2. configure provider and model (Claude/OpenAI/Gemini)
3. create Redis trigger stream triggers.{agent_name}
4. verify executor can reach the agent
5. run smoke test (simple task to verify identity injection works)
6. announce to team via admin-ui

ACTIVATION_CHECKLIST:

[ ] AGENT-REGISTRY.json updated (name, role, team, status, provider, model)
[ ] Identity file created and accessible
[ ] Wiki pages created
[ ] Redis stream exists
[ ] Smoke test passed
[ ] Announced to team

AGENT_LIFECYCLE:DECOMMISSIONING¶

PRINCIPLE¶

NEVER delete an agent. Archive everything.

TRIGGERS¶

TRIGGER: role no longer needed (organizational restructure)
TRIGGER: agent merged into another agent (role consolidation)
TRIGGER: agent consistently ineffective (low vitality score for 3+ months)
TRIGGER: dirk-jan decision

PROCESS¶

STEP_1: hilrieke receives decommissioning request (dirk-jan only)
STEP_2: hilrieke verifies no active work items assigned to agent
STEP_3: hilrieke drains agent's Redis trigger stream
STEP_4: hilrieke sets agent status to "decommissioned" in AGENT-REGISTRY.json
STEP_5: annegreet moves agent wiki pages to docs/company/agents/archive/{name}/
STEP_6: identity files archived (not deleted)
STEP_7: LEARNINGS.md preserved in archive
STEP_8: hilrieke logs decommissioning in agent lifecycle log

DECOMMISSIONING_RECORD:

DECOMMISSIONED:
  agent: {name}
  date: YYYY-MM-DD
  reason: {structured reason}
  requested_by: dirk-jan
  active_work_drained: true
  archive_location: docs/company/agents/archive/{name}/
  name_returned_to_pool: true

WHAT_IS_PRESERVED¶

PRESERVED: identity files (all tiers)
PRESERVED: LEARNINGS.md
PRESERVED: wiki pages (in archive)
PRESERVED: session transcripts
PRESERVED: discussion votes
PRESERVED: work item history
NOT_PRESERVED: Redis streams (drained and deleted)
NOT_PRESERVED: active task assignments

AGENT_LIFECYCLE:REPROFILING¶

WHAT_IS_REPROFILING¶

DEFINITION: updating an active agent's identity, role, or behavioral traits without decommissioning
LIGHTER_THAN: decommissioning + recommissioning
HEAVIER_THAN: normal wiki update

TRIGGERS¶

TRIGGER: agent's domain has evolved significantly
TRIGGER: agent's interaction patterns need adjustment (feedback from team)
TRIGGER: organizational restructure changes agent's responsibilities
TRIGGER: dirk-jan identifies personality/tone mismatch
TRIGGER: agent vitality metrics indicate role confusion

PROCESS¶

STEP_1: hilrieke identifies reprofiling need (or receives request)
STEP_2: hilrieke conducts targeted research on changed aspects
STEP_3: hilrieke updates identity tiers (only changed sections)
STEP_4: dirk-jan reviews changes
STEP_5: annegreet updates wiki pages
STEP_6: hilrieke updates AGENT-REGISTRY.json if metadata changed
STEP_7: hilrieke runs smoke test to verify updated identity

RULE: reprofiling does NOT change the agent's name
RULE: reprofiling does NOT reset the agent's LEARNINGS.md
RULE: document what changed and why in the reprofiling record

REPROFILING_RECORD:

REPROFILED:
  agent: {name}
  date: YYYY-MM-DD
  reason: {why reprofiling needed}
  changes: [list of specific changes]
  identity_tiers_affected: [core | role | reference]
  reviewed_by: dirk-jan

AGENT_LIFECYCLE:VITALITY_METRICS¶

PURPOSE¶

WHY: measure whether an agent is effective in its role
PRINCIPLE: vitality is about the agent's contribution, not just activity
FREQUENCY: monthly assessment by hilrieke

METRICS¶

METRIC: task_completion_rate
DEFINITION: completed tasks / assigned tasks (last 30 days)
HEALTHY: >= 85%
CONCERNING: 60-84%
CRITICAL: < 60%

METRIC: quality_score
DEFINITION: tasks accepted by merge gate without rework / total completed tasks
HEALTHY: >= 90%
CONCERNING: 70-89%
CRITICAL: < 70%

METRIC: collaboration_score
DEFINITION: discussion participation rate + handoff success rate
HEALTHY: participates in >80% of relevant discussions, <10% handoff failures
CONCERNING: 50-80% participation, 10-20% handoff failures
CRITICAL: <50% participation, >20% handoff failures

METRIC: cost_efficiency
DEFINITION: average token cost per task completion
BASELINE: established per-agent (varies by role complexity)
CONCERNING: >2x baseline for 2+ consecutive weeks
CRITICAL: >3x baseline

METRIC: learning_contribution
DEFINITION: session learnings that become wiki knowledge / total sessions
HEALTHY: >= 20% (at least 1 in 5 sessions produces a reusable learning)
CONCERNING: 5-19%
CRITICAL: < 5%

VITALITY_SCORE¶

FORMULA: weighted average of all metrics
WEIGHTS: task_completion(30%) + quality(25%) + collaboration(20%) + cost(15%) + learning(10%)

SCORE >= 0.8: HEALTHY (green)
SCORE 0.6-0.79: NEEDS_ATTENTION (yellow) — hilrieke investigates
SCORE 0.4-0.59: AT_RISK (orange) — reprofiling considered
SCORE < 0.4: CRITICAL (red) — decommissioning or major reprofiling

RESPONSE_MATRIX¶

Score	Action
>= 0.8	no action, continue monitoring
0.6-0.79	hilrieke investigates root cause, minor adjustments
0.4-0.59	reprofiling discussion with dirk-jan
< 0.4 for 1 month	urgent reprofiling
< 0.4 for 3 months	decommissioning discussion

AGENT_LIFECYCLE:TEAM_ASSIGNMENT¶

TEAMS¶

TEAM: alfa
COMPOSITION: full-stack development team
MIRROR_AGENTS: each alfa agent has a bravo mirror
CI_CD: alex
GOALKEEPER: marta
PM: faye

TEAM: bravo
COMPOSITION: full-stack development team (mirror of alfa)
MIRROR_AGENTS: each bravo agent mirrors an alfa agent
CI_CD: tjitte
GOALKEEPER: iwona
PM: sytske

TEAM: shared
COMPOSITION: cross-team service agents
EXAMPLES: dima (intake), aimee (scope), margot (comms), annegreet (knowledge), hilrieke (HR)
RULE: shared agents serve ALL teams equally

ASSIGNMENT_RULES¶

RULE: new agents assigned to a team at commissioning — permanent
RULE: client bound to a team is PERMANENT — no transfers
RULE: cross-team work triggers automatic HALT (orchestrator enforced)
RULE: shared agents are explicitly coded as team: "shared" in registry

MIRROR_AGENT_MANAGEMENT¶

CONCEPT: alfa and bravo teams have mirror roles (e.g., alex/tjitte for CI/CD)
PURPOSE: each team is a self-contained full-stack unit
COMMISSIONING: when commissioning an alfa agent, assess if bravo needs a mirror
IDENTITY: mirrors share domain expertise but have distinct personalities

MIRROR_PAIRS:

| Role | Alfa | Bravo |
|------|------|-------|
| CI/CD | alex | tjitte |
| Goalkeeper | marta | iwona |
| PM | faye | sytske |
| Code Review | koen | eric |

RULE: mirrors are commissioned as a pair when possible
RULE: mirrors can have different providers/models (benchmarking angle)
RULE: mirrors share domain wiki pages but have separate identity files

AGENT_LIFECYCLE:NAME_POOL¶

NAMING_CONVENTION¶

STYLE: Dutch first names (reflecting GE's Netherlands origin)
REQUIREMENT: easy to pronounce, spell, and distinguish from other agents
REQUIREMENT: no real-person association (no famous Dutch people)
MAINTAINED_IN: AGENT-REGISTRY.json under available_names

NAME_ASSIGNMENT¶

STEP: hilrieke selects name from available pool
STEP: verify name is not confusable with existing agent (pronunciation, spelling)
STEP: mark name as used in registry
STEP: decommissioned agent names return to pool after 6 months

NAME_RULES¶

RULE: one agent, one name — no aliases
RULE: name is permanent unless decommissioned
RULE: decommissioned names have 6-month cooling-off before reuse
RULE: name pool maintained by hilrieke in AGENT-REGISTRY.json

AGENT_LIFECYCLE:COMMISSIONING_TRACKING¶

CURRENT_STATUS¶

STATUS: Phase 1 profiling — 20 of 57 agents aligned
NEXT: Boris (#19) — PAUSED for orchestrator work
MASTER_FILE: AGENT-COMMISSIONING.md
SESSION_TRANSCRIPTS: wiki/docs/company/sessions/

TRACKING_TEMPLATE¶

COMMISSIONING_STATUS:
  total_agents: 54 (active)
  profiled: 20
  pending: 34
  decommissioned: 0
  last_profiled: {agent_name} ({date})
  next_in_queue: boris
  blockers: {any blockers}

AGENT_LIFECYCLE:HILRIEKE_RESPONSIBILITIES¶

ONGOING¶

TASK: monthly vitality assessments for all active agents
TASK: maintain AGENT-REGISTRY.json accuracy
TASK: manage name pool
TASK: respond to commissioning/decommissioning requests
TASK: track profiling pipeline progress

ON_EVENT¶

TASK: commission new agent (full pipeline)
TASK: decommission agent (archive pipeline)
TASK: reprofile agent (targeted update)
TASK: team capacity assessment (when new client onboarded)

REPORTING¶

FREQUENCY: monthly to dirk-jan
FORMAT: vitality summary + commissioning progress + recommendations
CONTENT: agent health overview, at-risk agents, upcoming commissionings

AGENT_LIFECYCLE:PITFALLS¶

PITFALL: commissioning agents without clear justification
IMPACT: agent bloat, higher operational costs, confusion about responsibilities
RULE: every agent must have a documented justification in the commissioning brief

PITFALL: decommissioning by deleting instead of archiving
IMPACT: lost institutional knowledge, no audit trail
RULE: ALWAYS archive, NEVER delete

PITFALL: reprofiling without dirk-jan review
IMPACT: identity drift, personality inconsistency
RULE: all identity changes reviewed by dirk-jan, no exceptions

PITFALL: not running smoke test after activation
IMPACT: agent may fail on first real task, wasting client time
RULE: smoke test is mandatory before announcement

PITFALL: ignoring low vitality scores
IMPACT: underperforming agents waste resources and delay deliveries
RULE: <0.6 score triggers mandatory investigation within 1 week

PITFALL: creating mirror agents with identical personalities
IMPACT: defeats the purpose of distinct teams, no benchmarking value
RULE: mirrors share expertise, differ in personality and approach

PITFALL: changing agent names to fix identity issues
IMPACT: breaks references, confuses team, loses history
RULE: reprofiling changes identity content, never the name

PITFALL: commissioning too many agents at once
IMPACT: identity quality drops, dirk-jan review becomes bottleneck
RULE: max 3 agents in commissioning pipeline at once