Our own tools, models and formats, written the way they would be written in a design note rather than on a product page. Every figure here is traceable to source, a release manifest, or a run somebody executed.
The systems built for customers are at work.
Rust · terminal · shipped
One terminal supervising every coding agent installed on the machine.
Running several coding agents at once means several terminals, several session stores, and no way to see what any of them did to the working tree until it is already done. Nothing capped how many ran, either.
A daemon owns every agent process and is the only thing holding state; the board is a view that owns nothing. They speak newline-delimited JSON over a loopback socket with a token. Each agent gets its own git worktree, so two agents cannot write the same file, and every diff is shown before anything reaches a branch. Admission control came out of a measurement rather than a guess: sixteen concurrent agent processes held 3,433 MB, an average of 215 MB each, and each pins a core while its turn runs. On a 16 GB laptop twenty agents is the whole machine, and the symptom is not a slow board, it is a desktop that stops responding.
The release gate is a static scan of the packaged binary. It has caught real leaks; it is not a proof that none remain.
| Language | Rust, no framework |
|---|---|
| Architecture | daemon owns state · TUI is a view |
| Transport | NDJSON over loopback, token-authed |
| Isolation | one git worktree per agent |
| Admission control | measured at 215 MB per agent process |
| Agent CLIs detected | Claude, Codex, Gemini, Grok, Kimi, Mercury, Cursor, Aider, OpenCode |
| Engines without a binary | API keys, treated as first-class backends |
| Key handling | never argv, never echoed, never printed back |
| Release gate | refuses to package a binary carrying build-machine paths, internal names or credential-shaped strings |
| Platforms | Windows, Linux, Android, macOS |
Routing · in production
The part that decides which model gets the work, and shows its reasoning.
Choosing a backend by hand every time is a guess, and an agent that names a helper out of habit is also a guess. Neither leaves anything to argue with afterwards.
Three signals score every task against every available lane, and the score vector is printed on the card. An engine whose last probe failed is excluded by name rather than quietly outranked, so a routing decision never hides a dead backend. When two lanes land within a hair of each other it refuses to commit and escalates to a planner instead of breaking the tie arbitrarily.
| Registered lanes | 6 |
|---|---|
| Decision record | score vector printed per card |
| Failed backends | excluded by name, not by ranking |
| Tightest observed refusal | unpublished; the page states the rule, not a margin |
| Fallback | escalate to a planner rather than guess |
Agent orchestration · v1 complete
Agents that open pull requests. They do not merge.
An agent with a merge call in its path will eventually use it, and the interesting failures are the ones nobody reviewed.
A ticket board where each card gets its own checkout and its own agent. A verifier lane can fail a ticket and block the merge. No agent has a merge call anywhere in its path — a person merges, by name, and the name goes into the commit.
| Tickets driven through | 19 |
|---|---|
| Completed agent runs | 10 |
| Concurrency observed | 3 agents, 250 s |
| Merge authority | human only, recorded in the commit |
| Status | v1 complete, access by invite |
Agent memory · running
What the agents remember between tickets, and where each fact came from.
An agent that recalls a fact without its source is asking to be trusted. Stuffing the whole history back into the context instead is expensive and still loses the middle of it.
Long-term memory shared across runs with provenance attached, so a recalled fact arrives with where it came from and can be checked. It is measurable rather than asserted: routing confidence on comparable tickets rose as the corpus filled.
The confidence figures are from one corpus filling over one period of use. They are a trend on our own work, not a benchmark.
| Records / shards | 58 / 7 |
|---|---|
| Routing confidence, early to late | 0.591 to 0.992 |
| Provenance | on every recall |
Language models · open release
Masked-diffusion language models, with the experiment log published.
A lab that publishes only the runs that worked is publishing a brochure. The failures are the part that tells you whether the method holds.
Anchor-token masking, written up with the method and the experiment log rather than a summary. The result worth naming is a generalisation lift on data the model never trained on, with the mechanism causally tested by ablation rather than inferred from the score.
Output quality still needs more training and structured evaluation before production use. The repository says so too.
| Out-of-distribution lift | 1.67×, 95% interval [1.51, 1.85] |
|---|---|
| Mechanism | causally tested via V/O ablation |
| Published generations | 504 |
| Open release | Cassandra T1, Apache-2.0 |
| Edge model | 1.33B parameters, 28 layers |
Open formats and runtime · Apache-2.0
A retrieval format and a spec language for deterministic generation.
Retrieval that cannot say why a passage came back, and generation that cannot guarantee a required token survives, are both fine until something depends on them.
LTMi-XT indexes on a hash-derived topological lattice, so a lookup is positional rather than a similarity guess. lens-xt is a declarative spec language for token-level deterministic generation — you write down what must be preserved and the runtime preserves it.
| LTMi-XT indexing | BLAKE2b hash-derived lattice |
|---|---|
| lens-xt suite | 256 passed, 2 skipped, 1 failed, at commit 01e5eed |
| Install | pip install lens-xt |
| Licence | Apache-2.0, both |
Real-time strategy game · v0.47
A paper-and-ink RTS, written without a game engine. Core game by Astra; the web integration, packaging and release path are ours.
Not a problem anybody brought us. It is where the rendering, animation and determinism work gets pushed harder than a business system would ever push it.
Plain browser JavaScript, no engine and no framework, wrapped for Android and Windows. A dedicated 60 Hz fixed-step simulation with the renderer kept separate, so the same match runs identically on every platform. Three factions with their own drawn architecture and vehicles, a GPU post pass that can be switched off, and a signed Ed25519 release feed the installed game updates itself from. Co-op runs host-authoritative over LAN with no account, or through a small relay that only passes messages.
Browser, Android and Windows builds are published and update themselves. Physical-phone performance is unmeasured, there is no public internet relay yet, and player-versus-player needs a server that runs the simulation, which is written up and not built.
| Version | 0.47.0 · protocol 47 |
|---|---|
| Credit | Core game by Astra. Web integration, packaging, release and deployment by SOPHIA XT |
| Engine | none · plain browser JavaScript |
| Campaign | 18 territories, turn-based |
| Battles | real time |
| Regression suites | 9 in the root test run, plus per-release construction, graphics and native checks |
| Multiplayer | two-player co-op: LAN with a PIN, or internet rooms through a relay |
Internal prototypes, half-migrated experiments, and the parts of the stack that work on one machine and nowhere else. They live on the roadmap and in the open lab stream rather than here, because a specification sheet for something that has run twice is a work of fiction.