Memex AI Documentation

Overview

Memex AI is the Mission, decision, and knowledge layer for AI-native software teams. It provides a shared graph that both humans and AI coding agents read from and write to, ensuring every participant, human or machine, acts on the same understanding of what's being built and why.

The platform captures four interconnected layers: Missions (the objectives), decisions (the choices that shape implementation), tasks (a dependency-aware execution graph), and standards (scoped, prescriptive knowledge that can't silently rot). Together they form a single source of truth that replaces scattered Slack decisions, stale wikis, and disconnected ticket trackers.

Quick Start

1. Connect your first agent Point any MCP-compatible AI coding agent (Claude Code, Cursor, Windsurf, Cline, or a custom agent) at your Memex AI server. The agent immediately gains access to your entire decision graph through standard MCP tool calls.
2. Create your first Mission Define an objective: the full context that makes every downstream choice intelligible. Add decisions, scope tasks with explicit dependencies, and write standards. It takes less time than setting up a Jira epic, and it's immediately useful for both humans and agents.
3. Watch the cycle work Agents load context, check decisions and dependencies, and produce execution plans. You review and approve. They implement. Drift detection and decision extraction start working from day one, automatically.

MCP Configuration

Memex AI uses Streamable HTTP MCP transport. Point any MCP-compatible AI tool at your Memex AI server's /mcp endpoint with your API key. Below are configuration examples for popular tools.

Claude Code

Cursor

Windsurf

Cline

Missions

A Mission is the top-level container in Memex AI. It articulates what the team is trying to achieve and why. Not a one-line epic title, but the full context that makes every downstream choice intelligible.

Missions are documents, not records. Their content lives in ordered sections: purpose, vision, context, approach, risks, and custom sections. Each section is independently addressable: agents edit one section at a time (sending only 200-500 tokens per edit), and humans can comment on individual sections during review.

Lifecycle:

• DRAFTInitial state. Content is being shaped. Agents can create a draft via create_mission_draft.
• ACTIVEPublished and driving work. Decisions, tasks, and standards are linked.
• ARCHIVEDCompleted or superseded. Still queryable for historical context.

Tags: Missions support freeform tags for categorisation: priority:high, team:platform, etc. Convention-based namespacing keeps things queryable without rigid schema. If a tag pattern solidifies into something every Mission needs, it graduates to a first-class field.

Section-level commenting: Reviewers can add comments to individual sections. Comments can be resolved by authors. The Mission detail URL is shareable. Paste it into Slack and see the title, status, and unresolved comment count.

Decisions

Decisions are first-class objects in Memex AI, not afterthoughts buried in Slack threads or locked in AI conversation history. Every non-obvious choice gets an ID, status, options considered, and rationale.

Sequential IDs: Decisions are numbered per Mission: D1, D2, D3, etc. This keeps references human-readable in conversation ("see D3 on the auth Mission") while UUIDs handle cross-Mission references internally.

Options and trade-offs: Each decision records the options considered, with labels, descriptions, and trade-offs for each. This gives agents and future humans the full context of what was weighed.

Statuses:

• OPENA decision that needs to be made. Open decisions block dependent tasks, preventing agents from building against unresolved ambiguity.
• LEANINGA preference has emerged but the decision isn't final. Indicates direction without commitment, useful for unblocking parallel work while the final call is pending.
• RESOLVEDA decision that has been made. Resolution records the chosen option, the rationale, and which options were rejected. Resolved decisions constrain downstream implementation and inform standards.

Re-opening decisions: When priorities shift or new information surfaces, you can re-open a resolved decision via reopen_decision. The system traces the impact, marking affected tasks as potentially stale and flagging related standards for review. Use get_decision_impact to see the full cascade before re-opening.

Tasks

Tasks in Memex AI are not a flat backlog. They form a directed acyclic graph (DAG). Each task has a goal, acceptance criteria, and explicit dependencies on both other tasks and decisions.

Sequential IDs: Like decisions, tasks are numbered per Mission: T-1, T-2, T-3, etc. Human-readable in conversation, UUIDs internally for cross-Mission dependencies.

The dependency graph means the system always knows what's ready to start, what's blocked, and why. Agents call get_ready_tasks and the system returns only those with all dependencies met and all blocking decisions resolved. Use check_dependencies to see met vs. blocked dependencies, and get_dependents to see what a task unblocks.

Status lifecycle:

• NOT STARTEDCreated, waiting for dependencies or pickup
• BLOCKEDDependencies not met or blocking decisions unresolved
• IN PROGRESSActively being worked on, execution plan submitted
• COMPLETEFinished, which may unblock downstream tasks

Tags: Tasks support freeform tags for type (type:verify, type:release, type:gate), execution mode (agent-only, human-only, paired), and any other classification.

Acceptance criteria: Each task has structured acceptance criteria: a list of conditions that must be met for the item to be considered complete. These are checkable (done/not done) and give agents clear targets.

Execution plans: Before coding, agents call submit_execution_plan with the files to modify, dependency flow, and any conflicts found. This grounds the implementation in the Mission's decisions and standards, and gives humans a chance to review the approach before code is written. Plans can be approved or superseded.

Standards

Standards are scoped, prescriptive instructions. Not "here's how auth works" but "when you modify auth, do X, never do Y, verify with Z." They represent institutional knowledge in a form that agents can reliably consume and act on.

Account-level, not per-Mission. Standards live at the account level and are linked to Missions via a many-to-many relationship. A "deployment" standard might be relevant to five different Missions. It exists once, linked to all of them. This avoids duplicating knowledge when multiple Missions share the same domain concerns.

Domain-scoped: Each standard covers a specific domain: "deployment", "testing", "auth", etc. The domain is unique per account: one standard per domain, one source of truth.

Every standard traces to the decisions that produced it. When a decision is re-opened or a task changes something a standard covers, the system flags the standard for review. Use get_standards_affected_by_decision to see the cascade. This is how Memex AI prevents knowledge from rotting silently.

How agents use standards: When an agent picks up a task, it calls get_standards_for_task to load the relevant scoped knowledge. The standards tell the agent which conventions to follow, which patterns to avoid, and which verification steps are required, all grounded in actual decisions, not guesses. Agents can also call update_standard to keep standards current as implementations evolve.

Drift status:

• CURRENTStandard is up to date and aligned with the codebase and decisions
• DRIFT DETECTEDSomething has changed that may make this standard inaccurate. Needs human review.
• STALEStandard is significantly out of date. Multiple drift events or extended time since last verification.
• UNDER REVIEWStandard is actively being updated in response to drift or new decisions.

Drift Detection

Drift detection is the feature that makes Memex AI fundamentally different from a wiki. Instead of relying on humans to remember to update documentation, the system actively monitors for divergence between standards and reality through four mechanisms:

• Agent-reported drift: During execution planning, agents compare what they find in the codebase against what the standard prescribes. If there's a mismatch, the agent flags it with evidence: "code says X, standard says Y."
• Decision-triggered drift: When a decision is resolved or re-opened, the system automatically identifies which standards are affected and marks them for review. A new auth decision, for example, flags the auth standard.
• Implementation-triggered drift: When a task is completed, the system prompts a review of any standards that cover the modified domain. The implementation may have introduced patterns or constraints not yet reflected in the standard.
• Scheduled audits: Continuous, automated comparison of standards against the current state. Not a quarterly review. An ongoing process that surfaces drift before it causes problems.

Decision Extraction

Nobody will log decisions manually. That's a well-known failure mode of every knowledge management system. Memex AI solves this with passive decision extraction.

How it works:

• Passive extraction: When agent sessions end, the system analyses the conversation to surface decisions that were made, explicitly or implicitly.
• Decision bundles: Extracted decisions are batched into bundles with a summary, rationale, and link to the source conversation. Think of it like a merge request, but for decisions.
• Review flow: Humans review decision bundles with progressive disclosure: approve, reject, or flag individual decisions. No need to read the entire conversation.
• Merge into the graph: Approved decisions become first-class objects in the decision graph, complete with provenance. They can now block tasks, constrain implementations, and trigger standard reviews.

Human-Machine Collaboration

Memex AI is designed for the team you actually have: humans and AI coding agents working in parallel, often without direct visibility into each other's work. The collaboration model is explicit about what each side brings:

What humans bring:

• Mission and intent: the why behind the work
• Decisions with rationale that others can trace
• Priority judgement when trade-offs have no clear answer
• Review of agent-extracted decisions and execution plans
• Domain knowledge that doesn't exist in the codebase

What machines bring:

• Tireless execution against well-defined tasks
• Automatic extraction of decisions from conversations
• Drift detection: flagging when docs diverge from code
• Dependency checking before every implementation
• Parallel work across the entire codebase, simultaneously

The shared graph is the bridge: one source of truth that both humans and machines read and write to. Not a human tool with an API bolted on. Not an AI tool with a dashboard bolted on.

Tech Stack

MCP Transport

Memex AI uses Streamable HTTP transport over the /mcp endpoint. Each tool call is a POST request with a JSON-RPC payload. The server responds synchronously. No streaming needed for the current implementation.

All read tools return formatted text optimised for LLM consumption: structured markdown with clear delimiters, stable IDs, and status indicators. Not raw JSON. The text format is designed to be scannable by both humans (reading in a terminal) and agents (parsing for IDs and status). All write tools accept structured parameters (JSON schema) and return confirmation with any cascading effects described.

There is no vendor lock-in, no proprietary plugins, and no custom integrations needed. If your AI tool supports MCP (and most modern ones do), it works with Memex AI.

MCP Tools Reference

The following tools are available to any connected agent via MCP. They form the complete API surface for interacting with the Memex AI decision graph.

Mission Tools

• list_missions() Returns all Missions with a summary of their status, decision counts, and task progress.
• get_mission(id) Returns the full Mission document: all sections in order, plus decisions, tasks, and linked standards.
• get_mission_status(id) Returns a lightweight status summary: open decision count, task progress, drift alerts.
• create_mission_draft(title, sections) Creates a new Mission in draft status with initial sections (purpose, vision, context, approach, risks).
• update_section(section_id, content) Updates a single section's content. Agents edit one section at a time: small, targeted writes.
• add_section(mission_id, type, content) Adds a new section to a Mission. Supports custom section types beyond the standard set.
• remove_section(section_id) Removes a section from a Mission document.
• publish_mission(id) Transitions a Mission from draft to active. Requires at least a purpose section.
• promote_task(task_id) Elevates a task to its own Mission when scope warrants independent tracking.

Decision Tools

• get_decision(id) Returns a decision's status, options with trade-offs, chosen option (if resolved), and rationale.
• get_decisions(mission_id) Returns all decisions for a Mission with status filters. Shows D1, D2, ... sequence.
• create_decision(mission_id, question, options) Creates a new open decision with a question and options (each with label, description, trade-offs).
• resolve_decision(id, choice, rationale) Resolves a decision. Records the choice, rationale, and rejected options. Cascades to dependent tasks and standards.
• reopen_decision(id, reason) Re-opens a resolved decision with a reason. Cascades staleness to downstream items and flags affected standards.
• get_decision_impact(id) Returns the full impact cascade: which tasks are blocked, which standards would be affected by re-opening.

Task Tools

• get_task(id) Returns full task detail: goal, acceptance criteria, status, dependencies, tags, and execution plan.
• get_ready_tasks(mission_id?) Returns tasks with all dependencies met that can start immediately. Optionally scoped to a Mission.
• check_dependencies(task_id) Returns met vs. blocked dependencies for a task, including cross-Mission task and decision dependencies.
• get_dependents(task_id) Returns which tasks depend on this one: what completing it would unblock.
• update_task_status(task_id, status) Transitions a task's status (not_started, blocked, in_progress, complete). Triggers downstream dependency checks.
• submit_execution_plan(task_id, plan) Submits an execution plan with files to modify, dependency flow, and conflicts found. Grounds the approach before coding begins.
• get_execution_plan(task_id) Returns the current execution plan for a task, including approval status.

Standard Tools

• get_standard(domain) Returns the scoped standard for a domain (e.g., "auth", "testing", "deployment") with prescriptive instructions.
• get_standards_for_task(task_id) Returns which standards are relevant for a given task, so agents load the right context.
• flag_standard_drift(id, evidence) Flags a standard as drifted with evidence like "code says X, standard says Y." Creates a drift event.
• get_standards_affected_by_decision(decision_id) Returns which standards would be affected by resolving or re-opening a decision.
• update_standard(domain, content) Updates a standard's content. Resets status to current and records the update in the activity log.

Assignment Tools

• assign_to_mission(mission_id, user_id, role) Assigns a user to a Mission with a role (lead or contributor).
• unassign_from_mission(mission_id, user_id) Removes a user's assignment from a Mission.
• assign_to_task(task_id, user_id, role) Assigns a user to a task with a role (lead or assignee).
• unassign_from_task(task_id, user_id) Removes a user's assignment from a task.
• get_my_missions() Returns all Missions assigned to the current user, grouped by role.
• get_my_tasks() Returns all tasks assigned to the current user with status and dependency info.
• get_assignments(mission_id?) Returns all assignments, optionally scoped to a Mission. Shows who's working on what.

Auth Model

Memex AI has two authentication paths: one for agents, one for humans. Both resolve to the same multi-tenant account model.

Agents (MCP connections)

API keys use the mk_ prefix for identification. The server hashes the key, looks up the api_keys table, resolves to account_id, and sets row-level security on the database connection. The key's label (e.g., "claude-code", "cursor", "ci-agent") is recorded in the activity log for audit.

Keys can be revoked without affecting other keys on the same account. The last_used_at timestamp lets admins see which keys are active.

Humans (React admin)

The server verifies the JWT with Firebase Admin SDK, extracts the auth provider ID, looks up the users table to get user_id and account_id, and proceeds. The user's role (owner, admin, member) determines their permissions in the admin UI.

Permissions

The permission model defines what each role can do across the platform:

Agents can do most operational work (resolving decisions, updating tasks, flagging drift, submitting execution plans), but cannot manage the account itself (users, API keys, Mission lifecycle).

Requirements

Memex AI can be self-hosted on your own infrastructure for complete data sovereignty. It runs as a single container serving both the REST API and MCP endpoint. The requirements are minimal:

• Node.js: v20 or later (TypeScript runtime)
• PostgreSQL: v17 or later (the decision graph, task DAG, standard storage, and row-level security for multi-tenancy)
• Firebase project: for human authentication (email/password + Google SSO). Agents authenticate via API keys and do not require Firebase.
• LLM API access: for decision extraction and drift detection features (bring your own API keys)

Configuration

Configure your self-hosted instance through environment variables:

Deployment

Memex AI runs as a single container serving both the REST API (/api/*) and MCP endpoint (/mcp). Basic deployment steps:

Once running, point your agent's MCP configuration to https://your-server:3000/mcp. The React admin connects to the same server on /api/*. API keys (with mk_ prefix) are generated from the admin Settings page.