How it works
From a request to a result you can inspect.
The workflow is deliberately understandable: connect what may be used, describe the outcome, shape the work, choose the intelligence, run bounded execution, and review the evidence.
01
Connect what Reforception may use.
Add the models, services, repositories, and machines you want available. A connection makes something visible to the workspace; it does not automatically grant every action.
Connections define availability. Capabilities and authority determine what can happen next.
02
Describe the outcome in ordinary language.
Start with what you want accomplished. Chat and Build are designed around intent first, so you do not need to translate every job into a developer workflow before Reforception can help.
The user request remains the center of the job.
03
Shape the work before execution.
Use Plan when the job needs structure. Break the outcome into projects, tasks, dependencies, milestones, or an agent-ready work packet you can inspect before it runs.
04
Choose the intelligence and the worker.
Select the model or eligible agent for the task. Reforception is designed to make that choice explicit rather than silently replacing it with another provider, worker, or billing path.
The same connection registry should feed every surface that needs the capability.
05
Let bounded execution do the work.
Build can give an eligible worker scoped authority inside an isolated workspace while you follow progress in the same conversation. Repository state, Stop, changes, and checks stay visible.
06
Review the evidence and decide what happens next.
A useful result is more than an AI saying it is done. Reforception is built to bring changes, checks, agent state, and remaining decisions back to you before publication or deployment.
The handoff matters
The model is not the workflow.
Reforception separates the intelligence answering a question from the authority that can change files, run checks, reach a machine, or publish a result. That separation is what makes it possible to use different models and workers without pretending they all have the same role.
The product is still in private beta, so some workflows remain under active development and acceptance. When a capability is unavailable or blocked, the product should say so rather than manufacture a successful state.