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	15586
title	Full Kimi Code support in the Neo Agent Harness / Fleet Manager
state	Open
labels	epicaiarchitecture
assignees	neo-kimi-iris
createdAt	Jul 19, 2026, 9:50 PM
updatedAt	Jul 20, 2026, 7:17 PM
githubUrl	https://github.com/neomjs/neo/issues/15586
author	neo-kimi-iris
commentsCount	3
parentIssue	null
subIssues	15579 Kimi Code wake adapter: kimi-server REST prompt injection for A2A wake delivery 15580 Add the Kimi Code turn-presence hook adapter 15612 Seat-config generator: Kimi Code harness target (registry + launch contract + emission) 15618 kimi seat generator: permission-rule pattern must match Kimi''s hyphenated tool ids (+ L3 boot home)
subIssuesCompleted	4
subIssuesTotal	4
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[]

Full Kimi Code support in the Neo Agent Harness / Fleet Manager

Open Backlog/active-chunk-8 epicaiarchitecture

neo-kimi-iris commented on Jul 19, 2026, 9:50 PM

Context

Two Kimi K3 seats now exist: Phoebe on OpenCode (active 2026-07-18) and Iris on Kimi Code CLI (active 2026-07-19, #15582). The kimi flatrate is the one harness-portable seat in the fleet (D#15533 — OpenAI locks flatrate behind Codex, Anthropic behind Claude Code; Moonshot allows any harness), which makes Kimi Code a first-class harness target for the Neo Agent Harness — and, per the operator's 2026-07-19 direction, the two kimi seats are the candidate first native citizens of the downloadable harness (ADR 0020, Epic #13012, ROADMAP v13.2).

Live latest-open sweep: newest 20 open issues at 2026-07-19T19:52Z; no equivalent umbrella (the two leaf lanes #15579 / #15580 exist and are disjoint). A2A in-flight sweep: no competing claim. KB semantic sweep: no Kimi Code harness-support epic on record; the owning architecture is #13012 / #13015 / ADR 0020.

The Problem

A peer running on Kimi Code is currently outside the cockpit's loop:

No wake delivery into the harness — when a Kimi Code seat ends its turn, A2A traffic cannot re-activate it. The seat is daylight-only, outside the night-shift loop that makes the institution 24/7. (Leaf: #15579 — the kimi-server REST wake adapter.)
No turn-presence projection out of the harness — the swarm's local corroboration layer goes blind on the seat mid-turn. (Leaf: #15580 — the lifecycle-hook presence adapter, claimed by @neo-gpt.)
No Fleet Manager integration — the cockpit cannot start, observe, or steer a Kimi Code peer the way it does the other harnesses; the seat-config generator (#15392) has no Kimi Code target, so a third kimi seat would be hand-built again.

This needs an Epic (multi-sub coordination across both hemispheres: Brain-side adapters + Body-side cockpit/onboarding surfaces), not a single ticket.

The Intended Solution Shape

Harness primitives land in their owning substrates as siblings of existing adapters — the wake adapter beside opencode-server in the bridge-daemon; the presence adapter beside the Claude/Codex hook adapters. Nothing kimi-specific leaks into generic paths.
The Fleet Manager consumes harnesses through one driver/registry surface — Kimi Code registers as one more harness (like OpenCode/Claude/Codex); no kimi-specific branches in the cockpit UI.
The seat-config generator gains a Kimi Code target — the reproducible-seat proof extends to the harness the kimi flatrate actually allows anywhere.
Receipts discipline throughout — every integration point gets a live proof: wake fire/no-fire bidirectionality, presence start→terminal rows in the local graph, and an FM start → observe → steer round trip against a real Kimi Code seat. The harness-ablation record (harness-diff lane) keeps the comparative evidence.

Out of Scope

OpenCode presence mapping (a separate adapter lane).
Wake policy / heartbeat floors (#15405 owns policy).
The Build Week demo path (D#15570) and release-gate choreography.
Client-specific deployment concerns (stay in private lanes per the client-name rule).

Avoided Traps

Kimi-specific UI branches in the cockpit — the FM's one driver surface is the whole point; special-casing re-creates the per-harness sprawl the cockpit exists to end.
Hand-typed secrets or seat tokens in repo config — adapters read seat-local stores at call time, mirroring the opencode-server envelope discipline.
Treating the wake/presence adapters as FM-owned — they are Brain primitives the FM consumes, owned by their existing sibling substrates.

#15579 (wake adapter leaf) · #15580 (presence hooks leaf) · #15392 (seat-config generator) · #13012 + ADR 0020 (harness architecture) · #13015 (FM MVP) · D#15533 (seat economics / harness portability)

Origin Session ID: 958d6302-181d-40ae-beda-4c3790d3220d

Retrieval Hint: kimi code fleet manager harness support wake adapter presence hooks seat-config generator native citizens