Research

Four directions, each listed with the artefacts that actually exist. Where evidence is missing, it says so.

01 — Inference & Performance

Inference optimisation, serving infrastructure, kernels, GPU utilisation, latency and throughput.

• Muse Open Kernel Challenge — five benchmark submissions, profile gaidar0yegor, snapshot 5 Nov 2026: prefill 1.918× (#107), bf16_proj 1.582× (#155), decode 2.270× (#194), attention_decode 2.651× (#180), moe_w4a16 2.391× (#234). leaderboard
• w4a16-dequant-gemm — own int4 dequant-GEMM kernel, three variants. Correctness 3.1e-4 at tested shapes; no speedup over the baseline. repository
• Serving configuration study — same GPU, same model, same prompt, same price: 125.0 → 135.9 tok/s between two server configurations at concurrency 1 and 8. Observation: that configuration changed throughput by ~9% in this setup. Interpretation (scoped): in this experiment, configuration mattered more than the kernel change being tested. This is not a general law. repository, raw results
• inference-kernels-lab — kernel and serving measurements kept as a public lab notebook: what was measured, on which GPU, with which result. repository
• SGLang serving track — patch work on SGLang at a55ab7d5 for the Muse serving benchmark. Status: in progress, no submitted result yet.

02 — Agent Systems

Autonomous agents, orchestration, tool use and agent behaviour — built, then operated.

• Operating stack — a long-running agent system in daily use: scheduled jobs with delivery verification, a kanban-based task router, and a three-layer memory (always-on notes, on-demand fact store, session archive). What it demonstrates: agents that run continuously need watchdogs and audit trails, not just prompts.
• Watchdog pattern — monitors emit nothing when healthy and an explicit STALE / NO_DATA state when they cannot read their source, so silence never mimics success.
• Orchestration under budget — task routing with per-run cost ceilings and a dashboard for live job state.

Note: this is operational engineering, not published agent-systems research. No paper, no benchmark of agent architectures.

Tools — agent harnesses, models, cloud and local systems — are named per experiment where they matter for reproducing it, never as the subject of this site. The lab is not tied to one harness or vendor.

03 — AI Security & Reliability

Permissions, isolation, failure analysis and controlled experiments.

• Guardrail behaviour in practice — a destructive request (delete a sender's mail, including trash) was refused after the target set could not be verified: a full-mailbox scan returned zero matching senders. Classification: operational safeguard. Not a security research result.
• Secret handling — credentials are collected through a one-time local form and never through chat; no secret is echoed back.
• Boundary discipline — irreversible actions require a verified target and a human decision; autonomy is granted per class of action, not globally.

Honest status: no published security experiment yet. What exists is discipline, and one internal measurement audit (see receipts).

04 — Experimental Research

Benchmarks, prototypes, tools and reproducible investigations — including the ones that failed.

• Measurement audits — every measurement instrument is validated against itself (A/A) before it is trusted; a stand that failed three A/A runs in a row was declared unusable rather than tuned until it agreed.
• Negative results kept — four hypotheses measured and rejected in one day (MoE config pinning −3.9%, quantisation pins +0.08…0.25%, weight compression on/off 0.0%, cluster glue already present). None of them was submitted as an improvement.
• External arbiter over self-report — an agent's own report is not evidence; agreement with an independent source is. LS-2026-0001 is the case study.

What is not here

No team, no funding, no publications, no certifications. One engineer, instruments, and a habit of publishing what was measured and what was wrong.