Archived experiment: local workflow tooling for coding-agent configuration, MCP servers, skills, and reference repos.
Saddle was an exploratory project for improving local workflows around AI coding agents. The original goal was to create a lightweight control layer for managing agent modes, MCP servers, skills, and nearby reference repositories without having to duplicate configuration across every coding-agent client.
The project is now archived because the core idea proved more complex and less ergonomic than the problem it was meant to solve.
Saddle was intended to help with two recurring problems.
Many coding-agent clients support MCP servers, skills, custom tools, and project instructions, but each client tends to manage them differently.
The initial goal was to provide a shared local catalog where MCP servers and skills could be:
- installed or referenced once;
- versioned and inspected;
- grouped into modes such as
research,plan,build, orreview; - exposed to different agent clients;
- synced into client-specific config files;
- checked for upstream updates or local modification drift.
I often want one agent to work in a primary target repo while reading other local repos as reference context.
For example:
workspace/
target-app/ # writable
framework-ref/ # read-only reference
tool-ref/ # read-only reference
The hope was that Saddle could make this topology repeatable, allowing agents to read nearby framework, library, or tool repos without relying as much on web search.
The premise was reasonable:
- agent clients are proliferating;
- each client has its own MCP configuration format;
- local skills and prompts can become duplicated;
- reference repos are useful context;
- worktrees are useful for isolated implementation tasks;
- different tasks benefit from different toolsets and permissions.
Saddle was an attempt to make these concerns explicit and reproducible.
In practice, Saddle would introduce a new layer of coordination on top of tools that already have their own configuration models.
For a small number of agents and clients, that extra layer becomes a bottleneck:
- Codex, Claude Code, Cline, OpenCode, Goose, Amp, and editor integrations each have their own MCP setup;
- each client has different assumptions about project config, global config, permissions, and launch environment;
- changing a mode in Saddle would often become a prerequisite before using the underlying client;
- generated config can obscure what the actual client is doing;
- editor integrations may not respect the same environment or generated config path as a terminal session;
- global MCP installs still need to exist somewhere, so Saddle would not fully eliminate external setup.
Instead of reducing friction, Saddle risked creating a second configuration system that had to be kept in sync with the first.
The main ergonomic issue is that Saddle would sit between the developer and the agent client.
A typical desired workflow is:
open editor → use agent
Saddle risks turning that into:
choose Saddle mode → render config → confirm generated files → open editor → use agent
That can be worthwhile for a large multi-agent system, but it is too heavy for everyday use with a few agent clients.
Other bottlenecks:
- Mode switching becomes indirect. Instead of using a client’s native settings, the user must remember to update Saddle first.
- Generated config adds opacity. Debugging requires checking both Saddle’s source config and the client’s final config.
- Client behavior diverges. A setting that works in one client may not map cleanly to another.
- Editor support is inconsistent. Terminal-launched agents can receive explicit environment variables, while editor integrations may use their own paths or managed runtimes.
- MCP installation is not actually solved. MCP servers still need to be installed, runnable, authenticated, and updated through each ecosystem or a separate manager.
- Reference repo safety is hard. Read-only intent is not the same as enforced read-only filesystem access.
- Worktrees help, but do not remove config complexity. Each worktree can carry project config, but per-mode and per-client behavior still needs careful handling.
The central flaw is that Saddle tries to normalize tools whose value partly comes from their own native workflows.
A universal layer only makes sense if it provides a large enough benefit to justify becoming the new source of truth. For my current usage, the benefit is not large enough.
Saddle should not become a general agent-client manager.
The better approach is to use each client’s native configuration model directly, keep MCP usage minimal and intentional, and rely on conventional development primitives where possible:
- git worktrees for isolated tasks;
- project-level instructions where supported;
- client-native MCP configuration;
- global MCP managers only when they clearly reduce duplication;
- simple local documentation for preferred modes and workflows;
- read-only reference repos by convention or container mounts when stronger isolation is needed.
A narrower version could still be useful someday, but only if scoped very tightly.
Potentially useful future scopes:
- a Codex-only project profile helper;
- a simple MCP inventory/status command;
- a worktree launcher that does not own client config;
- a documentation generator for local agent setup;
- a read-only reference repo mounting helper.
Any future version should avoid becoming a universal agent abstraction layer.
This repository is archived as a design exploration.
The project clarified the problem space, but the current implementation direction would likely add more workflow overhead than it removes.
The useful lesson is not that shared agent configuration is a bad idea. It is that, for small-scale personal use across a few fast-changing agent clients, a meta-configuration tool can easily become another thing to manage.
For now, native client configuration plus lightweight conventions is the simpler path.