J-Space Cognition Suite V3.7: a Skill that manages an agent's working memory at inference time

What the GLM-5.3-Flash capability realization report actually contains

The repository is not a model release. It is a report plus a Skill directory, and the README describes the Skill, not the model. The top level holds README.md, README.zh-CN.md, CITATION.cff, .zenodo.json, LICENSE, THIRD_PARTY_NOTICES.md and a Chinese-titled PDF whose filename translates roughly to moving GLM-5.3-Flash next to Opus-5 by touching only the harness. The single release is tagged V4 (report) and dated 2026-09-05. The last push to the default branch was on 2026-09-05, which is recent enough that the repository is not dormant, though the README itself does not state a maintenance policy.

The problem it addresses is the one an agent hits after the first few tool calls: context drifts, names get redefined, a conclusion arrives before its intermediates, and a stalled derivation has no exit. The README frames the suite as a "model-agnostic inference-time control system" for deep reasoning, long-horizon work, tool use, verification and recovery. Weights and training are untouched. If you came looking for a fine-tune, a checkpoint or a leaderboard, this is the wrong artifact.

Selective loading, the broadcast hub and the Dense Track

The mechanism is a managed workspace for the agent's own working representations. The README lists seven core mechanisms, and three of them carry most of the design weight.

Selective workspace loading keeps one or two load-bearing ideas active and externalizes the rest, so the agent is not holding the whole problem in the live context. The broadcast hub gives dependent branches one shared source for names, values, constraints and style anchors, which is the direct answer to an agent that renames a variable three turns after defining it. The Dense Track carries long internal chains in compact, decodable notation before the agent returns to clean outer language.

The remaining mechanisms are bridge-before-conclusion reasoning, which forces required intermediates to be explicit before a conclusion consumes them; metacognitive control, which routes confidence, inconsistency and failure signals into a concrete next action; empirical escape and verification, which converts a stalled derivation into bounded tests with a named verifier and stated coverage; and first-person agency, where the README says `I`, `we`, `let's` and `we need` are used to bind workspace state to later actions and checks.

The README is explicit that these are selectively loaded and are not a fixed checklist for every request. That is a sensible design choice, and it also means the suite's behaviour depends on the host model's judgement about which module to load. There is no router you can inspect.

Installing j-space/ into a Skills directory and running the integrity check

Installation is a directory copy, not a package install. The README gives two options. Option A is manual: clone the repository, find the user-level Skills directory your AI host uses, and copy the complete `j-space/` directory into it so that the installed entry is `<skills-directory>/j-space/SKILL.md`. The directory has to stay intact, because SKILL.md routes to relative paths under `modules/`, `references/` and `scripts/`.

After copying, the README says to run the integrity check with an available Python 3 interpreter:

<python-command> <skills-directory>/j-space/scripts/verify_suite.py

Replace `<python-command>` with whatever Python 3 command the host provides, commonly `python`, `python3` or `py -3`. The README does not print the expected output of the check, so treat a non-zero exit or a missing-file complaint as the signal. If your host discovers Skills at startup, reload it.

Option B is to hand the job to an agent that can read files. The README supplies a ready prompt that tells the agent to locate the Skills directory first, install the complete `j-space/` directory, compare rather than overwrite an existing target, run `scripts/verify_suite.py`, and then report the installed path, the verification result and how the host invokes the Skill. It also asks the agent to explain fast, full and loop, and to state that the optional controller records long-task state rather than choosing solutions.

Once installed, you invoke it through whatever mechanism the host provides, such as a Skill picker, `/j-space`, `$j-space`, or a plain request. The README's example request is:

Use j-space for this task. Audit this repository, preserve its architecture, verify every finding, and keep the work consistent across all affected files.

The README states that the entry gate then selects the lightest suitable pass automatically.

The three passes and the optional jspace.py controller

The suite has three passes. `fast` is for one step or a result checkable in one glance and loads nothing extra. `full` covers several dependent steps and one bounded deliverable, loading one or two relevant modules and running `ship` before delivery. `loop` is for multiple stages, files, turns, tools or persistent state, and brings in the ledger, seams, checkpoints, register audit and recovery. The README notes that asking for brevity changes the outer response length while verification stays aligned with the task's floor.

The controller is where `loop` becomes concrete. `j-space/scripts/jspace.py` externalizes loop state into `.jspace/` in the current task workspace, and the README says to invoke it by its resolved Skill path while keeping the task workspace as the current directory. The commands are `note` with `--goal` and `--next` to open the ledger, `note --next` to replace the single next action, `note --core` to record a hub entry and `--core-slot` to swap a live one, `note --check` with `--by` to append a checkpoint with verifier and coverage, `note --open` with `--settled-by` to record a question, `note --close N` to close it against a new checkpoint, plus `seam`, `ship FILE` and `resume`. A representative sequence from the README:

<python-command> <skill-root>/scripts/jspace.py note --goal "what done means" --next "first action"
<python-command> <skill-root>/scripts/jspace.py note --open "does the parser preserve state?" --settled-by "unit tests over all ledger sections and edge inputs"
<python-command> <skill-root>/scripts/jspace.py note --close 1 --check "the parser preserves state" --by "unit tests over all ledger sections and edge inputs"
<python-command> <skill-root>/scripts/jspace.py seam
<python-command> <skill-root>/scripts/jspace.py ship OUTPUT_FILE
<python-command> <skill-root>/scripts/jspace.py resume

Two constraints stand out. The controller uses only the Python standard library, so it adds no dependency graph. And the README states plainly that the controller records and reports state while solution choice remains with the model. That is a real boundary: `jspace.py` will not catch a wrong answer, only an unrecorded or unverified one.

Where J-Space is the wrong tool

The first limitation is the host. The suite assumes either a native Skill loader or a chat or API environment where you can supply `j-space/SKILL.md` as a system- or developer-level instruction and expose `modules/` and `references/` through file or retrieval tools. The README says selected files should be retrieved on demand and that selective loading is part of the operating design, but it does not document what happens when retrieval is unavailable or when the host truncates the instruction. In a host with no file access, you are left with whatever fits in the instruction block.

The second is verification depth. The README's own example of a checkpoint is "unit tests over all ledger sections and edge inputs", which is a strong verifier for a parser and a weak one for a claim about a production system. The suite gives you a place to record coverage; it does not judge whether the coverage is adequate.

The third is scope. Nothing here improves model quality. If your task is a single question with a checkable answer, the `fast` pass loads nothing extra and you have gained only a naming convention. The overhead of the ledger, seams and checkpoints is paid in tokens and turns, and the README justifies it only for work that spans files, turns or tools. For a one-shot summarization job, the controller is pure cost. The README also does not document rollback or uninstall, so removing the suite means deleting the `j-space/` directory yourself.

How this differs from a framework like LangGraph or CrewAI

The nearest alternatives are agent orchestration frameworks such as LangGraph or CrewAI, and the difference is where state lives. Those frameworks put durable state in a runtime you write: you define nodes, edges and a checkpointer, and the graph runs your code. J-Space puts state in the model's working representations and in a flat `.jspace/` directory that a standard-library script reads and writes. There is no graph, no scheduler and no server process. You do not write an orchestration program; you install a Skill and let the host model decide which pass to run.

That makes J-Space far cheaper to adopt and far harder to test. With a graph framework you can unit-test a node in isolation. With J-Space the routing decision lives inside the model, and the only inspectable artifacts are the ledger entries the controller writes. The trade-off is deliberate: the README's prompt for agent-assisted installation explicitly asks the agent to explain that the controller records long-task state rather than choosing solutions. If you need reproducible, externally scheduled execution, a graph framework is the better fit. If you need a model to keep its own reasoning consistent across a long session without building a runtime, the Skill approach is lighter.

Licence, upgrade cost and what to check before adopting

The repository metadata reports the licence as NOASSERTION, meaning GitHub could not match the LICENSE file to a known identifier. The README adds two distribution notes: the repository-level `LICENSE` and `THIRD_PARTY_NOTICES.md` remain part of the distribution, and both should be included when redistributing `j-space/` as a standalone package. Read both files yourself before shipping the Skill inside a product. This is a description of what the repository states, not legal advice.

Upgrade cost is low but not zero. The installed entry is `<skills-directory>/j-space/SKILL.md`, and SKILL.md routes to relative paths under `modules/`, `references/` and `scripts/`. Replacing the directory means re-running `scripts/verify_suite.py`, and if a `j-space` target already exists the README's agent prompt says to compare and ask before replacing anything. Because the controller writes only under the task's `.jspace/` directory, an upgrade does not touch task state, but the README does not state whether ledger formats are stable across versions, so check that before upgrading mid-task.

The concept DOI is 10.5281/zenodo.21971185, and CITATION.cff is present if you need to cite the report. The release history shows one entry, V4 (report), so there is no long trail of patch notes to read for migration guidance.

Editorial conclusion

Adopt J-Space if you already run an agent host with a user-level Skills directory and you want long tasks to carry external state instead of relying on a single prompt. Do not adopt it if you need a model, a training method or a benchmark harness with published numbers: this repository is a report plus a Skill directory, and the README documents no measured results. Before installing, verify three things: that scripts/verify_suite.py passes with your Python 3 interpreter, that your host actually discovers Skills at startup or can take SKILL.md as a developer-level instruction, and that you accept the licence terms, which the repository metadata reports as NOASSERTION rather than a named licence.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Tiger3807861189/GLM-5.3-Flash-J-Space-Capability-Realization-Report on GitHub