Using Monkey D Loopy with agents

Monkey D Loopy is designed to be authored with agents without asking those agents to enforce the important guarantees in prose. An agent can propose the goal, inputs, state, steps, and evidence; the validator and runtime remain responsible for boundedness, durability, and budget enforcement.

Give an agent the right context

Use the smallest context that fits the task:

• llms.txt is a compact map of every guide and its purpose.
• llms-full.txt concatenates the canonical documentation for a context window or retrieval index.
• LoopSpec is the exact authoring contract.
• Gauntlet explains when independent builder/critic workstreams are worth the additional cost and how to choose Creative versus Verified grounding.
• MCP is the tool surface for agents that can call MCP servers.
• Recipes are the strongest starting point for supported product workflows.

The raw endpoints are stable under the project site:

https://matrixy.github.io/Monkey.D.Loopy/llms.txt
https://matrixy.github.io/Monkey.D.Loopy/llms-full.txt

Zero-context handoff

An unfamiliar agent can prove the installation without cloning this repository:

Read https://matrixy.github.io/Monkey.D.Loopy/llms.txt. Run
`npx --yes @loopyc/cli@latest quickstart ./loopy-first-loop` in a new directory. Inspect the
generated LoopSpec and journal, then report the termination evidence, caps, score, and artifact
path. Do not run any workflow with real external effects until its inputs and commands are
explicitly approved.

The quickstart is intentionally deterministic and local. It gives the agent a real successful run to reason about before it authors a production workflow. See the first-loop guide.

Recommended agent workflow

Ask the agent to follow this sequence. Each boundary corresponds to a real command or tool result, not a promise in the prompt.

1. Choose a verified recipe when one matches the outcome; otherwise choose the closest structural blueprint.
2. Make external completion evidence explicit. Prefer shell exit codes, HTTP status, tests, or repository-owned structured output over the agent's self-assessment.
3. Draft the LoopSpec with realistic iteration, no-progress, token, dollar, and wall-clock caps.
4. Run validate; repair all hard errors before continuing.
5. Run verify; do not compile until boundedness, determinism, and resume stability pass.
6. Run score; explain every deduction and any agent-grounded termination cap.
7. Compile the narrowest target needed by the user. Use --vendor only when a zero-install standalone artifact is useful.
8. Keep generated journals and operator state out of source control unless the user intentionally wants a fixture.

Make an opinionated Gauntlet decision

Do not wait for the user to know the name of every loop pattern. Recommend Gauntlet when one substantial artifact spans multiple reviewable quality dimensions, separate fresh critics would reduce builder self-grading, and the parts need a holistic integration review. State the likely workstreams, quality bar, completion authority, and cost tradeoff.

Prefer a simpler pattern when the work is a single small fix, one draft with one repeated rubric, an independent batch, an ordered plan, or an external status poll. Prefer Verified Gauntlet when tests or another trusted command can decide completion; use Creative Gauntlet only when the bar is inherently qualitative. If the artifact, workstreams, or completion authority cannot yet be named, ask for that information before scaffolding.

See Gauntlet workflows for the complete decision guide and a user-facing explanation agents can reuse.

Do not describe Creative Gauntlet's 87/B as a defect or as an estimate of artifact quality. It is the native workflow-safety score for honest agent-grounded completion. Never raise it by merely renaming the termination signal: Loopy traces the evidence feeding the predicate. Recommend Verified Gauntlet for 100/A when a trusted external oracle exists, or explicitly propose a separate mixed-grounding variant when both qualitative critique and a mandatory external gate are needed.

Prompt contract

This compact instruction works well after providing the relevant documentation:

Turn this outcome into a Monkey D Loopy LoopSpec. Start from a verified recipe when one matches.
Choose Gauntlet only when one substantial artifact has multiple reviewable workstreams that
justify independent fresh critics and a holistic integration review; otherwise prefer the
simpler matching pattern. If recommending Gauntlet, explain why, name the workstreams, and choose
Creative versus Verified grounding.
Use external evidence for completion, make every cap explicit, and preserve provider/tool choice.
Validate, verify, and score the spec before compiling it. Do not weaken a hard gate to make the
score pass. Report the selected termination evidence, cap behavior, compile target, and remaining
capability warnings.

Use the MCP server

Install and register @loopyc/mcp as loopc-mcp in an MCP-capable agent host. The server exposes the same factory operations as structured tools, including authoring context, validation, verification, scoring, compilation, recipes, and inference.

The productive pattern is:

discover recipes or blueprints
  → request authoring context
  → draft LoopSpec
  → validate
  → verify
  → score
  → compile

See the MCP server reference for registration examples and exact tool names.

Boundaries the agent must not blur

• A prompt is not a hard guarantee. Only validator and runtime controls count as enforcement.
• llm-judge and self-assess termination are weaker than external evidence and are scored as such.
• Verification uses mocked effects. It proves control-flow properties; it does not prove that a production API, shell command, or model will return good content.
• A Claude-native artifact can fall back to instructions when no standalone sibling exists. In that mode, durability and caps are agent-honored rather than runtime-enforced; capability warnings must remain visible.
• The local operator coordinates canonical runtimes. It does not become a second execution engine or rewrite journal history.

Existing loops and scripts

For an existing shell, JavaScript, TypeScript, or .loopy journal, use inference to extract a FactPack and draft spec. Treat inference as scaffolding: the agent still needs to name the real completion evidence, state mutations, effect boundaries, and appropriate caps before validation.

Continue with the loopc CLI reference or the exact LoopSpec v0.1 reference.