Limner: A Harnessed Image-generation Agent

A Harnessed Image-generation Agent: Claude reasons, Cloudflare executes, D1 remembers, OAuth is the only way in.

Limner is an Agent Harness and Model Context Protocol (MCP) server for orchestrating image generation across multiple pipelines, with durable memory for project context. This repository is rasa, the foundation variant of the Limner family. You deploy rasa as your own instance: free as in beer, no strings or data pipelines attached.

Contents

• The Harnessed Agent
• Decisions and dead-ends
• Architecture
• Stack
• Tool Surface
• Memory
• Managed Agent Setup
• Skills and Capability Surfaces
• Security
• Privacy Policy
• Prerequisites
• Quickstart
• Testing and feedback
• Roadmap
• The Limner family
• Contributing
• License
• Acknowledgments

The Harnessed Agent

Limner is explicitly built as a composable harness with clean seams:

• The reasoning loop runs on Anthropic's Claude Managed Agents platform. The model does the planning and the tool choice. It never holds provider credentials and never executes code.
• Tool execution runs in Cloudflare V8 isolates. Every tool call lands in a Worker: deterministic TypeScript with explicit bindings, not a shell. Image composition happens in-isolate (WASM codecs, raster ops, text rendering) so the common path costs nothing and leaks nothing.
• The seam between them is an OAuth-gated MCP surface. The agent reaches the tools the same way any MCP client does: dynamic client registration, a bearer token, and a typed tool contract at /mcp. There is no private side channel.
• Memory is a database, not a context window. Project briefs, style decisions, and progress notes live in D1 and survive across sessions. The agent recalls what it recorded last week instead of being re-told.

The same tool surface ships three ways from one codebase: the OAuth-gated Workers endpoint, a local stdio server, and a .mcpb one-click bundle for Claude Desktop. The stdio server identifies itself as limner-mcp (preview): stdio is the preview transport at v1, pending a refresh against the next MCP spec revision. The Workers and .mcpb surfaces carry no preview tag.

Decisions and dead-ends

The design did not arrive fully formed. The full record lives in docs/Limner_Cloudflare_CMA_Architecture.md: 22 dated decision records, a cost model, and five named off-ramp triggers that state in advance what would make us walk away from the approach.

Several of those records are reversals. The FastAPI shim that fronted the first design was killed. The Sharp/libvips composition path was abandoned for a hybrid WASM stack that runs inside the isolate. Recraft began as a composed first-party MCP and was later amended to a direct REST call, with the transport seam kept as a reusable adapter. One record is a correction: a request timed out at 30s during integration testing and was first blamed on an upstream API, until the API's own docs turned up an async mode and the fault turned out to be ours.

The "Deploy to Cloudflare" button is the cleanest dead-end (currently). We ran the spike on 2026-06-12. The button's monorepo mode extracts a single package into a standalone repo, which severs the @limner/core workspace dependency and breaks the build. Provisioning and secrets worked; the repo shape did not. The full note, and the script that does the same job plus migrations and a smoke test, is under Where is the Deploy to Cloudflare button?.

Architecture

Stack

• TypeScript pnpm monorepo: @limner/core (pipelines, composition, state), @limner/mcp (the server, all three transports), @limner/cma-tools (the same tool contract packaged for CMA custom-tool consumption)
• Cloudflare Workers, D1, KV, R2, Durable Objects, Images
• Composition: Photon and jSquash (WASM), Satori + resvg for typography, Cloudflare Images for the network-side ops
• MCP over Streamable HTTP and stdio

The architecture document with decision records lives at docs/Limner_Cloudflare_CMA_Architecture.md.

Tool Surface

All tools are namespaced limner_*. Full schemas in packages/limner-mcp/README.md.

Memory

Most image tools start every session from zero. Limner records what a project is and what you decided, then reads it back on the next run. Two stores back this, both in D1 (or local SQLite for the stdio and .mcpb flavors):

• Categorized memory. limner_record writes a fact under a category with an idempotent upsert, so re-recording the same key updates in place instead of piling up duplicates. limner_recall reads a category back, limner_forget removes an entry, and limner_list_categories enumerates what exists. Use it for durable preferences: a house palette, a default aspect ratio, a model that works for a given look.
• Project context. limner_create_project opens a project, limner_record_project_note appends running notes (briefs, style decisions, progress), limner_get_project_context returns the brief and notes for a project, and limner_list_projects lists them. This is the "what were we doing last week" layer.

Nothing here is a vector database or an embedding model. It is plain structured state with explicit keys, which is the point: the agent recalls what it actually recorded, not the nearest fuzzy match.

Managed Agent Setup

Limner runs as a Claude Managed Agent: Anthropic's model does the reasoning (the brain), Cloudflare's Worker does the executing (the hands), and the two meet at the OAuth-gated MCP surface described above. The agent definition itself is narrow by design.

• What's on the agent. Model claude-sonnet-4-6, an A4-framed system prompt (the framing is code-enforced: assertA4() refuses to build the agent plan if the verbatim disclaimer is missing), and 16 Agent Skills uploaded through the Skills API. That's it.
• What's deliberately not on the agent. Tools and MCP servers never appear in the agent definition. They bind to whichever consumer Worker you deploy, not to the agent's identity, so one agent definition works against any Worker you point it at.

Stand up your own agent: