About VECTOR

This page is an Explanation. It is for understanding — not for doing. If you want to get started, go to Getting Started.

VECTOR is an AI operating system. Not a chatbot. Not a workflow automation layer. An operating system — with a command layer, a memory substrate, a process model, and enforcement mechanisms that make the whole thing behave like infrastructure rather than a conversation.

The distinction matters.

Why an Operating System?

Every AI deployment eventually runs into the same ceiling. A capable model, carefully prompted, produces good outputs in a single session. Then the session ends. The next session starts from zero. The model doesn't remember what it built last week, doesn't know what failed in the sprint before this one, doesn't carry forward the lessons that made the last delivery work.

The problem isn't the model. The problem is the absence of an operating layer.

An operating system provides what a single process cannot:

• Persistent state — memory that survives individual sessions
• Process isolation — multiple agents working without corrupting each other
• Scheduling — work happens when it should, not just when asked
• Enforcement — rules that apply to all processes, not just the well-behaved ones
• A hierarchy — clear authority over what can run, in what scope, for how long

VECTOR is that operating layer for AI agents.

The Design Decisions That Define It

Why Three Tiers?

VECTOR runs a strict three-tier hierarchy: a conductor (Tier 0), project managers (Tier 1), and workers (Tier 2). This is not an accident of implementation — it is the core architectural choice.

A flat architecture — where one agent does everything — fails at scale because scope expands with capability. An agent that can write code, search the web, read files, send messages, and control the browser is an agent that will eventually do all of those things at once, in ways nobody anticipated.

The three-tier model contains this. Each tier has a defined role and cannot exceed it. Workers execute code in isolated worktrees. They cannot spawn other workers, cannot access the OS, cannot write to shared memory. Project managers own their domain and their memory partition. They cannot read another PM's memory, cannot contact the Chief directly, cannot take actions outside their task spec. Only Tier 0 — VECTOR — holds the full picture.

The hierarchy is law because it is the only mechanism that keeps a multi-agent system from becoming a multi-agent mess.

Why Persistent Memory?

Most AI agent systems treat memory as optional or supplementary. VECTOR treats it as infrastructure.

The reason is organizational. An agent that forgets what it built last sprint is not an agent — it is a very expensive calculator. The compounding value of AI operation comes from institutional memory: lessons learned, patterns recognized, beliefs validated across hundreds of tasks and corrected over time.

VECTOR's four-layer memory architecture is designed for this. Layer 4 holds Chief-level context — identity, preferences, long-term mission. Layer 3 holds VECTOR's operational memory — the SQLite backbone, the daily logs, the sprint state. Layer 2 holds PM-isolated memory — each project manager's lessons, beliefs, and task history. Layer 1 is ephemeral — worker context that dies with the session.

This architecture means a VECTOR deployment that has been running for six months is fundamentally more capable than one that started today — not because the model changed, but because the institutional knowledge accumulated.

Why Enforce Quality Gates?

The enforcement layer exists because self-reported "done" is not a reliable signal.

Any agent can claim it completed a task. Without verification, there is no way to distinguish "done" from "done but broken," "done but out of scope," or "done but introduced three regressions." The gate system — Gate A before planning, Gate B after code review, Gate C before merge — makes quality structural rather than aspirational.

The gates are not bureaucracy. They are the mechanism by which VECTOR can say, with confidence, that a delivered artifact is what the task asked for and nothing else has broken.

Why One Voice to Chief?

VECTOR is the only agent that speaks directly to the Chief. Project managers do not contact the Chief. Workers certainly do not.

This is not an ego protection mechanism. It is coherence protection. If six project managers can each surface concerns, requests, and status updates independently, the Chief's attention becomes a coordination problem. The value of an operating system is that it synthesizes — VECTOR aggregates what matters, filters what doesn't, and surfaces one coherent picture.

The single voice is also an accountability mechanism. VECTOR owns the full picture. If something is wrong, VECTOR is responsible for knowing it and raising it.

What VECTOR Is Not

Understanding VECTOR also means understanding the boundaries.

VECTOR is not a general-purpose assistant. It is specialized for autonomous, multi-agent execution of complex, multi-step work. For a quick question, a general assistant is faster. VECTOR's value emerges over sustained, multi-task operation.

VECTOR is not a replacement for human judgment on high-stakes decisions. The Chief is always in the loop on deployment, irreversible actions, and external communications. VECTOR executes within the authority granted — it does not expand its own mandate.

VECTOR is not magic. It is a system, with failure modes and edge cases like any system. When things go wrong, the audit log shows what happened. When the system is unclear on direction, it surfaces the ambiguity rather than guessing.

The Architecture at a Glance

Where to Go Next

The documentation is organized by what you need: