Chat UI grows up: resizable layout, nested tool calls, sub-agent cards

One visible, one quiet: the UI grows up while the backend pours a foundation

The day's work split into a visible half and an invisible one. The visible half: the chat interface matured a notch — this is what users face every day, where every bit of progress shows immediately. The invisible half: the backend quietly poured a far-reaching foundation, a runtime that lets "third-party capability be safely installed as a plugin." The latter shipped almost nothing a user could perceive that day, yet it decides whether the platform can grow from "an app with hardcoded features" into "a platform that can be extended endlessly, even built upon by users." Seen on the same day, the two embody a balance: keep polishing the experience at hand while betting on long-term extensibility.

Chat matures: resizable layout + tool calls nested under their to-do

The interface's progress this day centered on "organizing information more clearly." One: the sidebar, chat area and bottom panel are all resizable, so you can allocate screen space to whatever you're doing — narrow the chat when reading code, raise the bottom when watching output. Two, and more important: tool calls now nest under the to-do item they belong to, rather than spreading into one long flat list. When an agent executes a multi-step task, you can clearly see "which tools it called to complete this step," with the hierarchy obvious at a glance. What long conversations and multi-step tasks fear most is information blurring into a mass that hides progress; these two changes make "seeing clearly who's doing what, and how far along" real.

Sub-agents get their own cards

As multi-agent collaboration grew common, "a lead agent delegating to several sub-agents" became an everyday scenario. This day gave sub-agent activity its own card presentation: sub-tasks no longer mix into the main conversation's text stream but each get a foldable card with their own context. This makes "who's working for whom, and how each is progressing" instantly distinguishable. For a platform that treats "one person directing a team of AIs" as a core scenario, this way of "giving each member's work its own place" is essential — otherwise, as the team grows, the screen becomes an unreadable stew. The sub-agent card is the first step in turning the abstract "multi-agent" into a picture your eyes can directly read.

Live and replay unified into one pipeline

Before this, "watching the agent live" and "replaying history afterward" were likely two separate rendering paths — so for the same content, what you saw live and what replayed often disagreed in detail. This day unified them onto one pipeline sharing the same processing callbacks: whether content is streaming in live or being replayed from the history ledger, it travels the exact same parse-and-present path. The significance is consistency: reopen a stretch of history and you see exactly what truly happened, with no detail distorted. This "single source-of-truth path" design both removes the burden of maintaining two logics and eliminates at the root the most confusing class of bug — "live and replay disagree."

A backend plugin-runtime foundation: bus, permissions, sandbox

The backend's heaviest work this day was beginning to pour a plugin-runtime foundation, aimed at letting "third-party capability be safely installed and run as a plugin." It's made of meshing parts: an in-process event bus so components communicate loosely via publish/subscribe; parsing and validation of plugin manifests, with anti-forgery on the "scope" a manifest declares (so a plugin can't lie about its permissions); a permission engine that constrains by rules what each plugin can and can't touch; a sandboxed file API with cooperative file locks so multiple plugins reading and writing don't corrupt each other; plus an append-only file ledger recording what happened. This whole set shipped almost nothing user-facing that day, but it's the true starting point of the long-term "everything is a plugin" direction — with it, new tools, new workbenches or new agents can later plug in a unified, controlled, sandboxed way, without rewriting the core for each addition.

Engine: an extended component vocabulary + scene assets

The engine kept expanding the "vocabulary" with which it describes a game world. The component system gained support for data shapes like strings and fixed/variable-length arrays, and a built-in "name" component — so every object in a scene can have a readable name rather than just an internal number, far more convenient for debugging and for later viewing in an editor. More importantly, "scene assets" were introduced: managing a whole scene as a referenceable, instantiable asset object, with a mechanism to instantiate a scene into the world. This means scenes can now be saved, referenced and reused structurally just like models and textures — the underlying precondition for all later abilities like "building scenes in an editor, assembling scenes into levels."

An engine quality gate: two-channel checking

The engine also raised a two-channel quality gate this day, automatically checking code quality from two complementary angles: one channel does conventional style and convention checks, the other specifically watches the usage boundary of "internal interfaces" — ensuring things meant for internal use only aren't unintentionally exposed as public. Both channels run in continuous integration, automatically on every commit. Its value is of a piece with the earlier rendering benchmark: turning "is the code quality right" from human review and self-discipline into an automatic, objective, unavoidable gate. An engine meant to evolve long-term and face ever more collaborators relies on gate after automatic gate to iterate fast without slowly rotting.

What this day means

The day's two lines represent exactly the two ends a mature product must hold at once: one is the user's present feel, the other the platform's long-term skeleton. The chat interface's maturation makes it more comfortable to use right now, while the backend's nearly invisible plugin runtime plants the seed for "whether this platform can be extended without limit later." Caring for the present and investing in the long term on the same day takes clear division of labor and judgment about priority — which are experiences that must pay off immediately, and which are foundations worth laying solidly even if slower. That's an experience worth leaving for future development: don't only pile on visible features, and don't only bury yourself in invisible foundations; the truly hard thing is to shortchange neither.