Backend: `fortemi` (alpha, legacy for search)

Backend: `fortemi` (alpha, legacy for search)

Prompt-first procedure: Describe the outcome you want in your agent conversation. The agent should select and load the appropriate AIWG assets, explain material changes, request any needed approval, and report verification evidence. Exact commands and flags appear only in the CLI reference.

Routes a subsystem's persistence into Fortemi, the first-party AIWG semantic-memory project. Fortemi is Rust + PostgreSQL + pgvector with SKOS hierarchies, MRL embeddings, and W3C PROV provenance. Communication happens over MCP.

Status: alpha MCP storage adapter

The adapter ships with the parameter shapes documented in `phase-4-fortemi-review.md`, but those shapes have not been formally validated against a live Fortemi instance. Real-world parameter mismatches surface as MCP errors that bubble up to the consumer.

This adapter is deprecated for index/search routing. New discovery, artifact query, graph traversal, and release-package fallback work uses the Fortemi Core static-cache backend by default; `the backend option local` selects the legacy local fallback during the phase-out window.

Use this backend when:

  • You're running AIWG against a Fortemi instance and want memory artifacts to flow into Fortemi's semantic-memory graph
  • You're prototyping the integration

Fortemi Core Migration Boundary

This backend is the older Fortemi MCP storage adapter. It is not the Fortemi Core index/search backend used by:

Use AIWG to complete this documented outcome: This backend is the older Fortemi MCP storage adapter. It is not the Fortemi Core index/search backend used by
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Configuring a subsystem with `"type": "fortemi"` changes persistence for that subsystem through Fortemi MCP tools. It does not switch AIWG discovery, artifact query, graph traversal, research-query, or KB traversal to the Fortemi Core static cache. Those paths use Fortemi Core by default after an artifact graph sync; `the backend option local` selects the legacy local fallback during the phase-out window.

Release packages also include a prebuilt Fortemi Core `framework` index for capability discovery fallback. See `docs/fortemi-core-prebuilt-indices.md` for the cache contract and release matrix maintenance workflow.

There is also a separate, explicit conversion command:

Use AIWG to complete this documented outcome: There is also a separate, explicit conversion command
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

That command maps an AIWG v2 static index through the installed `@fortemi/core/aiwg-index` converter. It does not use this MCP adapter. Conversely, a successful the agent-owned storage operation does not prove that a generated shard is accepted by a Fortemi server. Shard compatibility must name a profile and pass the published-package, server-owned-schema, and real server import/re-export gates documented in `docs/integrations/fortemi-index-export.md`.

Configuration

{
  "version": "1",
  "backends": {
    "memory": {
      "type": "fortemi",
      "mcpServer": "fortemi",        // optional, default: "fortemi"
      "scheme": "aiwg-memory"        // optional SKOS scheme to scope writes
    }
  }
}
FieldRequiredNotes
`mcpServer`noMCP server name registered via the agent-owned mcp operation. Default `"fortemi"`
`scheme`noOptional SKOS scheme (vocabulary scope) for this subsystem's notes

No credentials or env vars belong in `storage.config`. Authentication is governed by the AIWG MCP server registry. Local workstation installs can use a stdio server; internal/Enterprise installs can use HTTPS Streamable HTTP or legacy SSE with the header-env option. The registry stores the environment-variable name, never its value.

How it works

The adapter routes the storage interface to Fortemi MCP tools:

AIWG opFortemi tool
`read``get_note`
`write` (new)`capture_knowledge`
`write` (existing)`update_note` (versions are first-class)
`list``list_notes` (filtered by `id_prefix`)
`delete``update_note { archived: true }` (Fortemi is immutable)
`query``search`

Note-id namespacing

Each entry stored in Fortemi has `note_id = subsystem + ':' + path`. The subsystem prefix prevents collisions across `kb`/`memory`/`research`/etc. when they share a single Fortemi instance.

Example: the agent-owned memory operation → Fortemi note_id `memory:research-complete/index.md`.

Delete semantics

Fortemi's design is immutable — no destructive delete. The adapter's `delete()` issues `update_note { archived: true }` instead, which suppresses the note from `list`/`read` but preserves history. If you need a "real" delete, do it through Fortemi's admin tooling.

Capabilities

OperationNotes
`read`Returns `null` for `not_found`; prefers `revised_content`
`write`Calls `capture_knowledge` for new IDs, `update_note` for existing
`list`Filters by subsystem prefix; strips prefix from returned paths
`delete`Archives via `update_note`; no-op for missing
`query`Implemented (Fortemi has native semantic search)

Caveats

  • Alpha stability. Parameter shapes are based on the planning doc, not a live API. File issues if you see schema mismatches.
  • Async model. Fortemi's NLP pipeline runs server-side; `write` returns when the tool call is accepted, not when the artifact is queryable.
  • Transport security. Stdio supports local workstation installs. Streamable

HTTP and legacy SSE support remote services; non-loopback endpoints require HTTPS and missing credential references fail closed.

  • No `update`-on-conflict semantics. Two concurrent `write`s to the same `note_id` may race at the Fortemi side. Behavior is governed by Fortemi's versioning model, not by the adapter.

Setup

1. Install and run Fortemi (separately from AIWG). 2. Register the Fortemi MCP server with AIWG:

Use AIWG to complete this documented outcome: 1. Install and run Fortemi (separately from AIWG). 2. Register the Fortemi MCP server with AIWG
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Or register authenticated Enterprise transport without storing its token:

Use AIWG to complete this documented outcome: Or register authenticated Enterprise transport without storing its token
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

the header-env option is resolved only by AIWG's storage runtime. The registry and generated provider configuration contain the environment-variable name, not its value; set that variable in the environment that runs the agent-owned storage operation.

3. Add the backend to `.aiwg/storage.config`:

   {
     "version": "1",
     "backends": {
       "memory": { "type": "fortemi", "mcpServer": "fortemi", "scheme": "aiwg-memory" }
     }
   }

4. Verify:

Use AIWG to complete this documented outcome: 4. Verify
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

5. (Optional) Migrate existing AIWG memory:

Use AIWG to complete this documented outcome: 5. (Optional) Migrate existing AIWG memory
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

6. Ingest the research corpus (preview first):

Use AIWG to complete this documented outcome: 6. Ingest the research corpus (preview first)
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

See also

  • `.aiwg/planning/training-framework/phase-4-fortemi-review.md` — Fortemi architecture review
  • `docs/storage/migration.md` — bulk migration into Fortemi
  • AIWG MCP server registry: the agent-owned mcp operation, the agent-owned mcp operation