Full-chain observability: see where it's slow at a glance

A system you can't see, you can't control

As a system grows more complex and hands more and more steps to AI to run autonomously, a fundamental question surfaces: what's actually happening inside it? An action was sent, nothing responds for a while — is it stuck on the front end, the backend, or is some agent heads-down at work? From surface symptoms alone, you can only guess. What this day did is turn the whole system from a "black box" into a "transparent box": making an action's full journey — from your click in the UI, through backend processing, through an agent executing turn by turn, back to the result on screen — traceable and visible all the way. It adds no new gameplay, yet is the precondition for steering a complex system long-term: only what you can see can you control, and only what you can control can you confidently hand more to. Observability is the starting point of all optimization and debugging — you cannot improve what you cannot clearly see.

One trace threading front end, backend and agents

The day's core work was connecting "tracing" into a chain that truly threads the full stack. Tracing means stamping an action with a single identifier so that, whatever layer of the system it flows through, it carries that identifier and leaves timestamps, so the fragments scattered everywhere can afterward be strung into one complete timeline by that identifier. What was achieved this day is passing that identifier from the front end all the way to the backend and into an agent's execution — any action can be reconstructed into the full trajectory of "how long it spent on the front end first, then the backend, then which agent took over and how long that took." The technical key is correctly propagating this trace context down across every layer boundary instead of dropping it at the boundary (which would leave only isolated fragments that can't be assembled into a whole). Once this full-chain trace exists, the vaguest, hardest-to-investigate complaints — "the system is slow" or "the system is stuck" — gain a ruler that pinpoints precisely.

A browser tracer + a stall watchdog

Within this full-chain trace, the front-end segment got a dedicated browser-side tracer following the leg "from your action in the UI to its final render." It addresses a very concrete confusion: sometimes you click or type and the interface is slow to respond — is the request not sent yet, is it waiting on the backend, or is the front end itself stuck rendering somewhere? The browser tracer breaks this leg into visible steps so you can see exactly which step it's stuck on. A "stall watchdog" came with it: it watches the rhythm of key flows and, the moment a step stalls beyond its expected time, flags the stall immediately, instead of leaving you staring at a frozen interface unsure whether it's dead or busy. For a tool centered on interface interaction, "what is the front end busy with, is it stuck" is users' most direct and frequent question; bringing this leg into observability extends tracing's reach to the spot closest to the user.

Backend collection and reporting + each agent turn in the trace

The chain's other two segments were filled in alongside. The backend stood up a telemetry sink: traces and logs produced everywhere are collected here and reported out, and the trace context brought down from the front end is passed further on, ensuring an action's backend portion still hangs on the same trace line without a gap. The agent segment wove each turn of execution into the same trace — when an agent takes a task and runs a turn, how long that turn took and what it did is recorded as one node on this trace. Together these make "full-chain" live up to its name: from a front-end click, through backend processing, to an agent's turn-by-turn work, all strung on one line. For a platform whose core experience is "directing a team of AI agents to work," "what is each agent busy with this turn, where is it slow" is exactly what should be visible; bringing agent execution into the trace means the AI's work process is no longer an un-peerable black box.

Graphics debugging: recording initial state to reproduce black-screen bugs

In the same spirit as observability, the render-debugging tooling got stronger this day. It could already "capture a frame and replay it for comparison," but a key piece was missing: initial state. A picture is drawn step by step from some starting point, and if capture only recorded the drawing actions but not the initial contents of resources at the start, replay amounts to "replaying from a wrong starting point," and some problems simply won't reproduce. This day filled that in: frame capture now also records the initial state of relevant resources, seeded into the replay to precisely rebuild the whole frame from an identical start. It's especially useful for the nastiest problems like "the screen is black, objects vanished" — often caused by some initial state being set wrong, previously very hard to locate because the replay couldn't reproduce it; now the black screen reproduces faithfully on replay, turning an "occasional, uncatchable" ghost bug into a concrete object that "reproduces stably and can be studied and fixed repeatedly." It's two sides of the same coin as the day's full-chain tracing: one lets you see "where the system is slow," the other "where the picture is wrong."

What this day means

What this day added is a sense organ indispensable to a maturing system. Over many preceding days the platform kept growing new capabilities — moving characters, editable scenes, generatable assets, open-sourced to all; but the more capable and autonomous it gets, the more important it is to "see clearly what's happening inside." A system that can't see its own interior can only guess when something goes wrong, doesn't know where slowness comes from, and eventually loses control for being undiagnosable. This day connected tracing into one line spanning front end, backend and agents, and let render debugging record initial state to reproduce picture problems stably — effectively giving the platform two pairs of eyes at once: one for performance and flow, one for picture and rendering. Making both "what the system is doing" and "why the picture looks like this" visible means that whatever comes next — optimizing speed, diagnosing faults, or confidently handing more autonomy to the AI — rests on reliable evidence. Capability decides "what a platform can do," and observability decides "how far it can be trusted" — and this day filled in the latter.