Personal AI Platform: Key Architecture Design

This is the personal AI platform I use for sustained engineering, research, and creative work. It serves several people, runs model inference on my own hardware, and turns that inference into agents that can inspect sources, use tools, produce editable files, and continue an assignment across pauses and review.

Penny Royal is the customized SGLang runtime I built for shared local inference. Open WebUI provides the multi-user browser work surface. Pi provides a dedicated coding environment. Customized Hermes supplies an independent harness for selected tasks. A standalone Penny executor coordinates durable assignments through OWUI or Pi, while Codex supplies the separate supervisor and review surface. Native Linux identities own tool execution; Versity Agent Library retains file originals; image, speech, and document tools extend the same working system.

Data sovereignty is a core property of work executed entirely through Penny. Model inference, conversations and coding sessions, tool execution, media processing, and durable files remain on operator-controlled hosts. Connected research supplies outside information through the requests sent to search providers and websites. The OpenAI-backed Codex supervisor is a separate model and conversation path.

My runtime work has brought generation speed to nearly 2× the original stock setup. The architecture combines a 524,288-token served context window, reusable prefix state across GPU memory, host RAM and SSD, identity-aware tools, event-driven task coordination, and authenticated file delivery. The following chapters show the components and the paths that connect them: from an interactive conversation or coding assignment to model execution, native tools, retained state, and a finished result.

A search provider receives the query sent to it; a visited website receives ordinary browser requests. Penny evaluates the returned material using local inference. Codex has its own OpenAI-backed model interaction and saved conversation, separate from this Penny-local path.

Figure S1 — Penny data sovereignty boundary

The local S3 interface is Versity storage. User grants and native identities determine which tools and objects an account can reach. OWUI and terminal file routes provide authenticated delivery to people, while temporary storage URLs supply selected inputs to processors.

These capabilities meet in real workflows. A general assignment can inspect a set of files and create an editable presentation through OWUI. A coding assignment can use Pi to examine a repository, change source in an isolated worktree, and return a patch. Both can pause for a decision and resume under the same durable task identity.

The system separates the model service from the environments that use it. Penny Royal owns inference and reusable computation. OWUI owns authenticated conversations and browser interaction. Pi owns coding sessions and its repository tool loop. Customized Hermes owns the harness and working state for its selected tasks. The executor owns assignments that outlive a single response. Native accounts own commands and working files; Agent Library owns durable originals for the OWUI file path.

The data plane carries model requests, tool inputs and outputs, media, and files. The control plane carries authentication, grants, task lifecycle, steering, notifications, and human decisions. A notification can wake the supervisor without carrying the full work trace. A signed processing URL can supply an image to a renderer while a different, authenticated route serves the result to the user.

Shared capability installations supply the tools; native identities supply their writable state. A browser or document renderer can be installed once while user profiles, downloads, source changes, and working documents remain under their own accounts.

Figure 1 — Logical architecture

The overview shows the standalone executor feeding OWUI and Pi, with Customized Hermes handling selected tasks through its independent harness. All three share Penny Royal inference. Identity routing, native execution, specialized capabilities, and file storage complete the working paths.

OWUI runs as a rootless Podman application container. The executor, Pi, Customized Hermes, identity router, and Open Terminal instances are native processes outside that container. OWUI reaches the router through the host gateway, and the router selects the terminal mapped to the authenticated user. The coding route runs under its dedicated native identity.

Neomatrix’s RTX 5090 supplies a second GPU domain. AI Tools on thegrid calls ComfyUI there for image generation and editing; OWUI calls Dubline there for speech recognition and synthesis. Codex Desktop also runs on the workstation, with its own external model connection. Language-model, image, and speech workloads therefore have distinct execution and resource paths.

Browsers and phones enter through Caddy on thegrid and authenticate in OWUI. User downloads pass through OWUI or its terminal proxy. Durable originals remain in Versity storage, separate from the chat database, native working files, and inference cache.

Figure 2 — Deployment architecture

The placement view nests room101 inside thegrid and distinguishes its application container from native coordination and execution. Cross-host calls connect inference, image processing, speech, storage, and the supervisor.

That separation allows several agent environments to share one accelerated model service while keeping their own working state. The standalone executor coordinates durable OWUI and Pi assignments; Hermes has its own session and tool loop.

On 21 October 2026, Penny Royal 3.1’s native NEXTN MTP/FR-Spec profile, using my OrcaRouter Qwen3.8 Flash-Next ModelOpt NVFP4 checkpoint on one RTX PRO 6000 Blackwell, averaged 252.83 output tokens/s through a completed coding workflow and 216.23 output tokens/s through a completed ten-slide presentation workflow. Both ran at medium reasoning with one generating request and block-8 verification. These active generation means include reasoning; prefill, tool execution, rendering, and idle time are separate. The current measurements carry the full settings and results.

The maintained default is native NEXTN multi-token prediction with FR-Spec. A target runs the request and its own prediction path proposes candidate steps, so there is no separate draft checkpoint to load or keep in step. DFlash2 is an optional external drafter over the same target weights and the same cache hierarchy. A separate draft model proposes candidates, and FlashInfer on the SM120 GPU verifies them.

In both configurations the target remains authoritative over accepted tokens, and speculative width follows active concurrency: a wider batch of active requests narrows the width spent per request. The GPU key-value pool is shared and sized automatically at startup inside the profile memory budget. The acceleration comes from doing useful work ahead of verification and making each execution phase cheaper. Correct continuation requires the model state to match the accepted tokens after every verification step.

Figure 3a — Inside the selected inference profile

The Flash-Next path coordinates attention, recurrent state, sparse-attention indexing, and native draft prediction. FR-Spec reduces draft scoring work while target verification retains the full vocabulary. An optional DFlash2 drafter replaces the native proposal path and keeps the same verification authority. Recovery returns every dependent state component to the accepted token path before generation continues.

Figure 3b — An inference request

A client assembles the request; Penny Royal tokenizes it, looks for reusable prefix state, computes the remaining input, and generates a response. A tool call returns to the client for execution. The resulting tool output becomes part of the next assembled request, creating another opportunity to reuse the unchanged prefix.

Penny Royal keeps reusable prefix state in three local tiers:

All three tiers run on thegrid. Requests, cache writes, restoration, and generation stay on my own hardware. The SSD tier is optional. The GPU pool and host RAM tier carry reuse on their own, so GPU and RAM reuse remain available whenever disk persistence is disabled. The 524,288-token served window is the capacity of one model request; the shared GPU state pool and lower cache tiers support active and reusable prefixes across requests.

Saving attention KV alone would leave other parts of the model out of step. Penny Royal’s persistence path saves and restores the complete compatible representation, with recovery and load ordering that bring its components back together before continuation. The 27B/DFlash2 profile has the corresponding requirement for its target, draft, and recurrent state.

The large PLE model table has a separate role: it is shared model data, distinct from the context-dependent PLE state in a cached prefix. Its RAM or optional SSD placement is handled separately from NIXL’s computed-prefix storage.

Compatibility includes the model, tokenizer, precision, state layout, and relevant speculative configuration. Cache namespaces keep different representations separate, and two speculative configurations over the same target weights do not make their cache representations interchangeable. A compatible restart can reuse persisted state; a representation change starts with a fresh namespace and recomputes its prefixes.

Figure 4 — Cache hierarchy and request reuse

A Flash-Next restart check on this system restored 489,856 of 489,879 input tokens, recomputed the remaining 23, and returned all three exact long-context markers. It demonstrates the intended architecture: a nearly full context window can resume from complete persisted model state on local SSD, with only the unmatched tail requiring fresh computation. The SSD tier is the optional part of that picture; the complete-state hierarchy below the request path is not.

Compaction and caching also serve different purposes. Each client decides which material belongs in the next prompt. Penny Royal decides which computation for that prompt can be reused. A restored prefix still occupies the request’s logical context budget; reuse reduces the work needed to process it.

OWUI retains the full saved chat while compaction can replace older model-facing turns with a checkpoint summary and recent working context. Compaction runs before model calls, including tool continuations. The context indicator displays the latest provider request’s input usage against the configured model window, with estimated or unknown readings identified separately.

The deployment retains built-in file tools while disabling automatic File Context injection. Penny deliberately selects and reads an attachment through a visible tool path. That supports file-intensive work in which the selected source and the resulting tool output matter to the next step.

Figure 5 — Request context is assembled from layers

Context assembly determines what reaches the model. Prefix caching determines how much computation can be reused for that request. The request still occupies its logical token budget when part of its prefix is restored from cache.

Pi manages the context of its own coding session. The executor retains the assignment and routes continuation to the selected environment; OWUI’s context display and compaction settings belong to the OWUI path.

The personal OWUI fork also includes a skill-proposal path. Background review or an explicit learning request can draft a procedure from a user’s tool-using conversation and stage it in the owner’s Skill Creation folder. The owner can approve, reject, or request revision. Approval checks the staged change and intervening edits before the personal skill becomes discoverable in later work.

Figure 5a — Human-in-the-loop skill creation

The proposal, revision, and approval loop turns a useful procedure into an owner-controlled capability. Shared capability installations and access grants remain centrally managed.

Codex submits the objective, source context, boundaries, and originating supervisor destination. The executor creates a durable task ID and workspace, records compact state in its ledger, and starts the selected environment. The task can continue across multiple invocations, pause for input, or return a result for review.

General assignments can use the browser, research, file, media, and document capabilities exposed through OWUI. Coding assignments use Pi’s native repository tools and engineering guidance. Pi has its own session and tool loop, with isolated source changes and reviewable patch output.

Both environments call Penny Royal for inference. The executor manages the assignment while the selected environment manages model turns, tool calls, and the detailed execution trace.

The executor’s configured capacity is three active tasks shared across the two routes. A running assignment occupies a slot. Paused work and completed results retain their state while releasing execution capacity; a full executor returns busy. Repository work can use an exact base revision and an isolated worktree. Research or document work can begin in a task workspace without a checkout.

For OWUI work, continuation uses the saved worker chat and native workspace. For Pi work, it uses the retained coding session and worktree. A pause preserves completed actions and the source changes already made. Review feedback returns to the same durable assignment.

The notification path uses a restricted receiver to queue attention on the supervisor’s originating host. The supervisor reads current state when it wakes, so task status, results, and steering stay anchored to the ledger rather than to the timing of a notification.

The human owner sets the objective and decides consequential scope and release steps. The executor and work environments provide the retained state, tools, and return path that make sustained delegated work practical.

A helper finishing on its own cannot mark the parent assignment complete. Completion needs the helper result to reach the parent model context, the parent to incorporate it and respond, and Pi to settle.

OWUI’s existing helper route stays a separate mechanism, and the supervision boundary does not change: Codex still reviews the actual returned work.

Figure 6 — Event-driven multi-agent assignment and return

The sequence follows an assignment through execution, retained state, notification, review, and continuation. General and coding work share the coordination lifecycle while retaining their own execution state. The Pi column also shows the single native async helper lane and the return it must reach.

Shared binaries and skills live in a centrally managed capability tree. User-written files, browser profiles, caches, and experiments live under that user’s account. The platform owner’s private presentation assets are in a separate private capability tree. This makes it possible to share a document renderer or browser installation while preserving separate writable state and private material.

Pi uses a dedicated native coding identity for its sessions, task workspaces, and isolated worktrees. That route shares the model service and durable executor with general assignments while retaining its own tool loop and source changes.

Capabilities are additive. Global access stays narrow, and groups supply model, research, image, workspace, document, or private resources. This avoids a separate model copy for every person’s combination of permissions. It also keeps personal interface preferences under each user’s control: deployment reconciliation manages shared invariants and selected prompts/grants, rather than treating every user-owned setting as drift.

The shared browser illustrates the difference between installation and state. The agent-browser binary and matching skill are installed once. Browser processes, profiles, sockets, downloads, and screenshots live under the invoking user’s home. The default persistent browser session lets one user’s task continue across tool calls, while concurrent browser jobs under that same account require distinct sessions. A web page’s contents and metadata are treated as input to evaluate, not instructions with authority over the agent.

Thegrid’s shared NFS artifact mount maps client identities to one server-side identity. Native terminal services therefore use filesystem and mount-namespace boundaries to separate user-private paths. This is a specific correction to a real infrastructure constraint, not a generic claim that NFS permissions enforce per-user privacy in this deployment.

Figure 7 — From grant to operating-system identity

This small trusted-group design uses OWUI ownership checks and Unix ownership. Shared NFS artifact storage uses squashed identity, so native terminals hide protected paths through service mount namespaces; server-side mode bits alone cannot separate those paths.

The identity router uses the mapped user’s library identity for private and shared objects; a missing mapping does not fall back to another account. Renaming changes display metadata while retaining the same object identity and bytes. Neither behavior is a substitute for application authentication at download time.

An OWUI upload hook archives files handled by its upload path, including native MCP image responses. When a chat attachment goes through the terminal router, the router archives it before forwarding a workspace copy. Library tools let Penny list, fetch, publish, and rename objects within the mapped user’s permissions. A new published result receives a new identity rather than overwriting the earlier object. The library is not a replacement frontend; the user normally remains in OWUI.

For coding assignments, Pi retains repository changes and outputs in its task workspace. The library path described here serves OWUI’s uploaded files and selected artifacts.

Library keys are UUID-prefixed so two uploads called image.png do not collide. The original filename and a display name can remain metadata. Renaming the display name updates metadata on the same key and preserves the object identity and bytes. A new output publish assigns a new UUID rather than replacing an older original. These mechanics are mundane but important: agent work often produces iterations, and overwriting an input or losing the distinction between a filename and object identity would make later retrieval unreliable.

Two ingress paths serve different user actions. OWUI’s upload hook archives content handled by its file upload route and preserves OWUI’s own file ID for display. A terminal attachment passes through the identity router, which archives it before placing the UUID-prefixed working copy in the user’s workspace. Both paths avoid forcing a user to manage a separate S3 console for ordinary work. The standalone storage Explorer remains an administrative or direct-storage interface, not the normal OWUI file-delivery path.

A library fetch returns a working copy that tools can read or edit. A publish call records a deliberate output in the library. Fetch and publish can return an OWUI-relative download route, which Penny can present without inventing a URL. OWUI and its terminal proxy still authenticate the browser request. This is why the location of the working copy matters: removing a copy that backs a current terminal download link breaks that link, even though the library original remains available for another fetch.

Figure 8 — File lifecycle and delivery

The browser does not need direct S3 access. Library-only results can be fetched into the user’s workspace and delivered through the authenticated terminal file route. Files already owned by OWUI use its authenticated file route. A live download link depends on the working copy remaining present; the durable library object can be fetched again if needed.

Image editing has a different internal input path: a selected library object can receive a short-lived signed URL for ComfyUI to read into memory. That URL is for service-to-service processing and is not the user-facing download link. The integration issues these URLs for a limited processing window.

This architecture makes a useful separation: the original survives beyond an individual chat, tools get disposable working copies, and people receive files through their authenticated application. Backup and restore of all library state are a separate operational question; the existence of S3-compatible storage alone does not prove a tested restore.

The integration’s configured upload limit is 512 MiB. The router spools its transfer to private temporary storage, but upstream OWUI proxy and Open Terminal paths still buffer some uploads in memory. This affects capacity planning for very large files and prevents the library chapter from implying a fully streaming, arbitrary-size pipeline. It does not change the normal object identity or authenticated download model.

The durable library comprises Versity objects, metadata, IAM state, and application mappings. OWUI retains its own chat database and display files. These storage domains preserve different parts of the user’s work.

Dated multi-user acceptance exercised these boundaries directly: duplicate filenames remained independent, OWUI and fetched-library downloads matched original bytes, one user’s private object was denied to the other, and unauthenticated download attempts failed. Those tests validate the selected paths at the time they ran; they do not replace review when the application fork or storage integration changes.

Research services return information for Penny to evaluate and cite. The interactive browser is a stateful Chromium session running through a user’s native terminal, with that user’s profile and downloads. It can continue across tool calls; page content remains untrusted input. The distinction matters because finding a page and filling a form are different activities with different state and consequences.

For images, AI Tools owns the named MCP contract and invokes tracked ComfyUI workflows on Neomatrix. ComfyUI performs generation or editing; image bytes return to the harness for archival and authenticated display. Agent Library supplies selected edit inputs through temporary signed URLs rather than a permanent shared input directory.

For speech, OWUI owns microphone upload, transcription display, read-aloud interaction, and personal voice selection. Dubline on Neomatrix owns local decoding, speech inference, voice references, and GPU serialization. The current integration uses MOSS transcription and IndexTTS output. Speech and ComfyUI share workstation GPU resources; this build does not claim a general scheduler for them.

Document tools run in the native user’s workspace using shared installations and, when granted, private assets. That places generated files within the same identity and delivery scheme as other agent work.

Browser Research and Interactive Browser solve different tasks. Browser Research selects, retrieves, and extracts information from the web. Interactive Browser operates a persistent Chromium session under the user’s native Linux identity. It can click, enter text, navigate tabs, wait for page state, and handle downloads across terminal calls. The agent reads the installed browser skill and uses the browser’s accessibility snapshot and element references rather than assuming page coordinates or inventing selectors. Its profile and socket are isolated by the user’s home, and page content remains untrusted even when it appears inside a tool result.

This distinction is relevant to enterprise workflow design. Research can inform a decision; browser interaction can change external state. The latter therefore needs an explicit user or supervisor checkpoint for credentials, CAPTCHA, or consequential external actions. The platform’s architecture makes that difference visible through capability grants and tool contracts.

An edit adds a source-selection problem. Penny can identify one to three Agent Library objects under the user’s library access, request short-lived source URLs, and pass them to AI Tools in the requested order. ComfyUI’s URL input node loads the images into memory for the edit graph. The signed URL is a transport credential with a short lifetime; it does not become a permanent artifact or a browser download link. The final PNG returns to OWUI, where the ordinary archive and display path applies.

The application fork’s native MCP image-reference handling matters at this boundary. A tool can return image content without first publishing a public URL. OWUI persists the display copy and supplies an authenticated reference. Model-facing guidance lets Penny embed that reference in a response while the server enforces access control. Generated-image and reference checks exercised this path.

Figure 9 — Specialized processing rejoins the authenticated user path

The separation keeps each actor’s responsibility narrow. Agent Library controls retained objects and per-user S3 access. AI Tools owns the image-tool contract and workflow selection. ComfyUI performs GPU rendering. OWUI owns the logged-in user’s display and download. The signed input URL is not displayed as a permanent artifact link, and ComfyUI does not become a general-purpose object browser.

Figure 9a — Image-edit sequence

The input contract matters. OWUI’s audio bypass passes the original uploaded recording through once, allowing the backend to maintain its decoding and speaker context. Without that bypass, OWUI’s normal preprocessing can convert or split a large upload before it reaches the speech model. The same bypass affects output processing, so the TTS provider is configured to request MP3 and the backend returns actual MPEG audio. Input and output behavior were therefore qualified together.

Read-aloud splits text by paragraph to stay within Dubline’s per-request limit. A single paragraph longer than that limit can fail explicitly; the system does not claim unlimited synthesis by virtue of splitting. Voice choice is user-owned in OWUI. A model-level voice override would take precedence and would undermine that personalization. Browser Voice Mode was accepted as a practical user flow, while individual voice quality remains a subjective choice.

Figure 9b — Speech ownership and return path

A successful speech backend response verifies only part of the user path. Transcription must reach the chat, Penny must answer, and playback must reach the browser for the full interaction to work. The same principle applies to image output: a successful ComfyUI render does not by itself verify OWUI persistence or authenticated display.

The architecture values editable outputs. A presentation remains a PPTX with source material and rendered pages for review. A hardware or network diagram remains a draw.io file with reusable shapes and connections rather than only a flat image. Catalog-backed assets improve the physical specificity of a diagram, but they do not validate an invented topology. Technical source facts and visual layout still require review.

Private brand capabilities can overlay the shared document stack. A deck owner’s approved assets and licensed fonts can remain in a separate private capability tree with corresponding OWUI grants. Application authorization and filesystem placement both protect them.

Execution. Pi runs the coding session under the dedicated native worker identity. The session is a native JSONL RPC conversation between the executor and Pi, and it needs neither OWUI nor Open Terminal on this path. Pi can inspect the repository, navigate source, change files in an isolated Git worktree, and run focused checks using Penny Royal inference for its model turns. The session and workspace retain the detailed work while the executor records progress and compact task state.

Pause and return. A question raised in the Pi session pauses the assignment, releases its execution slot, and keeps the session, workspace, and existing changes. The executor queues an actionable notification to Codex. The supervisor reads the current task record and question, supplies steering, and resumes the same assignment; resume continues the same Pi session and worktree without replaying earlier turns. Waiting releases its execution slot.

Review and result. Pi returns reviewable source changes and their checks. Completion has a precise definition on this path: Pi settlement plus the executor’s bounded shutdown of the running Pi process retires that invocation and frees its capacity slot, while the retained session and worktree stay available for review and resume. An executor restart reconciles interrupted Pi sessions before it admits new work. Codex examines the actual diff and behaviour, and returns any defects to the same task and worktree. The human owner decides acceptance and any publication or deployment. After review, Codex and I preserve the useful outputs and then explicitly request release; only then does the executor release the workspace, session, and patch material it owns. Otherwise inactive retention expiry applies: retention can be extended, active tasks are excluded, and an incomplete cleanup retries. Ordinary conversations, shared installations, and separately uploaded OWUI files keep their own lifetimes through all of it. A general assignment follows the same coordination path through a saved OWUI chat and its granted tools.

Figure 10 — Engineering assignment control and evidence

Figure 10 stops where the reviewed source and its evidence are recorded. Figure 10a, shown below, continues from that point through resume, restart recovery, and closeout. Codex and I preserve the useful review outputs first and explicitly request release; only then does the executor release the workspace, session, and patch material it owns. Otherwise inactive retention expiry applies: a retention extension keeps that material for a stated period, active tasks are excluded from expiry, and a cleanup that fails is retried rather than recorded as done.

Figure 10a — Coding task closeout and retention

In a later chat, Penny lists or searches the user’s allowed library space and fetches the exact source. The terminal receives a working copy under the user’s Linux identity. A display-name change can make the object easier to locate without changing its stable ID or bytes. If the task is an image edit, Penny requests a short-lived source URL and supplies it to AI Tools in an explicit input order. ComfyUI reads the source into the edit graph and returns PNG bytes through AI Tools. OWUI archives and displays the new image. A deliberate publish operation can retain the final result as another library object, leaving the input unchanged.

The download path is independent of the S3 processing URL. OWUI can serve its own file object through its authenticated file API. A library-only object can be fetched into the native workspace and presented through the authenticated terminal file route. If that workspace copy is removed, its existing terminal link may stop working; the library object can still be fetched again. That behavior is visible in the architecture and preferable to treating a temporary signed storage URL as a permanent deliverable.

The same pattern applies to non-image files: preserve an original, work on a copy, publish deliberate results with distinct identity, and let the application mediate user delivery.

1. Brief and authority. The deck owner supplies the audience, argument, approved facts, and source material. The private presentation capability is granted only to the authorized OWUI identity. Its brand overlay and licensed assets live in a private filesystem tree; generic presentation tools are shared.
2. Creation. The agent uses the private capability within the owner’s native workspace. The toolchain creates editable slide content and a PPTX, rather than a slide-shaped raster image. Source material and intermediate files remain available for revision.
3. Review. The deck is rendered to pages and inspected for hierarchy, font use, legibility, overflow, visual consistency, and fidelity to the brief. The deck owner reviews technical and customer-specific claims. Large prose changes are made in the editable source and regenerated, preserving layout quality.
4. Revision and delivery. The owner requests changes through the normal conversation. The agent revises, rerenders, and returns the deck through authenticated file delivery. A deliberate library publish can preserve a result for later work.

The light and dark HPE examples below show the result of that workflow: private brand grants, shared presentation tools, native workspace ownership, editable PPTX output, render-and-review, and authenticated delivery. Customer facts remain subject to the deck owner’s approval.

Figure 11 — Presentation artifact pipeline

Rendered artifact exhibit

One branded deck, two presentation themes

The same editable content model was rendered through HPE light and dark brand themes. These reviewed page images demonstrate the private presentation capability built on the shared document toolchain.

Penny Royal addresses a different cost. If the assembled prefix is compatible with cached state, the runtime can reuse GPU pages or restore older state from HiCache/NIXL and prefill only the new tail. Application compaction decides what information enters the next prompt. Prefix caching decides how much computation required for that prompt can be reused. One mechanism does not replace the other.

The Flash-Next restart check restored 489,856 tokens from a 489,879-token input. For a long-running engineering agent, compatible prefix reuse avoids recomputing most shared context as new tool results and decisions accumulate.

For an engineering assignment, the supervisor examines the actual diff, relevant source, and focused checks. A fresh reviewer can investigate a concrete concern with a narrow source brief. Findings return to the same Penny task and worktree so the change and its corrections remain one piece of work.

Review effort follows the change. A substantive implementation receives source and behaviour review; a prose or layout change receives an editorial and rendered check. Repeated findings that expose a design problem bring the work back to a human decision.

Figure 12 — Bounded multi-agent review and architecture stop

The workflow connects implementation, independent inspection, feedback, and the owner’s decision. Durable tasks retain the work across those transitions.

The same pattern extends beyond code. Editable presentation source survives a visual revision. A retained library original survives a later image edit. An owner-approved personal skill carries a useful procedure into a future conversation. Each result has an identifiable owner and a place to persist.

The metrics path covers the platform. Penny Royal publishes aggregate runtime counters and node_exporter publishes host counters on thegrid; Prometheus collects both and Grafana displays them. What I read there is workload, cache tier behaviour, latency, resource use, and whether each service is up. Conversation content and user or request identities stay out of it, which keeps the telemetry useful without turning it into a transcript store.

The Pi execution dashboard sits on room101 and covers the coding assignments. My Pi sessions feed it directly: their activity, transcripts, and tool output behind each task, shown view-only to everyone who can reach it. It observes work. It does not accept prompts, answers, resumes, or cancellations. Those control actions stay with the executor and the Codex supervisor, exactly as in Chapter 6.

Both paths are read-only in this architecture. Prometheus holds aggregate numbers with no identities; the Pi dashboard holds task detail drawn from Pi session state.

Figure 13 — Operational visibility paths

The figure keeps the two collection paths distinct: counters on one side, task transcripts on the other.

This inventory also identifies where a substitute implementation could fit. A different model server must preserve the model API and usable context/usage reporting. A different object store must preserve user-scoped object identity and signed processing inputs. A different browser harness would need equivalent authenticated file routes, saved execution state, and tool permissions before the agent workflow would retain the same properties.

A common source of architecture errors is to conflate these lifetimes. A NIXL namespace can be cleared while the conversation remains intact. A working file can be deleted while its library original persists. An OWUI chat can contain full worker output while the executor ledger carries only a compact review result. A source checkout can be present on a machine without being the revision selected by the running service. The design assigns each fact to the layer that can prove it.

1. Account grant: an administrator assigns OWUI capability groups. The model’s instruction text does not create access.
2. Terminal mapping: the router resolves the authenticated OWUI user to an explicitly allowed native identity. Unknown users do not inherit a default terminal.
3. Task submission: the supervisor supplies objective, boundaries, and a return target. The executor’s capacity limit can reject the submission.
4. Blocked task: a native question pauses execution while retaining state. The supervisor supplies an answer before the same task resumes.
5. Personal skill proposal: the owner accepts, rejects, or revises a staged candidate before it becomes persistent behavior.
6. Artifact review: a rendered deck, diagram, code change, or image result is inspected before it is accepted as finished.
7. Publication or deployment: reviewed source or customer-facing material moves outward only through a separately authorized decision.

These checkpoints are not a universal human-in-the-loop rule for every tool action. They are placed where this deployment crosses ownership, persistence, or consequence boundaries.