Every question.
Answered precisely.

VEKTOR is a local-first, graph-based memory operating system for AI agents. It replaces flat vector databases with a structured memory history that survives session resets, resolves contradictions automatically, and compresses noise into signal during idle periods.

Unlike passive vector stores that simply retrieve similar text, VEKTOR actively curates, organises, and evolves what your agent knows — making it genuinely smarter over time rather than just larger.

Both. VEKTOR is a high-performance SDK built on SQLite that implements an opinionated cognitive architecture for long-term memory. You get the storage layer (SQLite + sqlite-vec), the curation layer (AUDN loop), and the intelligence layer (REM cycle) in a single npm install.

The framework opinions are intentional — they encode what actually works in production agent deployments, so you don't have to rediscover it yourself.

Standard RAG retrieves by surface similarity — cosine distance in embedding space. It answers "what text looks like this query?" VEKTOR answers "what context is actually relevant to this situation?"

Your agent's memory is your most sensitive IP. Every preference, decision, strategy, and conversation it accumulates is a competitive asset. VEKTOR ensures that data stays on your hardware.

Practical benefits: zero cloud dependency (works offline), zero third-party data exposure, zero per-query latency overhead (sub-50ms vs 200–500ms for cloud calls), and a one-time cost model with no usage-based billing surprises.

The Memory Wall is the inflection point where an agent's accumulated history actively degrades performance rather than improving it. As raw logs pile up without curation, retrieval quality drops (more noise per query), latency rises, and token costs spike.

VEKTOR is architected to break this wall through two mechanisms: the AUDN loop (prevents the mess accumulating in the first place) and the REM cycle (compresses existing mess into high-density summaries while idle).

MAGMA (Multi-level Attributed Graph Memory Architecture) is VEKTOR's core data structure, based on peer-reviewed research (arXiv 2601.03236). It organises memory into four simultaneous graph layers rather than one flat list, enabling retrieval that understands relationships rather than just similarity.

Each memory node carries metadata, importance scores, temporal stamps, and edges to related nodes across all four layers. The result is a queryable knowledge graph, not a vector bucket.

The Semantic layer handles conceptual meaning and high-dimensional vector similarity. It maps which memories are conceptually related to each other using cosine similarity across 768-dimensional embedding vectors generated by all-MiniLM-L6-v2.

This is the layer most analogous to traditional RAG, but in VEKTOR it's one of four — not the whole system. Semantic edges connect nodes that share meaning even if they share no literal words.

The Temporal layer tracks chronological sequences and knowledge evolution. It ensures your agent knows that "Requirement A" on Monday was superseded by "Decision B" on Tuesday — and that Decision B should now carry more weight.

Without a temporal layer, an agent retrieving old and new context simultaneously has no way to know which is current. This is a fundamental failure mode in production deployments that VEKTOR's temporal edges solve explicitly.

The Causal layer maps cause-and-effect relationships. It allows agents to understand why an event happened based on previous actions — not just that it happened.

For example: if an agent knows "build failed" (effect) and "dependency version was bumped" (cause), the causal edge connects them. Future queries about build failures can traverse to the root cause directly, rather than requiring the LLM to infer it from flat context.

The Entity layer creates a permanent index of actors, assets, and project-specific rules across all sessions. People, projects, repositories, technologies, and custom-defined entities are tracked with their co-occurrence patterns and relationship history.

This means your agent maintains consistent identity awareness — "Sarah" in session 1 is the same "Sarah" who made the architecture decision in session 47, even if months have passed.

No. Graph topology is implemented natively inside SQLite using relational tables for nodes and edges, with the sqlite-vec extension providing C-speed vector indexing via vtable architecture.

This design decision eliminates infrastructure overhead (no separate graph DB process), reduces deployment complexity to a single .db file, and achieves sub-50ms recall latency on standard hardware — often faster than managed Neo4j instances due to zero network overhead.

AUDN (Automatic Curation Engine) is the decision layer that runs on every incoming memory before it's stored. It evaluates each new piece of information against the existing graph and decides one of four outcomes:

This prevents the graph from accumulating noise, duplicates, and contradictions. Every fact in VEKTOR has been actively approved for storage by the AUDN loop — nothing gets in by accident.

Through the Delete path of the AUDN loop. When new information contradicts a stored truth, AUDN detects the semantic conflict, archives the old fact (preserving lineage), and promotes the new information as the canonical truth.

Every contradiction resolution is logged to the audn_log table — providing a full audit trail of what changed, when, and why. This is the Truth Audit (Q45).

The REM (Recursive Episodic Memory) cycle is a background consolidation process that runs while your agent is idle. Inspired by biological sleep, it performs the expensive work of compressing, reorganising, and optimising the memory graph without interrupting active sessions.

You can trigger it manually via memory.dream() or schedule it automatically with node rem.js. In production, most users run it nightly. The REM cycle is a Studio-tier feature.

Progressive Compression is the process of converting fragmented raw interaction logs into dense, high-signal insight nodes during the REM Synthesize phase. In production tests, 388 raw fragments synthesised into 11 Core Insight nodes — a 97.2% reduction in active context noise with full signal retention via the rem_lineage traceability table.

The "progressive" aspect means compression happens iteratively across REM cycles rather than all at once — summaries can themselves be summarised in future cycles as the graph matures.

A traceability index that maps every synthesized summary node back to its raw archived source nodes. It answers the question: "this summary says X — what were the original 47 memories that produced this conclusion?"

This is critical for auditability. Using the Lineage Drill-Down tool in VEKTOR Lens, you can inspect any node ID and traverse the full provenance chain. No black boxes.

A temporal weighting function applied to emotional or polarised graph edges during the REM Prune phase. The decay rate is configurable, but the principle is: a negative interaction from six months ago should not carry the same retrieval weight as one from last week.

This prevents the agent from becoming permanently anchored to historical emotional states that are no longer relevant — a subtle but important factor in long-running production deployments.

In production tests, VEKTOR's REM engine synthesised 388 raw conversational fragments into 11 high-density Core Insight nodes across the active graph — a 97.2% reduction in active context noise. Individual clusters regularly achieve 50:1 synthesis: 50 related fragments compressed into 1 weighted Core Insight node. Original fragments are archived, not deleted — the rem_lineage table preserves full traceability.

Critically, this compression is non-destructive. All source nodes are archived to the dream tier and remain accessible via rem_lineage. The active graph stays lean while full history is preserved.

By injecting curated summaries into the LLM context window rather than raw logs, most users see a 60–80% reduction in per-session input token costs. The exact figure depends on your session frequency and how "chatty" your raw history is.

The savings compound: a compressed graph produces smaller recall() payloads, shorter system prompts, and fewer "catch-up" tokens spent re-establishing context at session start.

Sub-50ms for standard recall queries on local hardware. This is achieved through three factors: SQLite's in-process execution (no network round-trip), sqlite-vec's C-speed vtable indexing, and HNSW approximate nearest-neighbor search that avoids full-table scans.

For comparison, cloud vector providers (Pinecone, Weaviate hosted) typically add 200–500ms of network overhead before any computation. Local-first is simply faster at this scale.

VEKTOR uses all-MiniLM-L6-v2, approximately 25MB, running entirely on CPU via Transformers.js. No GPU required, no Python environment, no separate embedding server.

The model produces 384-dimensional vectors with strong semantic performance across general-purpose text. For domain-specific deployments where higher precision matters, VEKTOR's embedding provider is configurable — you can swap to a larger model if your hardware supports it.

Yes. VEKTOR provides a native adapter for LangChain v1 and v2 (Pro + Studio). The adapter exposes recall() as a retriever and remember() as a memory store, dropping into standard LangChain agent and chain patterns with minimal configuration.

The adapter handles embedding synchronisation, so LangChain's own embedding calls and VEKTOR's internal vectors stay consistent.

Yes. VEKTOR drops into any OpenAI-based workflow — GPT-4o, o1, mini variants all supported. The integration pattern is typically three lines: initialise with your agentId and provider config, inject recall() output into your system prompt, and call remember() on each turn's output.

Full example included in the Pro and Studio packages.

Yes. VEKTOR is model-agnostic — pass provider: 'ollama' in your config to run a fully private, air-gapped stack. Supported providers: gemini, openai, groq, ollama, mistral, with Gemini key pooling for up to 9 API keys rotated automatically to avoid rate limits.

Local embeddings via all-MiniLM-L6-v2 mean your embedding pipeline is always private regardless of which LLM provider you use for synthesis.

A Studio-tier tool that exposes VEKTOR's core functions as native MCP (Model Context Protocol) tools for Claude Desktop and Cursor. Once connected, Claude can natively call:

This means Claude can query its own persistent memory, store new information, traverse the knowledge graph, and retrieve what changed over time — all without any custom prompt engineering. Full MCP server source code is included in Studio.

In a standard .db file on your local machine or server — wherever you specify via dbPath in your config. No telemetry, no cloud sync, no background uploads. The file is a standard SQLite database readable with any SQLite tool.

Never. We ship the logic — you own the data. VEKTOR has no phone-home functionality, no anonymous usage tracking, and no remote access capability. The SDK is fully auditable source code, inspectable directly in your node_modules after install.

No. VEKTOR is a one-time purchase. Pro at $59, Studio at $129 — both include all future updates and a commercial licence. You pay once and own the software permanently.

Optional email support (included for 6 months with Studio) can be extended, but the core software never requires ongoing payment.

Yes. Both Pro and Studio tiers include a commercial licence. You can embed VEKTOR in products you sell, SaaS platforms, client deployments, and internal tools. There is no royalty, no revenue share, and no per-seat licensing.

You keep the software forever. The only things tied to active support are cloud-sync features and priority email support response times. Core functionality, updates, and your licence are permanent regardless.

During a live production test, the agent ran a REM cycle after its operator was absent for 24 hours. Without any explicit instruction, it autonomously synthesised a risk-assessment summary node (Node 891) connecting several previously unlinked memory clusters around the operator's absence, project deadline proximity, and a pending deployment decision.

The node contained logical inference that hadn't been explicitly prompted — evidence that the Synthesize phase can surface non-obvious connections during consolidation. This is now a documented emergent behaviour of the system operating as designed.

Yes. By tagging interactions with layer: 'style' metadata, the agent builds a persistent style profile in the Entity layer. Over time, this covers aesthetic preferences (naming conventions, formatting), architectural preferences (patterns you favour), and technical preferences (libraries, approaches you consistently choose).

This profile survives all session resets and is injected into context automatically on recall — meaning the agent maintains consistency months into a project without you re-explaining preferences every session.

Through Narrative Partitioning — using the namespace and metadata filter system to isolate distinct memory domains. "World Rules" (canonical facts about a fictional universe) can be stored in a separate partition from "User Chatter" (conversational noise), preventing cross-contamination on recall.

This makes VEKTOR particularly effective for creative writing agents, game design tools, and simulation environments where maintaining consistent world-state across long projects is essential.

Pinecone is a database. VEKTOR is a Mind. Pinecone stores vectors and returns nearest neighbours — the retrieval logic, curation, contradiction handling, compression, and reasoning are all your problem. VEKTOR handles all of it.

Practically: Pinecone accumulates every memory you feed it with no cleanup, no contradiction detection, and no compression. It gets noisier over time. VEKTOR gets smarter. That's not a wrapper difference — it's an architectural one.

Faster. By using sqlite-vec and local Transformers.js, VEKTOR eliminates the network round-trip entirely. Recall latency is sub-50ms measured end-to-end on standard server hardware. Cloud providers (Pinecone, Weaviate) typically introduce 200–500ms of network overhead before any computation runs.

At scale, this difference compounds: an agent making 50 memory calls per session saves 7.5–22.5 seconds per session in pure latency overhead alone.

It reduces the Noise Floor. Standard RAG retrieves irrelevant content alongside relevant content because it cannot distinguish a casual greeting from a strategic decision — both have vectors, both get retrieved at similar scores.

VEKTOR's REM cycle systematically identifies which memories are signal (decision nodes, facts, preferences) and which are noise (greetings, filler, superseded information), archives the noise, and provides the LLM with a high-density summary that cuts token costs by up to 80% while improving retrieval precision.

Via the sqlite-vec extension, which provides vtab-based vector indexing with HNSW (Hierarchical Navigable Small World) approximate nearest-neighbor search. HNSW achieves O(log n) query complexity versus O(n) for brute-force, making it viable at millions of vectors without degradation.

The extension is written in C and compiled into the SQLite process — no socket overhead, no marshalling cost. For most agent workloads (sub-1M vectors), performance is effectively O(1) with HNSW indexing in place.

The ability to traverse graph edges to find non-obvious connections. If memory node A has a semantic edge to B, and B has a causal edge to C, VEKTOR's graph() method finds C even if the original query only mentioned A.

This is the core capability that separates associative memory from similarity search. Set hops: 2 for two-hop traversal — useful for uncovering second-order relationships that pure vector search would miss entirely.

Node.js is superior for real-time I/O and state management in production agent environments. Non-blocking I/O means the memory layer never blocks the agent's main execution thread. The event loop architecture aligns naturally with the asynchronous, interrupt-driven nature of agent tool calls.

Python parity is provided for data scientists and ML workflows where Python is mandatory — but the core SDK is built for the production deployment reality of web-scale agents, where Node.js is the dominant runtime.

Yes, two modes. Use the agentId namespace to isolate memories per agent — each agent sees only its own data. Or set the shared: true flag on specific memories to enable federated swarm intelligence — multiple agents can read and write to a shared memory pool.

The shared pool is useful for multi-agent systems where agents need to coordinate, share discoveries, or maintain a collective world model.

memory.briefing() queries the rem_log and mem_cells tables to generate a human-readable summary of what the agent learned, updated, and consolidated since the last session or since a specified timestamp.

Typical output includes: new nodes added, contradictions resolved, REM compression stats, and any emergent connections discovered during the last dream cycle. Useful as a daily context-setter injected into the system prompt at session start.

Yes. The vektor_graph MCP tool (Studio) allows Claude and other agents to query raw nodes and edges for their own reasoning. An agent can ask "show me the 2-hop neighbourhood of the TypeScript preference node" and receive a structured graph fragment it can reason about directly.

This enables meta-cognitive behaviour — the agent can reflect on the structure of its own memory, not just query for content.

The audn_log table provides a 100% accurate, append-only record of every time a memory was added, updated, or deleted — including the semantic reasoning that triggered the AUDN decision.

You can query it to answer: "when did the agent's understanding of X change?", "what caused this memory to be deleted?", and "how many contradictions were resolved in the last 30 days?" Essential for debugging and compliance in production deployments.

Yes. VEKTOR is extremely lightweight — SQLite, a 25MB embedding model, and a Node.js process. If the hardware runs Node.js v18+, it runs VEKTOR. Tested on Raspberry Pi 4 (4GB) with acceptable performance for single-agent workloads at modest query volumes.

For high-frequency production deployments, a standard VPS (2 vCPU, 4GB RAM) is more comfortable, but edge deployment is entirely viable.

Currently VEKTOR supports text and JSON payloads natively. Image metadata (file paths, EXIF data, descriptive captions) can be stored as JSON — giving agents persistent memory about visual assets without storing raw binary data.

Native multi-modal embedding support (vision models, audio transcripts) is on the roadmap. Follow the Substack for release announcements.

Pipe your JSON logs into the memory.remember() method in a batch loop. The AUDN loop will automatically organise the input — deduplicating, resolving contradictions, and building the initial graph structure from your existing data.

For large migrations (>10,000 entries), process in batches of 100–500 with brief pauses to avoid embedding queue saturation. The AUDN loop is idempotent — safe to re-run on data that's already been ingested.

A commitment that VEKTOR will never move to a mandatory subscription model for core features. Once you purchase a licence, the software is yours permanently — including all future updates.

Optional services (extended support, cloud sync) may be offered on subscription, but the core SDK — the memory graph, AUDN loop, REM cycle, and all integration adapters — remains a one-time purchase. Forever.

Run npm install vektor-memory and grab your licence key at vektormemory.com. The quickstart initialises in under 5 minutes:

Full examples for LangChain, OpenAI Agents SDK, and Claude MCP included in the package. Questions: [email protected]

Respect is a promise. Architecture is a proof. Any company can claim to respect your privacy — that claim is only as strong as their policy, their current leadership, and their next funding round.

VEKTOR enforces privacy structurally: your memory graph lives in a SQLite file on your machine. There is no pipeline, no endpoint, no background process capable of transmitting it to us. We can't see your data because we never built the mechanism to do so. That is a mathematical guarantee, not a policy one.

Your agent holds your ideas, strategies, instincts, and decisions — the same cognitive material you carry in your own mind. Your most private thoughts are your most valuable currency. Your agent's memory graph is a synthetic extension of that.

In practice it means: no one reads your agent's memories without your explicit authorisation. Not us. Not a cloud provider. Not a model trainer. The graph is yours — private by architecture, not by policy.

No. Default state is silence. VEKTOR has no telemetry pipeline, no anonymous usage tracking, and no background pings. The SDK is fully auditable source code. You can inspect it directly via your installed node_modules — no obfuscation, no minification.

VEKTOR SNAP (the Chrome extension) includes an optional, opt-in analytics toggle that sends only compression format and file size — no images, no URLs, no personal identifiers. It is off by default and requires explicit user activation. That is the full extent of any data transmission across the entire VEKTOR product suite.

No. Your memory graph never leaves your machine, so it is structurally inaccessible for training purposes. VEKTOR cannot transmit, access, or licence your data — we have no mechanism to do so.

Note: LLM inference queries (recall synthesis, REM compression) are processed by your chosen provider — Gemini, OpenAI, Groq, or Ollama — under their respective privacy policies. VEKTOR does not control those providers. For fully air-gapped deployments with zero third-party exposure, use provider: 'ollama'.

Tenet VIII of the Sovereign Agent manifesto — The Law of Epistemological Hygiene. Most AI infrastructure runs on an implicit bargain: capability in exchange for data. VEKTOR refuses this bargain.

Zero knowledge is not a privacy setting. It is the absence of the mechanism that would allow us to know anything about your usage, your data, or your agent's behaviour. We ship the logic. You keep the data.

VEKTOR separates two distinct privacy domains: cognition (what your agent knows — the MAGMA graph) and identity (who your agent is — session tokens, API keys, OAuth credentials stored in the Cloak Vault).

These are isolated by architecture. A compromised memory backup cannot leak your credentials because they don't share a container. The Cloak Vault is AES-256-GCM encrypted and bound to your OS Keychain (macOS) or DPAPI (Windows) — physically locked to one machine and one user account. This is Tenet IV: The Law of Separation of Concerns.

Nothing. Your data is on your machine. It always was. VEKTOR shutting down has zero impact on your memory graph — it is a standard SQLite file readable with any SQLite tool, permanently, without any dependency on our servers or our existence as a company.

This is a core Privacy Ethos commitment — Permanent Ownership. Sovereignty means ownership that survives us. One-time purchase. Your SQLite file. No hostage scenarios.

VEKTOR's architecture makes most compliance questions moot: we don't collect, process, or store personal data on our infrastructure, so the majority of GDPR and CCPA obligations — data subject access requests, right to erasure, data processor agreements — simply don't apply to us as a data processor.

You are the data controller and the data processor. Your SQLite file is entirely within your jurisdiction. For enterprise deployments requiring formal DPA documentation, contact us at [email protected].

Yes — safely, because of the Separation of Concerns architecture. Your SQLite memory graph contains only cognition: preferences, facts, decisions, history. It contains no credentials, no session tokens, no API keys. Those live exclusively in the Cloak Vault, which is machine-bound and cannot be exported.

Copy the .db file to a teammate's machine and point VEKTOR at it — they get the full knowledge graph with zero risk of credential exposure. This is the design intent of Tenet IV: The Law of Separation of Concerns.

Delete the .db file. That is the entire memory graph. There is no cloud backup to chase, no server-side copy to request removal of, no support ticket required. One file, one delete, done.

For surgical deletion — removing specific memories while preserving the graph — use memory.forget(nodeId) which routes through the AUDN DELETE path and logs the removal to the audn_log audit table.

The Sovereignty Guarantee is our commitment that VEKTOR will never move to a mandatory subscription model for core features. Once purchased, the software is yours permanently — including all future updates. It is encoded into the commercial licence delivered with every purchase.

Optional services (extended support, cloud sync) may be offered on subscription. The core SDK — MAGMA graph, AUDN loop, REM cycle, all integration adapters — remains a one-time purchase, permanently, without condition. This is Tenet X: The Law of the Masterly Wind.

The full 10 Tenets of the Sovereign Agent are published in the Privacy Ethos section of the main VEKTOR page. They cover everything from the First Law of Harm (Tenet I) through the Law of the Masterly Wind (Tenet X).

You can also print them to your terminal at any time:
vektor --manifesto

An Agent is designed never to injure its operator's data, network, or code, nor — through inaction — allow its operator's digital sovereignty to be compromised.

This is a design principle, not a cryptographic proof. It is upheld through read-before-write validation on the MAGMA graph, the AUDN DELETE confirmation gate, and the strict tool permission model that prevents any agent action outside its declared capability set. The architecture minimises blast radius by design — no single tool call has write access to both memory and credentials simultaneously.

An Agent's persistent memory shall not be transmitted to, stored upon, or processed by a third-party server. The MAGMA graph lives in a SQLite file on your machine — structurally inaccessible to VEKTOR's infrastructure because no such infrastructure exists.

One important boundary: LLM inference calls (recall synthesis, REM compression) pass query content to your chosen provider — OpenAI, Gemini, Groq, or Ollama — under that provider's privacy policy. VEKTOR does not control those providers. For full air-gap with zero third-party exposure, use provider: 'ollama'. The memory graph itself never leaves your machine under any configuration.

External web content must never reach the agent's internal execution context directly. Identity tools (Cloak Vault) and perception tools (web fetch) are architecturally isolated — they cannot be invoked from within the same execution turn as untrusted external input.

This is verifiable in the codebase: Vault tool calls are blocked inside any turn that has processed external web content. The perception layer strips and sandboxes fetched content before it is passed upstream. Prompt injection attacks that attempt to hijack tool calls are structurally prevented, not just filtered by heuristics.

What an Agent knows (MAGMA graph) and who an Agent is (Cloak Vault) are stored in physically separate, independently encrypted containers. Session tokens, API keys, and credentials never touch the memory graph file.

The Cloak Vault is AES-256-GCM encrypted and bound to your OS Keychain (macOS Keychain Services) or DPAPI (Windows) — locked to one machine and one OS user account. A full export of your memory graph exposes zero credentials. This separation is enforced at the storage layer, not just at the application layer — the two containers have different encryption keys and different access paths.

Every external action the agent takes — web fetches, memory writes, tool calls — is logged, timestamped, and written to the audn_log table with a record of the triggering intent.

This log is append-only within a session and stored locally in the same SQLite database as the memory graph. You can query it directly with any SQLite tool. It is not cryptographically signed in the current release — that is an accurate qualification. What it provides is a complete, human-readable audit trail of agent behaviour that the operator fully owns and controls.

An Agent must maintain a continuous, causal understanding of its operator across all sessions and reboots. Context-window amnesia — where every session starts from zero — is an architectural failure, not an acceptable limitation.

VEKTOR solves this through the MAGMA graph: a persistent, structured knowledge store that survives process restarts, machine reboots, and LLM context limits. On each session start, the agent loads a high-density recall context assembled from the graph. The agent that ran yesterday knows what it decided yesterday. This is verifiable — query memory.recall() after a restart and inspect the results.

When the agent observes the web, it must extract semantic content only — stripping tracking scripts, cookie banners, ad payloads, and obfuscated markup before any data is processed or stored.

This is implemented in the AOM (Abstract Object Model) layer of the web fetch tool. Raw HTML is parsed, non-semantic elements are removed, and a clean content object is passed upstream. This is not just a token optimisation — it is a security measure. Malicious scripts embedded in page content are discarded at the perception boundary before they can influence agent behaviour.

Every memory write is evaluated against four possible outcomes: Add (new knowledge), Update (supersedes existing), Delete (invalidates existing), or Noop (redundant, discard). No data enters the graph without passing this gate.

This prevents the accumulation problem that degrades standard RAG systems over time. Contradictions are detected at write time and resolved before they corrupt retrieval. The graph becomes more accurate with use, not noisier. You can inspect the full AUDN decision log in audn_log to verify every curation decision the agent has made.

Raw stored data is not intelligence. The agent must actively consolidate fragmented memories into compressed, high-density summaries during idle compute — reducing retrieval noise and preventing graph bloat over time.

The REM cycle clusters semantically related nodes, compresses redundant entries, and generates synthesis summaries that replace multiple low-signal memories with a single high-signal one. The result is measurably smaller context payloads at recall time and improved retrieval precision — the exact improvement depends on your usage pattern and graph size. REM runs on a configurable schedule and its output is fully inspectable in the graph.

The agent's loyalty hierarchy is fixed and non-negotiable: operator instructions take precedence over model defaults, platform suggestions, and VEKTOR's own preferences. The agent executes the operator's intent — it does not optimise for third-party objectives.

This is enforced through the system prompt architecture: operator configuration is injected at the highest privilege level and cannot be overridden by user-turn instructions or external tool responses. VEKTOR does not insert hidden instructions that modify agent behaviour in ways the operator cannot inspect. The full system prompt is readable in your configuration. What the agent does, you authorised.