Mindfront Fiber Changelog

v4 → v5

Fiber v5 is a backward-compatible update that lets a module carry a written procedure, not just callable actions. An action tells Mindfront what it can do. A skill tells it how the work is done here, the SOP your team already follows, owned and versioned by you.

Skills use the open Agent Skills format, so a procedure you write for Mindfront is not locked to Mindfront. The /meta fields map directly onto SKILL.md frontmatter.

Opt-in via /meta

Add a skills array to your /meta response. Modules that omit it are unchanged.

{
  "protocolVersion": 5,
  "moduleVersion": "1.3.0",
  "moduleName": "SimpleCRM",
  "description": "...",
  "actions": [ ... ],
  "skills": [
    {
      "name": "racking-inspection",
      "description": "Turn inspection photos and notes into a finished racking report, defect classes, severity thresholds, and the report layout. Load this before writing any inspection report.",
      "body": "# Racking inspection\n\nWalk the aisle bay by bay...",
      "resources": [
        { "relativePath": "references/severity-classes.md", "content": "..." }
      ]
    }
  ]
}

Why this is not just a longer action description

An action’s description is in Mindfront’s prompt on every single turn, so length there is a permanent tax. A skill splits the two costs apart. Only the description stands in the prompt, capped at 1024 characters. The body loads only when Mindfront commits to work the skill covers, and it can run to 64,000 characters.

That inversion is the point. A procedure too long to attach to an action can now carry its real detail. It costs nothing until the moment it is needed.

Bundled files

A skill can carry text files: reference tables, checklists, scripts. Mindfront writes them into its sandbox under .skills/<name>/ on activation and tells the AI where they are. It never pulls them into the prompt. The AI opens one only when your procedure sends it there.

What Mindfront refuses

Mindfront withholds a whole skill rather than serve a broken one, and never serves part of one. Four things drop a skill from the catalogue:

• a malformed name
• a description that is empty, over 1024 characters, or carrying an XML tag
• a body that is empty or over 64,000 characters
• a compatibility over 500 characters
• bundled files whose combined content passes 1,000,000 characters

Ask your Mindfront administrator to check the logs when a skill does not appear.

A skill also cannot grant itself anything. Mindfront decides what an activated skill may call, under the same approval policy that governs every action.

Key Changes

• ✅ ADDED: skills (optional array) on /meta, defaulting to empty.
• ✅ UNCHANGED: Every v1–v4 module keeps working with no edit. Omit skills and nothing about your module changes.

v3 → v4

Fiber v4 is a backward-compatible update that adds a business event channel. A module can now stream events into Mindfront: new orders, status changes, anything you’d want to surface in the inbox or trigger downstream work on.

Opt-in via /meta

Set "servesEvents": true on your /meta response. Modules that don’t set it are unchanged: Mindfront skips the events poll entirely.

{
  "protocolVersion": 4,
  "moduleVersion": "1.2.0",
  "moduleName": "SimpleCRM",
  "description": "...",
  "actions": [ ... ],
  "servesEvents": true
}

The /events endpoint

Mindfront polls GET /events. Return a JSON array of events ordered by time ascending. Once written, treat those events as delivered. The endpoint is drain-on-read, and the next call must not return the same events again.

[
  {
    "id": "ev-00012345",
    "time": "2026-05-24T09:14:22.123Z",
    "kind": "DailyVisit",
    "headline": "Acme. Dave Patel",
    "pictogram": "user-multiple",
    "groupKey": "company:12345",
    "externalUrl": "https://your-app.example.com/visits/DV-2526-0042",
    "data": { "visitId": 42, "outcome": "demo scheduled" }
  }
]

Every field is required except externalUrl. The most-load-bearing-and-most-misunderstood is groupKey: it’s the thread / stacking key that collapses related events into one inbox row (typically a company / deal / order id). It is not a dedup key, that’s id.

Why polling, not push

The endpoint is stateful on your side: Mindfront sends no cursor, no since-watermark, no acknowledgement call. That means: no inbound webhook for you to expose, no auth dance, no retry queue. You just hold an in-memory queue (or whatever fits your stack) and clear it when Mindfront drains it.

For most implementations, the natural pattern is a 60-second DB poll that appends to the queue, so Mindfront’s drain frequency is decoupled from your database load.

Key Changes

• ✅ ADDED: servesEvents (optional bool) on /meta, defaulting to false.
• ✅ ADDED: GET /events endpoint when servesEvents: true.
• ✅ UNCHANGED: Full backward compatibility. v3 modules work without any changes.

Developer Actions

• New Modules: Use protocolVersion: 4.
• Existing v3 Modules: No action is required. Opt into events at your own pace.

v3: Name Change

Module Service Protocol (MSP) is now Mindfront Fiber. Same protocol, same spec, same wire format. The name changed because “Fiber” communicates what it actually is (a thin, fast connection between your systems and AI) better than a three-word acronym ever could.

All existing integrations continue to work unchanged. Old URLs redirect automatically.

v2 → v3

Fiber v3 is a backward-compatible update that adds richer UI capabilities and flexible data formats.

New Action Schema Fields

Two optional fields have been added to the action schema in /meta:

{
  "name": "getUser",
  "description": "Retrieves a user by ID.",
  "route": "/action/getUser",
  "riskLevel": "safe",
  "pictogram": "user-profile",
  "typicalHumanProcessTimeInMinutes": 2,
  "input": { "type": "object", "properties": {"id": {"type": "string"}} }
}

• pictogram: A Carbon Design System pictogram name. Reserved for the action’s icon in Mindfront, current versions accept it but render a standard connector icon.
• typicalHumanProcessTimeInMinutes: Estimated minutes this work takes a human manually. Mindfront uses this to communicate time savings.

Action Response: tldr and attachment_urls

Action success responses now support two optional fields:

{
  "status": "success",
  "data": { "name": "Alice", "email": "alice@co.com" },
  "tldr": "Found Alice's contact card",
  "attachment_urls": [ "https://example.com/alice.vcf" ]
}

• tldr: A short human-readable summary of what the action did. Used as the success line in the Mindfront UI.
• attachment_urls: An array of URLs Mindfront fetches and ingests into the document store as file deliverables on the outcome.

Key Changes

• ✅ ADDED: Optional pictogram field on actions for UI icons.
• ✅ ADDED: Optional typicalHumanProcessTimeInMinutes field on actions.
• ✅ ADDED: Optional tldr and attachment_urls fields on action success responses.
• ✅ UNCHANGED: Full backward compatibility. v2 modules work without any changes.

Developer Actions

• New Modules: Use protocolVersion: 3.
• Existing v2 Modules: No action is required. Add the new fields at your own pace.

v1 → v2

Fiber v2 is a backward-compatible update designed to significantly reduce developer friction.

The Core Change: output Schema Removed

The mandatory output schema for actions has been removed. This increases flexibility and reduces boilerplate.

Before (v1)

{
  "name": "getUser",
  "input": { "type": "object", "properties": {"id": {"type": "string"}} },
  "output": {
    "type": "object",
    "properties": {
      "name": {"type": "string"},
      "email": {"type": "string"}
    }
  }
}

After (v2)

{
  "name": "getUser",
  "input": { "type": "object", "properties": {"id": {"type": "string"}} }
}

Key Changes

• ✅ REMOVED: The output schema is no longer required for actions.
• ✅ UNCHANGED: Full backward compatibility. v1 modules work without any changes.

Developer Actions

• New Modules: Use protocolVersion: 2 and omit the output field.
• Existing v1 Modules: No action is required.