Technical updates

Implementation notes from MarkOS.

Updates · July 2026

Atlas audit: turning AI platform claims into enforceable platform facts

Atlas has moved from an application framework into the shape of an agentic development platform. The current architecture separates surfaces, capabilities, agents, models, workflows, workers, connections, and environments. That separation matters: applications should not embed hidden infrastructure assumptions, and agents should not be buried inside individual app code.

The strongest parts are already concrete. Capabilities are OpenAPI-first. Generated clients and policy checks verify that implementation signatures match declared contracts. Surfaces bind through scoped runtime context instead of importing capability internals. Local, dev, and prod have separate state, secret bundles, routes, and deployment targets. Services are reached through declared endpoints over private Tailscale networking, so placement can change without changing application code.

The next layer is evidence. Agentic systems need traceability across surface requests, capability calls, workflow steps, model inference, tool use, memory updates, evals, and deployments. Atlas is adding that as platform structure rather than relying on logs and chat transcripts. The goal is to know what ran, what source data it used, what it changed, what model or agent acted, and what evidence supported the result.

This is the practical direction for MarkOS: contracts for boundaries, registries for discoverability, gateways for agents and models, ledgers for workflows, source-backed memory for reusable context, and eval evidence for behavior that cannot be checked by unit tests alone.

Updates · July 2026

NeuralWeave: per-song visual data for MarkOS Radio

radio.markos.live is moving from a fixed visualizer toward a per-song rendering pipeline. The goal is direct: when a song plays, the visuals should reflect the structure of that song rather than apply the same effect to every track.

The current foundation is a compact neural model trained on the station catalog. For each track, it produces frame-level signals for drums, bass, melody, energy, and related musical features. That data becomes the input contract for client-side Three.js scenes.

The important platform decision is to stop treating visualization as a purely visual problem. The music analysis stage, render contract, and visual design stage are separate. The neural model reads the song once. The renderer consumes a stable data shape. The design loop can then tune how those signals affect motion, color, depth, pulse, and tunnel behavior.

A separate visual-feedback loop generates motion summaries from the rendered output. That gives an agent a way to evaluate whether beat hits, bass pulses, and melody activity are visible in the final scene. The agent is not just changing numbers blindly; it can compare the music signals to the motion the viewer will actually see.

The output is intended to travel with the audio stream as metadata. Standard players can ignore it, while the MarkOS Radio client can use it to render synchronized visuals. That keeps the client lightweight and keeps the analysis work out of the browser.

Implementation notes

The current direction is inference-only for new tracks. Training is not part of the runtime path. The per-song pipeline runs the trained model, writes the chart data, renders candidate Three.js designs, evaluates motion against the source signals, then publishes a selected visual contract for the client.

radio.markos.live