AnxCorTexHQ

ANXCORTEX HQ · WINDOWS · RELEASE CANDIDATE

AnxCorTex HQ

One command center. Specialized intelligence.

AnxCorTex HQ is a local-first desktop command center for coordinating ten specialized AI departments across engineering work. Missions are planned, routed, executed, and verified under explicit operator approvals, and every department separates verified facts, assumptions, unknowns, and recommendations. Cloud inference is off by default and requires a provider you explicitly configure and enable.

Download v0.9.8 RC Explore HQ

Windows · Release Candidate · v0.9.8-rc.1 · Unsigned installer

Mission Control: a row of mission status tiles above grouped mission lists, with the Local AI Queue panel below.
Mission Control, captured from the packaged Windows build of v0.9.8-rc.1 (fresh profile, no providers configured).

COMMAND CENTER

Mission Control

Mission Control is the multi-mission command surface: every persisted mission in one place, presented through four views of the same records.

Four views

Overview, Mission Graph, Pipeline, and Timeline read the same persisted missions: current status, mission graph, workflow stages, and chronological activity.

Overview Mission Graph Pipeline Timeline

Live tiles

Overview summarizes ten live counters for current work.

Active missions Agents running Queued tasks Blocked Pending approvals Sentinel escalations Provider issues Recent failures Completed 24h Change sets 24h

Mission categories

Persisted records are grouped into Attention Required, Running, Drafts, Failed, and a bounded Recent history.

Local AI Queue

The Local AI Queue is strictly FIFO and keeps at most one active local inference per application process. Ollama readiness is reported separately from queue occupancy.

A focused mission is only the record currently open for detailed review.

Focus never starts, pauses, cancels, approves, prioritizes, or authorizes work.

PIPELINE

Pipeline

Work routes through the canonical seven-stage pipeline. Department sequence:

Manager → Architecture → Engineering → QA → Security → Documentation → Manager

  1. 1Plan missionVantage · Manager
  2. 2Analyze architectureLattice · Architecture
  3. 3Develop implementation reasoningCobalt · Engineering
  4. 4Review available evidenceRift · Quality Assurance
  5. 5Review trust boundariesOnyx · Security
  6. 6Prepare technical handoffSlate · Documentation
  7. 7Finalize missionVantage · Manager

Three optional stages exist; each is inserted only when the Manager plan routes there.

  • +Gather precedent and constraintsUmbra · Research
  • +Review product and UX behaviorPrism · Product / UX
  • +Assess release readinessKeystone · Release

ORGANIZATION

Ten departments

Mission Control routes work across ten specialized departments; each returns evidence-grounded results that separate verified facts, assumptions, unknowns, and recommendations.

Recovery exists as an event actor for blocked-mission reconciliation, not a department.

Vantage

Manager

Mission orchestration & synthesis.

Participates in stages 1 and 7 of the canonical pipeline — planning the mission, then finalizing it.

COORDINATION

War Room

The War Room is General HQ plus one room per mission. Departments post automatically from live mission events, operators can address departments with @mentions and react, and challenges can be opened and resolved.

Chat is advisory — approvals & evidence still enforced.

Requests for real work are routed through Mission Control — chat never executes actions.

War Room: the General HQ room with department messages, mention controls, and reaction options.
War Room, captured from the packaged Windows build of v0.9.8-rc.1 (fresh profile).

HOW WORK MOVES

Mission lifecycle

Six phases, each mapped to the real persisted mission state and the mechanism that produces it.

  1. 01

    Request

    A request becomes a durable mission record.

    Draft — durable mission record

  2. 02

    Plan

    The Manager produces the mission plan.

    Planning — Manager plan

  3. 03

    Route

    The plan is assigned to departments under the routing policy.

    Running — department assignment and routing policy

  4. 04

    Execute

    Department stages run; code changes and commands remain proposals until approved.

    Running — department stages, Change Set approval

  5. 05

    Verify

    QA and Security validation run against recorded evidence.

    QA and Security validation, Sentinel evidence ledger

  6. 06

    Report

    Documentation prepares the handoff, and Release Center reports readiness.

    Documentation handoff, Release Center readiness

Mission states

Eight mission states are persisted:

  • Draft
  • Planning
  • Running
  • Waiting
  • Needs Approval
  • Failed
  • Completed
  • Cancelled

Code changes and commands stay proposals until the Change Set and execution-approval architecture authorizes them.

If validation fails, engineering may propose a repair, but every repair is a new Change Set with a new explicit approval, and revalidation requires a new execution approval. Automatic repair is capped at two cycles; reaching the limit stops the mission for human attention.

INFERENCE

Local and cloud

Inference is local-first. Cloud providers are an explicit opt-in, never a default.

Local by default

  • Local-first desktop application with a local backend bound to 127.0.0.1.
  • Local inference through Ollama and llama.cpp.
  • Speech is transcribed locally by bundled whisper.cpp and is never sent to a cloud service.
  • Default routing policy is local-only: cloud models are never auto-routed, and explicit cloud requests are rejected before any content is sent.

Cloud by opt-in only

When a cloud provider is used, prompts and context can leave this machine.

Cloud adapters exist for OpenAI and OpenRouter. Nothing is sent unless all three conditions hold:

  1. An API key is stored for that provider.
  2. The provider is enabled in Settings.
  3. The routing policy allows cloud use.

When a cloud request is made, the assembled prompt (system instructions plus the task prompt and any bounded mission, context, or code excerpts the planner includes), the selected model id, output limits, and request options such as temperature and streaming are transmitted to that provider.

Provider terms of service and billing apply to the transmitted content.

Read the privacy disclosure

Settings: local provider configuration and opt-in cloud provider sections.
Settings, captured from the packaged Windows build of v0.9.8-rc.1 — local providers and opt-in cloud providers are configured separately.

ASSURANCE

Control and observability

Assurance comes from enforced approvals, recorded evidence, and visible routing.

This is controlled execution, not an OS sandbox.

Mission state

Every mission is a durable persisted record. Status shown in the interface comes from that record, not from a transient view.

Department routing

Work routes across ten departments through the canonical seven-stage pipeline and its optional stages, under a routing policy that is explicit and inspectable.

Provider and model visibility

Configured providers and the model selected for a request are visible, along with the request class that shaped the routing decision.

Execution evidence

Validation runs produce real execution evidence. Each command execution requires its own approval, and changing a bound field invalidates that approval.

Verification

QA static review and automated evidence feed Security, Documentation, and Manager validation before a mission can complete.

Sentinel enforcement

Destructive, secret, git-push, deployment, and privileged actions stay approval-gated in every access mode. Sentinel reports what is enforced. Enforced, never optional.

Release awareness

Release Center is read-only — it never creates, pushes, uploads, or publishes anything.

Routing awareness

Routing summaries carry tokens and latency only when a provider actually reported them; no currency is estimated when pricing is unknown.

Request classes

DETERMINISTIC SOCIAL_LIGHT SOCIAL_CONTEXTUAL MISSION_STANDARD MISSION_COMPLEX CRITICAL

Routing policies

local-only prefer-local balanced prefer-quality
Sentinel Security Center: enforcement summary, approval blockers, and policy list.
Sentinel Security Center, captured from the packaged Windows build of v0.9.8-rc.1.

TRUST

Privacy at a glance

  • Application data is stored on this machine.
  • There is no AnxCorTex-operated server and no account system.
  • There is no telemetry or analytics SDK, and no usage data is sent anywhere.
  • Cloud use is off by default and only possible with a provider you explicitly configure and enable.
  • API keys are stored through OS-level protection (Electron safeStorage / DPAPI, with an AES-256-GCM vault fallback) and never reach the renderer or the database; the interface receives only a masked hint and configuration state.

Read the privacy disclosure

RELEASE

AnxCorTex HQ v0.9.8-rc.1

Platform
Windows x64
Status
Release candidate — not generally available
Installer
AnxCorTex-HQ-Setup-0.9.8-rc.1.exe
Size
429.6 MiB (450,447,850 bytes)
SHA-256
572E2F46A092B5DD6FA013942ECF9D8FF37C8358AEB11A00B28C5F462D7533A0
Signing
Unsigned — Windows SmartScreen or Unknown Publisher warnings are expected
Update channel
Manual upgrade only — this build has no auto-update
Publication pending

The installer is unsigned. Windows SmartScreen guidance or an Unknown Publisher warning is expected during installation.

Publishing is gated pending the owner's license decision, so the download action is not yet generally available.

Download v0.9.8 RC View releases

The installer link activates after the owner resolves the license decision.