For a while I described Prism in its most ambitious form: a workspace for search, branching, comparison, and adjudication across multiple AI-generated paths. I still think that direction matters. In the long run, coding systems will need stronger ways to compare strategies, weigh evidence, and decide between competing answers.
But that is not where the first version should begin.
Prism's long-term ambition can stay the same while its first product move gets smaller and sharper. The right wedge is not a full adjudication workspace. The right wedge is a spec layer for AI coding agents.
More plainly: Prism should start as the task contract layer.
The problem is not just generation
Most AI coding tools are already good enough at producing plausible code. Their failure mode is usually not "the model cannot write anything useful." The failure mode is that the system cannot keep a task legible over time.
The common problems are familiar:
- the agent drifts away from the original goal
- important constraints disappear midway through execution
- acceptance is implicit rather than explicit
- a pile of changes appears, but nobody can say whether the task is actually done
- after twenty or thirty minutes, the task has no stable status
This is why so many experiences still feel chat-first even when they are technically agentic. The conversation continues, but the task itself never becomes a first-class object.
The wedge is a task contract
The most useful line I have for Prism right now is this:
Prism does not start from chat history. It starts from a task contract.
That contract is the core product object. It should not be a static brief that gets written once and forgotten. It should be the thing the rest of the system orbits around: plan, execution, verification, completion, and any later rework.
That is why I increasingly think the right center of gravity is not a "Spec Card" in the lightweight sense, but a live task contract.
At minimum, that contract needs to hold:
- Task
- Goal
- Constraints
- Non-goals
- Acceptance criteria
- Risks
- Execution state
- Open questions
- Verification checklist
- Outcome note
If I had to reduce it even further, the most important fields would be constraints, acceptance criteria, and execution state. Those are the things that stop agents from free-associating their way out of the original task.
Why this is a better V1
There are three reasons I think this is the right reduction.
First, it matches a much more frequent pain point. Branching and path comparison are valuable, but they are not required on every task. Spec discipline and execution state are required on almost every meaningful coding task.
Second, the value is easier for users to feel immediately. Most people will not say, "I need a multi-path adjudication workspace." They will say:
- the agent ran off track
- I lost the constraints
- I do not know whether this is actually done
- I cannot tell what state the task is in
Third, it is easier to build an MVP that actually behaves like a product rather than a demo. A task contract sits at the intersection of intake, planning, execution, and verification. It is not just a document. It is a workflow anchor.
The risk after the reduction
There is also a trap here.
Once Prism moves down from a broad adjudication vision to a spec-governed workspace, the main risk is no longer that it becomes too heavy. The main risk is that it becomes too thin. It could easily collapse into a nicer-looking form builder for prompts.
That would be a failure.
For Prism to stay meaningful, the contract cannot be a static text artifact sitting beside an agent. It needs to be:
- auto-generated first, not hand-authored first
- live, not static
- execution-bound, not advisory
- verification-bound, not cosmetic
The system should infer an initial contract from natural language, repo state, issues, and logs. A human should be able to correct it quickly. Then the agent's plan, progress, verification, and outcome should keep mapping back to that contract.
Without those bindings, the interface may look more structured than chat, but the behavior will still be chat-first underneath.
A better way to describe the layers
The simplest way I know to think about Prism now is as three layers.
Core layer
- Task object
- Live task contract
- Execution state
- Verification checklist
This is the minimum that creates first-order value.
Advanced layer
- Branching
- Strategy divergence
- Evidence view
- Rubric and decision mode
This is where the original Prism vision starts to reappear, but now on top of a stable task substrate.
Learning layer
- Outcome notes
- Reopen and rework tracking
- Aggregate learning about which specs, agents, and strategies succeed
This is the layer where the workspace becomes better over time, not just within one run.
The important point is that branching is not being rejected. It is being demoted from "the thing the product must be on day one" to "a higher-order mode that becomes much more useful once task contracts exist."
What I would build first
If I had to limit V1 to six things, the list would be:
- natural language task intake
- automatic generation of a first task contract
- fast human edit and approval of that contract
- agent execution that stays explicitly bound to the contract
- progress and changes that map back to the contract
- completion through a contract-derived verification checklist
That is already enough to feel like a real product category.
It would also make a stronger claim than "Prism helps compare multiple answers." The sharper claim is:
Prism gives AI coding tasks something they currently lack: a legible task contract that persists through execution.
That feels more fundamental. And more importantly, it feels like the kind of thing a first version can actually get right.