Prism: Make Your AI Editor Delegate

By Bryan Barton

Developer AI tooling is getting better, but a lot of workflows still have the same bad shape:

Ask the premium model to do everything.

Give it the task. Give it the repo rules. Give it the runbooks. Give it the skill docs. Give it the CI output. Give it the Kubernetes dump. Give it the prior chat. Then hope it can stay focused long enough to produce something useful.

That works until it does not.

The model becomes the planner, the researcher, the shell operator, the log reader, the docs scraper, the code reviewer, and the final writer. Every turn gets heavier. Every answer drags more context behind it.

Prism is an experiment in a different shape:

Keep the premium model as the orchestrator. Move the narrow work to local specialists.

The Problem Is Not Just Token Cost

Token cost is the easy thing to measure. Context quality is the thing developers actually feel.

When your main AI session is packed with every skill, instruction, and evidence blob, you are paying twice:

• money for tokens the premium model did not need


• attention for a conversation that gets harder to steer

Most agent frameworks try to solve this by becoming the new orchestrator. Prism does not.

Prism assumes your editor is already the control plane. Cursor, Claude Desktop, or any MCP host can remain where decisions happen. Prism sits underneath as a delegation layer.

The orchestrator asks for help. Prism runs a constrained local specialist. The specialist returns a compact summary. The orchestrator synthesizes the result.

No swarm. No replacement IDE. No giant hidden workflow engine.

Just smaller prompts in the place where smaller prompts matter.

What Prism Is

Prism is an MCP server and CLI for running repo-defined specialists on local Ollama.

Each specialist is plain text:

• an agent spec


• optional skills


• optional constitution


• task-specific evidence

Those specs live in your repo. They can be reviewed, changed, versioned, and benchmarked like any other engineering artifact.

Out of the box, Prism includes specialists for:

• GitHub PR and CI triage


• Kubernetes diagnostics


• Argo CD and Workflow debugging


• docs and release-note lookup


• focused Go helpers and package scaffolding


• simple frontend implementation tasks

The pattern is intentionally boring:

1. Keep the top-level brief short.


2. Delegate evidence-heavy subtasks.


3. Run specialists locally.


4. Feed the premium model compact summaries.


5. Let the editor-orchestrator make the final call.

A Concrete Example

I benchmarked a small but real coding request:

Build a minimal single-page todo app with HTML, CSS, and vanilla JavaScript. Users can add todos, mark them complete, delete them, persist todos in localStorage, and get a README with local run instructions.

Without Prism, the orchestrator gets the full task context directly.

With Prism, the orchestrator delegates focused pieces:

• UI structure


• localStorage + todo logic


• README instructions


• final synthesis from compact specialist summaries

The live run produced:

That is a 94.1% reduction in orchestrator input tokens for this task.

Both outputs passed the same quality rubric: required files, localStorage behavior, add/complete/delete flows, and README instructions.

The Honest Economics

This is not a claim that one todo app saves a company thousands of dollars.

It does not.

A single small coding prompt is cheap on modern API pricing. The interesting part is what happens when this pattern compounds across repetitive, context-heavy work.

Using the live todo benchmark as the unit workload, and assuming one prompt-heavy developer sends 20 coding prompts/day:

Model names above are benchmark pricing profiles from testdata/benchmarks/orchestrator-models.yaml (OpenAI/Anthropic list-rate assumptions), used to compare relative economics under one fixed workload.

Those are not life-changing numbers by themselves. They are proof that the direction is measurable.

The bigger win is architectural:

• the orchestrator sees less irrelevant material


• specialists stay scoped to the job


• workflows become repeatable


• teams can benchmark their own tasks instead of arguing from vibes

If your real workload includes long CI logs, cluster state, runbooks, incident chat history, and internal docs, the context avoided per task gets much larger than this todo benchmark.

Why MCP Makes This Practical

MCP gives AI editors a standard way to call external tools.

That matters because Prism does not need to be the application you live in. It can be a tool your current application calls.

In Cursor, the flow is:

1. Register Prism as an MCP server.


2. Ask the editor to delegate a focused subtask.


3. Prism runs the local specialist.


4. Cursor receives a compact result.

For exact Cursor setup, see the MCP config block in docs/usage.md ("Cursor configuration").

The premium model is still responsible for judgment. Prism just keeps it from doing clerical work that a local specialist can handle.

What Makes Prism Different

Prism is not trying to be:

• a replacement for Cursor


• a general-purpose autonomous agent framework


• a multi-agent research demo


• a black-box workflow runner

It is trying to be a small, inspectable delegation layer for engineering teams that already work in an AI editor.

The design bias is:

• local-first execution


• repo-native configuration


• explicit skills and constitutions


• MCP compatibility


• benchmarkable token and cost deltas

That last point matters. Prism includes benchmark fixtures so changes can be measured. The numbers in this post are generated from committed benchmark data, not hand-written marketing math.

Where This Fits

Prism is useful when the work has a repeatable specialist shape:

• “summarize this failing CI run”


• “inspect this rollout”


• “triage these Kubernetes pod events”


• “pull relevant docs for this SDK change”


• “implement this small helper function”


• “split this frontend task into UI, logic, and README”

It is less useful when the task is already tiny enough that delegation overhead is more expensive than just asking the model directly.

That is the point: Prism is not about delegating everything. It is about delegating the parts that are bloating the orchestrator.

Try It

git clone https://github.com/bryanbarton525/prism.git

cd prism

go install ./cmd/prism



# Ensure Ollama is running (or open the Ollama desktop app)

ollama serve

ollama pull llama3.1:8b

prism config doctor

prism agent list

Then wire it into your MCP host and call run_agent.

Start with one workflow. Measure it. Keep it if it helps.

That is the pitch for Prism:

Do not replace your AI editor. Make it lighter.