In the last article, I described why the renaissance workshop was the best system to mirror when working with AI agents, personally and professionally. That piece, as the intro for this series, also mapped my own setup as five layers with a promise to go into each in detail.
This is the deep dive on my agentic studio bench: the curated and portable configuration that upgrades any machine with Claude Code (or any coding agent) and makes it mine within five minutes.
Welcome to The Workshop Series, Part 1.
Claude Code has a marketing problem
Claude Code has the center seat in my setup, because it is the most robust and capable platform to build true AI assistants today. It just has a naming and marketing problem (OpenAI’s Codex has it too; that is why they created ChatGPT Work).
OpenClaw went viral because it showed the world what an AI that actually did things was like. It was also marketed as a real AI assistant and, at times, it truly felt that way. All built by a single individual.
The hype around it has since cooled off because of reliability, context bloating, memory management and cost issues.
I did test OpenClaw too but, throughout, I couldn’t stop thinking that the official coding agent systems created by the labs had access to even better capabilities: they can operate a computer, manage files, connect to external tools, handle a tiered memory system and run overnight unattended.
So, why didn’t anyone pay attention to these and go crazy over OpenClaw instead?
The answer is perception. Claude Code is named and marketed as a tool for developers whereas OpenClaw and Hermes are positioned as personal AI agents. They are also invoked via messaging apps while the “coding” agents live naturally on a computer terminal (with its white-over-black look).
This is intimidating for non-technical people. If and once you get past that, it is the most stable, well-engineered harness around which to build your own team of synthetic artisans.
The out-of-the-box Claude Code is generic, though. It doesn’t know my context, memories, life domains, projects, identity or communication preferences. It is also clueless about how I like to communicate and work, the tools and software I use or how I like things done.
To close that gap, I have been building my own harness on top of the harness. A private repository that keeps evolving, that can be cloned into every computer, and that wraps the plain coding agent platform to make it into my own AI studio.
1. Instructions: what the model always knows
This is the base layer that loads into every session, regardless of the project or the device. Currently, it holds one core context file (CLAUDE.md) plus nineteen rule files. They handle my needs and wants for every new session (overall identity and communication style) and specifics I want to be triggered depending on the type of ask (development, knowledge work, design...).
Global
CLAUDE.md(global): The backbone: how the config is organized, the one hard rule on secrets, the self-improvement loop.communication.md: How I want to be communicated to: directness, Simplified Technical English, decision-support structure, the banned-jargon list.capability-routing.md: Which skill, agent or plugin for which job, across ~110 skills and 10+ agents.design-system.md: My own visual identity across software, tools, diagrams, documents, decks and generated images: Atelier.workflows.md: The way I like to work across areas: plan before building, subagent strategy, verification before “done”, revision strategy.
Specific
image-generation.md: Where generated images land, and why the routing is a hook rather than a habit.development/*: 7 different rule files that govern software development and coding projects: from tool selection to testing discipline and stack defaults.work/*: 4 files that introduce discipline around research, citations, document structure, verification and document management.chief-of-staff/*: 2 files that trigger specifics when working with email, messaging, cloud drives etc.
These 20 files load in every new session and pay a token tax (about 7,600 today) before the assignment even starts. Worth it.
The five global files are detailed instructions that govern how I want agents to work, and how I want to be worked with. The other fifteen guide my agents to activate certain mechanics, depending on the nature of the task. In other words, these files are triggers, not detailed guides.
Also important to understand is that the system of CLAUDE.md files acts as an instruction cascade. A user-level CLAUDE.md loads in every session whereas you can create others at project and folder levels, which load upwards, effectively creating a tiered rules system. Several folders and projects in my setup have their own CLAUDE.md (for example, a pet project I am working on to create a way to connect coding agents to multiple models).
2. Reference: what it reads on demand
The folder that contains the long and specific knowledge that is read only when an agent needs it for the task.
It currently stores eleven files. Here are some examples:
about-me.md: Identity, family, life domains, financials and projects.editorial-style.md: My writing style, encoded. For article review and editorial check, posts and tweets.secrets.md: The secrets model and the per-device functioning.knowledge-work-plugins.md: The Product Manager and Design plugins, with the detail of what fires them.research-sources.md: Every paid subscription I hold and the permitted method for reading each.compound-engineering.md: How the/ce-*plugin is used for a software development or app project.gemini-image.md: Image-generation mechanics: install, auth, models, per-image cost.obsidian.md: My library instructions. The document vault structure and conventions.browser-testing-artifacts.md: The mechanics and tools to test in the browser.
The reference library extends much further than this portable configuration as the document vault, synced in Obsidian, is accessed by my agents on demand. Inside it, 2,400+ notes give ad hoc content to my system when pointed to or needed, never loaded wholesale.
3. Memory: lessons learned and the improvement loop
Claude (and other equivalent systems too) gives you a native memory system that is on by default and doesn’t need any setup. As Claude works, it writes notes for itself: one markdown file per fact, a MEMORY.md index on top, and automatic recall in later sessions.
However, this built-in memory has (at the time of this writing) two limitations:
Memory is per-project: a lesson learned in one folder or repository is invisible in the others.
It is local: these memory files do not sync across devices.
While these limitations last, I patched them with two hooks (more on those below) and a rule:
A trigger (
capture-lesson.sh) reads every prompt and, when the language looks like a correction, reminds the model at that exact moment to ask whether a durable lesson exists. If confirmed, a taxonomy classifies each memory into one of four types, and the type decides whether it travels.A sync script (
sync-memory.sh) runs at session start, carrying the portable types through the config repo to every project on every device.
4. Tools: what gives my agents capabilities
Four different primitives give my agents skills and hands.
Skills. A skill is essentially a folder with a Markdown file inside that contains instructions for one type of job. Formatting a PowerPoint document. Auditing a codebase. Designing an ad. They can be written from scratch by you, borrowed from others (there is a huge offering of skills by creators) or created with the assistance of AI (the official ‘/skill-creator’ by Anthropic is really high-performing).
I currently use 82 (both mine and adapted), grouped by discipline.
development/:deep-review,dependency-audit,pr-prep,handoff,project-bootstrap,output-skill.design/:atelier-design(my design system), five interchangeable style skins,redesign-skill,emil-design-eng,taste-skill.chief-of-staff/: Vault work:obsidian-cli,obsidian-markdown,obsidian-bases; Email management:gmail-mgmtn.finances/:analyze-asset,analyze-balance.
What makes this number of skills usable is a property called progressive disclosure: at startup only each skill’s name and description load. The body loads on invocation, and bundled files load only if the body calls for them.
They can be invoked directly (via a slash command) or by an agent, based on the description.
MCP servers. While a skill adds knowledge and procedure to a model, MCP gives it hands. The Model Context Protocol is an open standard for connecting AI applications to external systems. And an MCP server is a small process that exposes a system’s operations as tools the agent can call directly (query the database, access this information, change this data, drive this browser). They give the agents access and reach.
A sample of the MCPs living on my setup:
context7: Current library and framework docs. Beats guessing from training data, and beats web search for API syntax.cortex-scout: Deep research, multi-source web search, and authenticated fetches through a persistent browser profile.playwright: Headless browser automation. The only browser tool that works on my server.chrome-devtools: Console, network and performance traces when debugging an app I’m building. Needs a display.pinchtab: Interactive local browser session. Needs a display.supabase: Postgres, the default data layer. Registered at user scope, so it carries account-wide write access and its own guardrails.netlify: Deploys. Backs the “make it live” default.nanobanana: Gemini image generation, wrapped so it reads its key from the vault at launch.Gmail: Gives it permissioned access to my personal Gmail accounts.Todoist: Allows my agents to manage my to-do list (and vice versa).
Plugins. A plugin is a set of skills, agents, scripts and MCP servers packaged as one installable unit. They are distributed through marketplaces (git repositories with a catalog file) and you can think of a plugin as a full workflow, versus a skill being one job.
I currently have fifteen running. Two created by me and run locally, thirteen from marketplaces.
as-editorial(mine, custom): A package with my tools for the newsletter. Research for articles, shape outlines, editorial reviews, promotional copy...as-design(mine, custom): Visual asset creation: images, infographics, diagrams, social media assets etc, based on my design system.compound-engineeringby Every Inc: An awesome plugin by Every that governs software development excellently. Highly recommended.impeccableby Paul Bakaus: 18 frontend polish commands.document-skillsby Anthropic:pdf,docx,pptx,xlsxmanagement.product-management,designby Anthropic: PM and design workflows that fire on prompt match.code-review,code-simplifier,feature-devby Anthropic: Review, tidy, and guided feature work.skill-creator,claude-code-setup,agent-sdk-devby Anthropic: Building and evaluating new capability.typescript-lsp,pyright-lspby Anthropic: Language servers.ralph-loopby Anthropic: Recurring prompt loops.
CLIs. As coding agents are very proficient at using the command line, the Command Line Interface is one of the most robust ways for them to interact with third-party software and services, without being agent-specific.
Currently, five are reachable by my agents:
defuddle: Clean markdown out of a web page, without a browser.gemini: Hosts the nanobanana extension that the MCP server is built from.netlify: The login that the Netlify MCP reads its credentials from.gh: Git repository management.obsidian-cli: Obsidian vault management and document handling.
5. Agents: the delegation system and specialists
Within a session, Claude provides four different native methods to assign work to agents.
Agents (general-purpose): The main agent (the one you interact with) can spin up subagents on demand and in the background, for a single ask, returning the result to the one that spawned them.
Specialized Agents: You can define (or borrow) your own specialist for recurring or complex tasks. A subagent definition includes detailed instructions, behavior, tools, model and permissions.
Agent teams give each worker its own session, a shared task list and direct peer messaging.
Dynamic workflows hand the control flow to a script instead of a model: agents do the work, code decides what runs when. A workflow is a JavaScript script that orchestrates subagents: the script holds the loops, the branching and the intermediate results, and the agents just do the work.
As frontier models get better, the need for specialized agents is arguably diminishing. However, I still find them more robust and, most importantly, consistent for certain types of tasks and projects.
These are a few of my specialized agents within the portable setup:
chief-of-staff(Fable): Strategy, planning for other agents, delegation, workflow creation.payments-expert(Opus): A specialist agent acting as an advisor in the payments and financial services industries.financial-advisor(Opus): Portfolio review, Spanish tax planning, mortgage and scenario modeling. Reads the live balance sheet rather than carrying facts in its prompt.visual-designer(Opus): Visual asset design, design system improvements.software-architect(Fable): Architecture soundness, schema changes, technology selection.fullstack-engineer(Opus): Executing an architectural plan end to end.ai-engineer(Opus): AI system design and production deployment.security-auditor(Fable): Compliance posture: SOC 2, GDPR, PCI, ISO 27001.
On top of these agents sits one shared capability. Define it once, and every form of delegation (including teams and workflows) can reach it.
6. Hooks: how rules are enforced
A rule is text in a context window, which the model may follow, or not. It can forget it under memory pressure or find it outranked by a competing rule.
However, a hook (a small script that executes automatically) runs at a specific point with no room for interpretation. The memory triggers in the third section are one instance of this.
Anything that must happen deterministically runs as a hook, and anything that benefits from judgment stays a rule.
Hooks currently in my setup:
capture-lesson.sh, fires on every prompt: Detects correction-shaped language and re-injects the capture instruction at the moment it applies, not at session start.sync-settings.sh, fires at session start: Merges the shared config into the device-local settings file that Claude Code writes to at runtime.sync-memory.sh, fires at session start: Mirrors feedback and identity memories across all three machines, and leaves them uncommitted for review.mirror-reference-to-cowork.sh, fires at session start: Copies the identity and voice files into the vault, so Claude desktop reads from one source of truth.nanobanana-route.sh, fires after any image call: Moves generated images out of the staging folder the server hardcodes, into the project or the vault, and slugifies the filename.atelier-verify.sh, fires after every edit or write: Checks the change against the design system.headless-guard.sh, fires before any display-bound browser call: Denieschrome-devtoolsandpinchtabon a machine with no display, and tells the model to re-plan with the headless browser.
The bench evolves, shrinks and travels
The anatomy of my custom harness, as described, grows and shrinks.
Every quarter, a scheduled cron job runs an audit that checks the level of usage of the different primitives (skills, plugins, MCPs, etc.) and proposes to remove some.
Anthropic itself expects this to trend toward “letting intelligent models act intelligently, with progressively less human curation”, and every evolution seems to delete a layer of somebody’s setup. Mine will continue to lose layers too.
A more capable model makes the instruction layer thinner and the identity and taste layers ever more valuable.
The setup is built to travel across devices and environments.
Rules are Markdown, skills are folders with a Markdown file, agents are Markdown with formatted descriptors, MCP is a standard across models, and hooks are small shell scripts. Plugins are a combination of the above.
The whole bench is mostly text and code in one repository, and one script wires it into a new machine. It is also what makes it compatible with any agentic coding system if I decide to switch.
I hope this sparks your imagination to build your own AI workshop bench if you haven’t yet. I am planning to open-source my set once its last sharp edges are smoothed out.
Next in the series: the workshop building, the always-on server where the agent teams live.
How does your current AI setup look like?