Relationship to Other Tools

Musketeer is one part of a larger ecosystem. It does not replace other tools. It sits in a specific place and does a specific job. This page clarifies the boundaries.

Musketeer sits upstream

Imagine a pipeline from thinking to artifact. At one end, you have raw intent. At the other end, you have running code. Musketeer sits near the thinking end. It coordinates how intent becomes instruction. It does not manage how instruction becomes artifact.

This is deliberate. Execution is a solved problem. Many excellent tools manage execution. Musketeer focuses on the part that is not solved: the coordination between different kinds of thinking.

The models themselves

Musketeer does not replace your models. It coordinates them. You still need:

• A conversational model for the Originator role (ChatGPT, Claude, etc.)
• An executor model for the Executor role (Claude Code, Codex, etc.)
• An analytical model for the Cross-Examiner role (Gemini, or any model in a verification prompt)

Musketeer does not privilege any vendor. Use what works for you. The discipline is about role separation, not about specific tools.

Agent frameworks

Agent frameworks like LangChain, AutoGPT, and CrewAI manage autonomous agent execution. They provide loops, memory, tool use, and decision-making.

Musketeer is not an agent framework. It does not provide autonomy. It does not loop. It does not make decisions. It prepares handoffs that a human reviews and approves.

If you use an agent framework, Musketeer could prepare the handoff that initiates an agent task. The agent would execute autonomously. Musketeer would receive the result for review. But Musketeer itself does not run the agent.

Workflow engines

Workflow engines like Airflow, Temporal, and Prefect manage execution graphs. They handle dependencies, retries, scheduling, and distributed execution.

Musketeer is not a workflow engine. It does not manage execution graphs. It does not schedule tasks. It does not distribute work.

Musketeer produces handoffs. Those handoffs could trigger workflow engine tasks. The workflow engine would manage the execution. Musketeer would have no knowledge of the execution internals.

Execution runners

Runners execute bounded tasks. They take an instruction and produce output. Claude Code is a runner. Codex is a runner. These are the tools that actually write code.

Musketeer coordinates what those runners receive. The Executor role is filled by a runner. But Musketeer does not control how the runner operates. It prepares the handoff, then stands back.

SMALL and state management

SMALL is a companion project that manages execution state. It tracks what tasks have run, what outputs were produced, and what the current state of a project is.

Musketeer and SMALL are complementary. Musketeer coordinates handoffs. SMALL tracks execution state. Musketeer might produce a handoff that SMALL then tracks. They operate at different layers.

Version control and files

Musketeer produces files: handoffs, intents, constraints. These files live on disk. They can be version-controlled with Git like any other artifact.

This is deliberate. Files are interoperable. They do not require special tooling to read. They can be processed by any system that reads text. Musketeer does not lock you into a proprietary format.

No hierarchy, just boundaries

Musketeer does not sit above other tools. It does not orchestrate them. It does not manage them. It has a specific responsibility: coordinating handoffs between cognitive roles. Other tools have other responsibilities.

The relationships are horizontal, not vertical. Musketeer prepares. Runners execute. State managers track. Each does its job.

What Musketeer enables

By sitting upstream and producing structured handoffs, Musketeer enables:

• Clean integration with any executor tool
• Auditability of intent before execution
• Human review at the handoff boundary
• Interoperability through plain text files

Musketeer does not try to be everything. It tries to do one thing well.