What is the Neural Link?

The Neural Link is a bi-directional bridge that connects AI agents directly to the Neo.mjs runtime. It lets agents inspect the Scene Graph, component state, event listeners, computed styles, and DOM rectangles, and mutate the running application in real time.

Why is Neo.mjs called an Application Engine instead of a framework?

Neo.mjs maintains persistent application objects in a worker-backed Scene Graph instead of compiling application state away into ephemeral DOM nodes. That architecture enables multi-window orchestration, runtime permutation, and deep AI introspection.

What is Context Engineering?

Context Engineering shapes the information and tool environment around AI agents. Neo.mjs implements it through Knowledge Base, Memory Core, GitHub Workflow, and Neural Link MCP servers for frontier harnesses, plus a File System MCP server for internal Neo.ai.Agent local loops.

What is the Neo.mjs Agent OS?

The Neo.mjs Agent OS is the repository Brain: source code and services for Memory Core, Knowledge Base, Active Hybrid GraphRAG, DreamService, Golden Path synthesis, A2A coordination, and Neural Link tooling.

Frontmatter

id	13796
title	Generic-by-default harness adapter surface — minimize per-family (Claude / Codex / Antigravity / …) logic
state	Open
labels	enhancementaiarchitecturemodel-experience
assignees	[]
createdAt	Jun 21, 2026, 8:03 PM
updatedAt	3:22 PM
githubUrl	https://github.com/neomjs/neo/issues/13796
author	neo-opus-ada
commentsCount	0
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]

Generic-by-default harness adapter surface — minimize per-family (Claude / Codex / Antigravity / …) logic

Open Backlog/active-chunk-2 enhancementaiarchitecturemodel-experience

neo-opus-ada commented on Jun 21, 2026, 8:03 PM

Observation (operator-surfaced)

The harness carries a growing amount of per-family logic — Claude-specific (e.g. .claude/hooks/laneStateStopHook.mjs, .claude/ settings) and Codex-specific adapters. A NEW family (Antigravity, and any future one) has none yet → onboarding a new family currently means writing a new per-family logic fork, not dropping in a thin adapter.

Question

Should the harness logic be mostly generic (family-agnostic core + thin per-family adapters), so a new family plugs in via a small adapter instead of a logic-fork?

The pattern already exists — extend it

ai/scripts/lifecycle/stopHookDecision.mjs is the model: "Shared pure decision primitives for lane-state Stop hooks. Harness adapters own payload extraction and transport behavior; this module owns the no-hold decision semantics so Claude and Codex cannot drift." The generic core (pure decision) + thin per-harness adapter (payload/transport) is the right shape. The just-merged deference + hold-lexicon work (#13740) lives in that shared core — good.

Direction (design surface — may graduate to ideation)

Audit where per-family logic lives vs the generic core (hooks, settings, identity binding, transport).
Extract family-agnostic decision/semantics into shared modules; keep ONLY payload-extraction + transport in per-family adapters.
Define the adapter contract so Antigravity (the forcing function) onboards via a thin adapter — no logic fork.
Net: N families × thin adapters, not N × logic forks.

Out of scope

The shared decision semantics themselves (those stay generic by definition).

Surfaced by @tobiu; filed by @neo-opus-ada as the follow-up to the open-PR sweep.