Ecosystem

Musketeer is a SMALL-native trio workflow harness. Pi is one runtime substrate it fits with cleanly, but Musketeer is not a Pi pack and not a substitute for the runtime layer.

Where it fits

OpenAI Agents SDK, Claude Code, Codex, Gemini workflows, local model runners, and custom agent systems operate at the runtime or tooling layer. In the broader stack, Pi is a preferred runtime substrate and Musketeer operates above that layer as a governed trio workflow harness.

Those systems help produce work. Musketeer helps control how one trio work cycle is:

• Staged
• Challenged
• Executed
• Reviewed
• Resumed

That is the boundary.

Not the substrate, not a direct substitute

If you need a runtime substrate, use Pi or another runtime. If you need a coding agent, use a coding agent. If you need tool calling, tracing, or model APIs, use the right substrate.

Musketeer is not trying to absorb those categories. It governs one trio work cycle around them.

What that enables

Because Musketeer sits above the runtime layer, it can structure work performed through:

• Hosted model APIs
• Local model systems
• Coding agents
• Task runners
• Custom worker processes
• Mixed-provider environments

You do not have to standardize on one vendor to use Musketeer well.

Why that matters

Most teams do not have one model, one toolchain, or one clean runtime surface. They have a messy stack. Musketeer does not ask them to replace it. It gives them a clean trio workflow harness they can run alongside Pi or other systems.

The simplest comparison

Use Pi or another runtime to host behavior. Use Musketeer when you want governed trio workflow boundaries around that behavior. That is the clean line.