AI Infrastructure · Local Lab
A local AI workspace and laboratory built on a 48GB Apple Silicon Mac. Not a chat interface. An environment for designing and studying the shape of human-AI collaboration — from model management to agentic workflows to supervision patterns.
icuboid Studio is a local AI workspace that I built, maintain, and use daily. It manages the local model stack (Ollama and Forge), provides a full agentic chat environment, and serves as the primary laboratory for designing and testing human-AI interaction patterns.
The design question behind it: what should an AI operating environment look like when it's designed as an environment for humans, not just a conduit to a model? How do you design the workspace, the tool loop, the skills system — as a designer rather than just an engineer?
Running on a 48GB Apple Silicon Mac, the Studio manages several local models:
Auto model routing dispatches each message to the right model based on a vision/coding/general heuristic — the user doesn't need to think about which model to use for which task.
The chat environment runs a tool loop with a maximum of 8 iterations. Available tools: list_files, read_file, write_file in a sandboxed workspace directory, and run_command (toggle-gated — the user controls whether shell execution is enabled). Tool calls are shown as collapsible boxes in the chat, not hidden. The human can see exactly what the agent did.
This is deliberate: the Studio is a design research environment. Hiding the tool calls would make it harder to study how the agent uses them. Every design decision in the Studio is made in service of observability over convenience.
Skills are SKILL.md files with YAML frontmatter (name, description) in a skills/ directory. The agent discovers available skills via a read_skill tool, reads the instruction set, and applies it to the task. Users can also force a skill via a dropdown — the instruction content is injected directly into the system context.
The skills system is compatible with Anthropic's open-source skills format. Instruction-only skills drop straight in. The first skill built for Studio: icuboid-prototyper.
The Studio has an MCP (Model Context Protocol) client built on the official SDK. It supports stdio and streamable-HTTP/SSE transports. Configuration is via mcp-config.json. Tools from connected MCP servers merge into the agent's tool loop. The Settings panel shows server status and supports reload.
Session 4 backlog includes wiring the n8n MCP connector — once connected, the agent will be able to trigger n8n workflows from within a Studio conversation.
Building a reliable app launcher for macOS was the most technically difficult part of the Studio build. Five approaches failed before one worked.
The failures: .app bundles spawning detached children reaped on exit. Stay-alive scripts killed by RunningBoard. launchctl submit deprecated and silently no-oping. LaunchAgent plists blocked from ~/Documents by TCC without any dialog. Files created by tools with provenance tags refused by Gatekeeper.
What worked: a user-created Desktop .command file that runs in a Terminal context with nohup. It inherits Terminal's TCC grant, survives window close, and is exempt from Gatekeeper because the user created it. The key insight: the file has to be created by the user, not by an automated tool, because macOS tags files with their creation provenance.
This is now documented as part of the Studio handoff. The learning generalises: on macOS, process management for local services is constrained by TCC, Gatekeeper, and RunningBoard in ways that aren't obvious until you've hit all of them.
Session 4 is porting the four Agent-First UX patterns from A1OS into the Studio. Build order: approval mode (Graduated Trust, the centerpiece) → task timeline (Legible Autonomy) → per-conversation deliverables (Outcome Over Process) → handback summary card (Accountable Handback). Each pattern will be demonstrated with a recorded scenario using devstral as the agent.
The Studio is the right environment for these patterns — unlike A1OS, which was a standalone prototype, Studio is a system people actually use. The patterns in Studio will be evaluated in real use, not just demonstrated in controlled scenarios.
Architecture
Session 4
Patterns origin
A1OS — where the patterns were demonstrated →