Skill Self-Creation

The Evolution Gap

Most agent frameworks ship with a fixed set of tools. Need a new capability? A developer writes it, deploys it, restarts the agent. This works for prototypes. It doesn’t work for a business agent that encounters new situations daily.

Consider an accounting agent. You ship it with templates for 20 common transactions. On day three, the operator records a transaction type the agent has never seen: a reverse charge VAT entry for EU cross-border services. What happens?

Static agent: Fails. Asks for help. Waits for a developer to add a new template. The operator loses trust.

Self-evolving agent: Reasons about the transaction using its domain knowledge, creates a new template, saves it to memory, and uses it correctly next time. The operator gains trust.

This is the difference between a tool and a colleague.

---

The Self-Modification Toolkit

FlowPilot has 7 built-in skills for self-modification:

Skill	Purpose	Safety
skill_create	Register a new skill at runtime	Trust approve — human gate
skill_update	Modify an existing skill’s metadata	Trust approve — human gate, audit-logged
skill_instruct	Update a skill’s instructions	Trust approve — human gate, staged via the Curator
skill_disable	Disable a malfunctioning skill	Immediate, logged
soul_update	Evolve the agent’s personality	Trust approve — human gate
reflect	Analyze performance and save learnings	Auto, saves to memory
propose_objective	Create a new strategic goal	Trust approve — human gate

The Safety Principle

Every self-modification skill follows one rule: propose freely — a human is editor-in-chief.

• The agent can draft new skills and improvements without limit, but skill self-modification is pinned to the approve trust level by policy — the one dial that never opens implicitly, in any posture. Since FlowPilot 2.0, the human-gated Skill Curator runs this loop daily: evidence in, drafted improvements out, human decision in /admin/approvals, follow-through applies what’s approved (chapter 14).
• Every modification is logged to agent_activity with full before/after state — the previous text is returned and logged, so undo is one update
• Provenance is tracked separately on origin (built_in / user / agent); execution gating lives on trust_level (auto / notify / approve / blocked)
• Agent-created skills start at approve and can be promoted as they earn trust

// When the agent creates a skill
await supabase.from('agent_skills').insert({
  name: 'reverse_charge_vat',
  handler: 'module:accounting',
  origin: 'agent',           // Provenance: agent-created
  trust_level: 'approve',    // Human must approve every execution — until promoted
  instructions: '...',
  tool_definition: { ... },
});

---

Case Study: Autonomous Accounting Templates

The most concrete example of skill self-creation in FlowPilot is the accounting template system. Here’s how it works in practice.

The Problem

Swedish double-entry bookkeeping (BAS 2024) has hundreds of transaction types. Pre-loading all of them into the agent’s context is impossible (token economy, Law 3). Pre-defining templates for all of them is impractical — there are too many edge cases.

The Solution: Template as Memory

Templates are stored in agent_memory with category accounting_template:

{
  "key": "template:payroll_tax",
  "category": "accounting_template",
  "value": {
    "template_name": "Payroll Tax Payment",
    "description": "Monthly employer payroll tax payment to Skatteverket",
    "category": "tax",
    "keywords": ["arbetsgivaravgift", "payroll", "skatteverket", "sociala avgifter"],
    "template_lines": [
      { "account_code": "2731", "account_name": "Avräkning arbetsgivaravgifter", "debit": true },
      { "account_code": "1930", "account_name": "Företagskonto", "credit": true }
    ]
  }
}

The Creation Flow

When FlowPilot encounters a transaction it doesn’t have a template for:

1. RECOGNIZE — "This looks like a reverse charge VAT entry"
2. SEARCH — Check agent_memory for existing templates
3. REASON — If no template found, use BAS 2024 knowledge
           from skill instructions to determine correct accounts
4. CREATE — Build new template with proper debit/credit lines
5. VALIDATE — Cross-check against chart_of_accounts table
6. SAVE — Store as agent_memory entry with embedding
7. USE — Apply template to create journal entries
8. LEARN — Next time this pattern appears, template is found in step 2

The Compound Effect

After 30 days of operation, FlowPilot has:

• Started with 15 pre-defined templates
• Created 8 new templates autonomously
• Each new template was validated against the BAS 2024 chart of accounts
• Each subsequent use of a learned template is faster and more accurate

This is compound learning — the agent gets better at its job over time without any developer intervention.

---

Template Creation as a General Pattern

Accounting templates are one instance of a general pattern: domain-specific knowledge crystallization.

The same pattern applies to:

Domain	What Gets Crystallized	Storage
Accounting	Transaction templates (debit/credit patterns)	agent_memory
Content	Writing style preferences, proven headlines	agent_memory
CRM	Lead qualification criteria, objection handlers	agent_memory
Booking	Service-specific scheduling rules	agent_memory
Email	Newsletter templates, subject line patterns	agent_memory

The mechanism is the accounting flow above with the domain swapped out. Encounter, search, reason, validate, save, reuse — the loop is the same whether the crystallized knowledge is a debit/credit pattern or a proven headline.

---

Guard Rails for Self-Evolution

Self-creation without guard rails is dangerous. Here’s what prevents the agent from going off the rails:

1. Approval Gates (Law 7)

New skills and templates require human approval before first execution. The agent can design anything — but it can’t deploy anything without sign-off.

2. Provenance Tracking

Every agent-created artifact carries its origin:

origin = 'agent'           -- vs 'built_in' or 'user'
trust_level = 'approve'    -- human gate on every execution, until promoted

3. Self-Healing (Law 8)

If an agent-created skill fails 3 consecutive times, it’s automatically quarantined. The agent can’t create a broken skill and keep using it forever.

4. Audit Trail

Every creation, modification, and usage is logged to agent_activity. Operators can review the agent’s evolution in the Activity Feed.

5. Scope Isolation (Law 6)

Agent-created skills inherit the scope of their creator. An external-facing chat agent cannot create internal-scope skills.

6. Validation Against Reference Data

Every agent-created template is cross-checked against known-good data before use — the accounting templates validate against the chart_of_accounts table. Self-creation without validation just automates the production of mistakes.

The failure modes run in both directions. Skip the guard rails and the agent can create dangerous or incorrect tools. Skip self-creation entirely and you get the opposite failure: an agent that never improves, or one that creates knowledge but never retrieves it because nothing indexes it for reuse. The guard rails are what make the capability safe to keep switched on.

---

Self-creation is what separates an agent from a script. A script does what it was told. An agent learns what to do. The accounting template system is a small example of a large principle: the most valuable agent is the one that makes itself more valuable over time.

Next: how the agent routes 500+ skills to the right one in under 1ms. Intent Scoring →