The model brief
A professional model should carry the work, not only answer the prompt.
PRO v2 is being designed for assignments that unfold over time: a product with existing decisions, a repository with dependencies, a 3D scene with a real hierarchy or a connected application where every action has consequences.
01 · Why PRO v2
The difficult part of professional work often begins after the first answer.
The current SpectraMind AI Pro v1 is our strongest available model for demanding reasoning. It can analyse a difficult question, produce advanced code and work through complex material in depth. For many requests, that is exactly what a professional user needs.
But a technically convincing answer is not the same as a finished result. A change can be logically correct and still target the wrong file. A generated script can look complete while breaking an existing convention. A Blender automation can run successfully and still damage the scene hierarchy. The work becomes reliable only when the model understands the environment around the answer.
PRO v2 moves the product direction from answering a hard request to maintaining a dependable workflow. The intended model first identifies the relevant system, forms a scoped plan, uses an appropriate connected capability and stays with the task until there is evidence that the result works.
This is not an excuse to make every interaction slower or more complicated. Professional judgement also means recognising when a request is simple. Short questions should remain direct. Planning, tools and verification should appear only when they materially improve the result.
02 · How it should work
One objective, carried through a complete execution loop.
PRO v2 is being shaped around a persistent task state rather than a sequence of disconnected replies. The model should know what the user asked for, what it discovered, which decisions were made, what changed and what remains uncertain.
Understand the environment
Inspect the relevant files, dependencies, application state, project conventions and constraints before proposing changes.
Form a scoped plan
Separate assumptions from confirmed facts, identify risk points and make the intended outcome explicit.
Act through the right capability
Use code, research or a supported application only when it is needed, with access limited to the active task.
Verify the real result
Read build output, run tests, inspect a preview or compare scene state instead of treating generation as completion. A dedicated review pass can also check visual hierarchy, consistency and responsiveness before the work is called finished.
Leave a clear handoff
Explain what changed, what was validated, what remains open and how another person can continue the work.
The model should be able to recover when a check fails. A failed build is not the end of the workflow and should not be hidden behind a confident summary. It becomes new evidence: the plan is updated, the failure is traced and the next safe action is selected.
03 · Evaluation plan
We will measure completed work, not only impressive responses.
PRO v2 has not been released and we are not publishing benchmark claims for it today. Before presenting performance results, we want evaluations that resemble the work the product is meant to handle. Those evaluations need to test the complete path from initial request to verified outcome.
Does the model find the correct implementation path, preserve conventions and avoid unrelated regressions?
Can it maintain requirements, decisions and unresolved questions across a longer sequence of work?
Does it select the right capability, request confirmation at the right moment and avoid unnecessary actions?
When a test or action fails, can the model diagnose the evidence and continue without restarting blindly?
Can it change a scene while respecting hierarchy, scale, naming and non-destructive production practices?
Does the workflow produce a stronger result without using excessive context, unnecessary tool calls or repeated work?
When the evaluation suite and model behaviour are stable enough to be meaningful, we intend to publish results together with methodology, limitations and the configurations used. Until then, the capabilities on this page remain product direction rather than measured release claims.
04 · Safety and control
More agency requires clearer boundaries.
A model that can work with repositories and professional applications needs stronger product controls than a model that only returns text. PRO v2 is being designed around scoped access, visible intent and review gates for sensitive or irreversible actions.
The objective is not to interrupt normal work with constant confirmation prompts. Low-risk, reversible activity should remain fluid. Confirmation should appear where the consequence justifies it: sending information externally, changing protected resources, executing a destructive operation or extending access beyond the active task.
Connected work should begin with the smallest useful set of files, data and application permissions.
The model should describe material changes and separate a proposal from an executed action.
Sensitive steps remain behind explicit approval instead of being hidden inside an automated chain.
Outputs, failures and checks should be visible enough for a user to understand what actually happened.
These controls are still part of the development work. Their exact behaviour may vary by application, plan and risk level as the preview evolves.
Read more about how SpectraMind handles memory, projects and personal data in Security and privacy and the Privacy Policy.
05 · Spectra Team & agents
Some work is better split across coordinated agents than carried by a single pass.
SpectraMind already runs Spectra Team, a multi-agent mode where a coordinator breaks a larger request into smaller assignments and hands them to a small number of worker agents. PRO v2's execution loop is designed to extend that same idea to heavier professional workflows.
Each worker agent is scoped to a defined piece of the task, works against the same shared plan, and reports back progress the user can follow instead of a single opaque block of output. The coordinator is responsible for merging the results, checking that the pieces are consistent with each other and resolving conflicts before the work is presented as done.
Each agent owns a clear slice of the task instead of overlapping freely with the others.
Contributions and status are surfaced per agent as the run proceeds, not only at the end.
Results are reconciled and checked for consistency before being handed back as a single outcome.
The user can review, redirect or stop a run; agents do not keep working outside the scope they were given.
We do not publish the internal prompts, routing logic or upstream providers behind Spectra Team. What is public is the workflow shape above and the result the user sees.
06 · Depth and scale
The gap between PRO v1 and PRO v2 is not one more clever answer. It is what happens after the answer.
PRO v1 is already our strongest model for hard reasoning: dense technical explanations, difficult debugging, advanced code on request. PRO v2's target is different in kind, not just in degree. Instead of measuring success at the first reply, the loop is designed to keep going — through the second file that breaks, the test that fails for a reason nobody explained yet, the follow-up decision that only makes sense once the first change is already in place.
That requires the model to hold more than a single exchange in view at once: the original objective, the constraints discovered along the way, the parts of the system already touched, and the parts still untouched. PRO v2 is being built around keeping that state coherent across a long-running task instead of quietly losing it two or three steps in, which is where most "capable" models start to drift.
A task-scoped plan and decision log meant to survive many turns, tool calls and file edits without the user having to re-explain context.
Short questions stay short. When a problem has real edge cases, the model is meant to expand its reasoning to match, not pad every answer equally.
Changes are planned against the actual shape of a codebase or document set, not against a single file in isolation.
A failed test or a rejected action becomes evidence that updates the plan, instead of being smoothed over in the next response.
What this looks like in practice
A refactor that touches a dozen files
Trace every call site of a changed function across a repository, update them consistently with the project's existing conventions, and run the test suite before calling the work done — instead of editing one file and hoping the rest still holds together.
A build that fails for an unclear reason
Read the actual failure output, form a hypothesis, make the smallest change that tests it, and revise the hypothesis when the evidence disagrees — rather than guessing once and presenting the guess as a fix.
A task that spans more than one tool
Pull the current state from a connected application, propose a scoped change, wait for confirmation on anything sensitive, then apply and verify it — treating the tool as part of one continuous task, not a detour from it.
A scene with real structure
Respect existing hierarchy, naming and scale in a Blender project before generating a lighting or automation pass, and render a preview to check the result instead of assuming the script did what it was supposed to.
These are the kinds of tasks the model direction targets, described to make the goal concrete — not a demonstration of benchmarked performance. See Evaluation plan for how we intend to measure this once it is ready to report.
SpectraMind AI Pro v1