Systems design for controlled machine work
Designing and building systems for machine-driven work that needs boundaries, visibility, and review.
Current work centers on systems for bounded machine execution, workflow control, reviewable output, and machine runs that survive pauses, approvals, and file-heavy work.
StealthEye
StealthEye is the systems work around bounded machine execution, multi-step workflow, human checkpoints, execution records, and technical review.
Current work
The main active system is StealthClaw. Current work centers on scoped runs, workflow state, approval-aware steps, reviewable output, and handling for files, logs, datasets, and other run material.
StealthClaw
A system for machine work that has to stay inside scope.
StealthClaw is the main active system. It is meant for machine work that does more than return a single answer. It is aimed at runs that touch files, move through multiple steps, produce material over time, or need a person to approve part of the process.
The practical questions are straightforward: what was the run allowed to do, what happened during it, where did it pause, what came out of it, and can another person review it later without reconstructing the whole thing from memory.
StealthClaw is being built around scoped task entry, multi-step workflow, pause and resume points, execution records, review surfaces, and first-class handling for logs, files, datasets, and other run material.
Where it is useful
It fits work that unfolds over time: file work, longer machine runs, workflows with approvals, and runs that need a usable record after completion.
What it changes
The point is not to make a model more conversational. The point is to make machine work easier to bound, easier to follow while it is running, and easier to inspect afterward.
Why it was built
A lot of current tooling is easiest to understand at the start and hardest to trust in the middle. The longer a run goes, the easier it is for scope, intent, and accountability to blur.
Current state
The work is active and real. There are working system surfaces for scoped runs, approvals, records, and review, with the broader system still under active development.
Scoped runs
Work begins from a defined task boundary and stays tied to that boundary as the run proceeds.
Run history
Important activity can be surfaced during a run instead of guessed at only after it is done.
Reviewable results
Outputs are kept in a form that another person can inspect later without relying on a summary alone.
Approvals and pauses
Sensitive steps can stop for a human decision and continue afterward without treating the whole run as disposable.
Files and logs
Files, logs, datasets, and other run material are handled as part of the workflow instead of side baggage.
Local and managed execution
The design is meant for real environments, including local systems and managed runtime paths.
Glass
A replay-first bounded investigation surface.
Glass is the open-source investigation surface. It is built for looking back at one saved session and seeing what code or an agent actually did without pretending to offer a full trace or more certainty than the bounded window supports.
The viewer moves through scene, change, evidence, and receipt. Replay is the front door. A local live shell exists, but in the current public surface it is secondary and local-only.
The repo currently ships a replay-first bounded showcase path, Scene System v0 with bounded claims and receipts, committed flagship and canonical scenario packs, green CI and fixture validation, and a validator that checks shipped .glass_pack artifacts directly.
What it lets you see
A bounded scene, declared-baseline compare, evidence rows and facts, and receipt detail when the support is present.
How it is used
Open the hosted flagship replay or a local glass pack, stay on Overview first, and move from scene to evidence to claim support without treating the viewer like a full-history trace tool.
Current shipped surface
Replay-first viewer, optional local ?live=1 shell, canonical fixtures, tests, lint, fixture validation, and direct pack validation.
Current boundary
The public repo is not presenting cloud-hosted Glass, final F-IPC transport, or full topology runtime as the shipped surface.
Where it matters
Situations this kind of system is meant for.
Multi-step runs
Work that moves through several steps over time instead of ending at one response.
Approval-gated work
Workflows where some actions should stop for an explicit human decision before continuing.
Runs that touch files
Cases where the work involves files, logs, datasets, or other material that has to stay attached to the run.
Review after completion
Situations where someone needs to inspect what happened later instead of only seeing the final output.
Paused and resumed workflows
Runs that do not happen in one uninterrupted stretch and need to continue without losing the thread.
Local and managed paths
Work that may start on a local system, use a managed runtime, or move between the two.
Current emphasis
The parts of the work getting the most attention.
Bounded execution
Entering work with declared scope and carrying that scope through the run.
Workflow state
Supporting longer runs with pauses, approvals, resumptions, and usable continuity.
Review paths
Leaving behind records and artifacts that make later inspection possible.
Contact
For technical discussion.
If you have a concrete reason to reach out, use the address below.