Use Case Guide · v1.8.0

VEKTOR for Multi-Agent Systems

Every agent in a typical pipeline starts cold and keeps its own private context. VEKTOR replaces that with one shared memory graph every agent reads and writes to with automatic conflict resolution so they never contradict each other.

The problem

In a multi-agent pipeline, agent A learns something agent C needs, but they don't share state. Worse, when two agents write competing facts to the same store, most systems just let the last write win silently corrupting what the rest of the pipeline relies on.

How VEKTOR solves it

One MAGMA graph, shared across every agent in the pipeline. Writes go through AUDN (Add / Update / Delete / No-op) curation before they land a five-verdict resolution pass that classifies every incoming memory against what's already there:

Verdict	Meaning
`COMPATIBLE`	New fact coexists with existing memory both kept
`CONTRADICTORY`	Conflicts with existing memory resolved via trust weighting, not last-write-wins
`SUBSUMES`	New fact supersedes an older, narrower one
`SUBSUMED`	New fact adds nothing the graph doesn't already know
`NO_OP`	Duplicate or noise dropped

Trust matrix

A 2D trust matrix prevents automated agent writes from silently overriding facts a human explicitly set agent-sourced and human-sourced memories are weighted differently during contradiction resolution.

Framework adapters

CrewAI

Drop-in VektorMemory class use as long_term_memory on a crew, or as a standalone tool any agent can call directly.

bash

node node_modules/vektor-slipstream/Crewai/crewai-vektor-setup.js

Local HTTP bridge on localhost:3849 zero cloud dependency, memory never leaves the machine running the crew.

LangChain

v1 and v2 adapter available wire VEKTOR in as the memory backend for any chain or agent executor.

n8n

A VEKTOR memory node for automation workflows. Store and recall directly from any n8n flow via HTTP node, no custom code required.

bash

curl http://localhost:3848/health  # verify the n8n bridge is up

Shared graph vs. siloed memory

	Siloed per-agent memory	VEKTOR shared graph
Cross-agent context	None each agent is blind to others	Full graph visible to every agent
Conflicting writes	Last write wins, silently	AUDN five-verdict resolution
Human vs. agent facts	Treated identically	Trust-weighted separately
Where it runs	Varies / cloud	Local SQLite, $0 egress

Multi-model routing the Collab Model Registry

A single model is rarely the right fit for every step in a multi-agent pipeline. Planning a task graph, executing a step, and verifying a result have different requirements the Collab Model Registry formalises this into four roles, each with hard requirements on tier, context window, and structured-output support:

Role	Requirement	Used for
`conductor`	Structured output required, frontier or mid tier	Plans the task DAG
`thinker`	Frontier tier preferred	Deep reasoning steps
`worker`	Any tier meeting context minimum	Executes individual steps
`verifier`	Fast, clean structured output	Pass/fail scoring of results

Session modes

The registry scales the task graph to whatever models you actually have configured no manual tuning required:

Mode	Models available	Max DAG size	Parallel workers
`full`	Frontier tier present	12 nodes	4
`lite`	Mid tier only	6 nodes	2
`solo`	Free tier fallback only	2 nodes	1

Automatic mode detection

detectMode(availableModels) inspects which provider keys you have configured and returns the matching session mode full mode with a Claude key and a Groq key, lite mode with only Gemini Flash configured, solo mode if you are running Ollama alone. filterCandidates(role, models, budget) then returns the subset of available models that satisfy a given role's hard requirements.

Model coverage

14 providers across three tiers frontier (Claude Opus 4, Claude Sonnet 4.6, GPT-4o, Gemini 2.0 Pro), mid (Claude Haiku 4.5, GPT-4o mini, Gemini Flash, Grok 3 Mini, Mistral Small), and low/free (Llama 3.3 70B, Llama 3.1 8B, DeepSeek, Ollama, MiniMax). Per-provider model selection is configurable via model.{provider} keys in vektor/config.json applies to chat, synthesis, briefing generation, JOT collab, and recall tuning. See the FAQ Faraday-Gate & Multi-Agent section for setup details.

Security for multi-agent pipelines Faraday-Gate

More agents and more MCP tool servers means a larger attack surface. Faraday-Gate is a transparent security proxy that sits in front of every MCP server in your pipeline scanning tool schemas at connect time, pinning them with SHA-256 hashes to catch supply-chain rug-pulls, and gating high-risk actions for human approval before they execute. Available now in v1.8.0.

Next steps

See the full Integration Guides for setup details on every supported framework, the Faraday-Gate security guide for MCP proxy setup, or view pricing multi-agent shared-graph support is included on the Slipstream plan.