Use Case Guide · v1.7.2

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.7.5 Preview.

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.