Research and implementation need different AI workspaces

An AI system can search sources, condense arguments, modify files and prepare a publication within minutes. Technically, this looks like one continuous workflow. Organisationally, however, it combines fundamentally different activities. Research works with uncertainty. Implementation creates a new state. Between them lies a decision that should not disappear merely because the conversation feels smooth.

The same context is not automatically the same workspace

During research, a system may form hypotheses, collect contradictions and follow incomplete leads. It needs access to material whose validity has not yet been settled. That openness makes strong research possible. Implementation operates under different conditions. Its goal, affected files, permitted tools and expected effect must be clear enough for the change to be inspected and, where necessary, reversed.

When both activities are joined in one undivided chat or agent run, provisional assumptions can easily migrate into operational steps. A sentence that appeared only as a possibility during research may become the basis for a file modification moments later. The problem is not insufficient intelligence. It is the absence of a visible state boundary.

The research workspace protects openness

A good research workspace may read broadly but should not act silently. It separates observation, source, interpretation and open question. It records which statement is supported, which merely appears plausible and where sources conflict. Its outcome is not an intervention but a reviewable brief.

That brief includes source status, relevant passages, uncertainties and alternatives. The negative list matters just as much: What was not examined? Which information is missing? Which source is outdated or merely supplemental? Research becomes dependable when it delivers its limits together with its findings.

The implementation workspace needs a contract

Implementation should begin only after open research has been converted into a bounded task contract. The contract describes the intended outcome, affected surface, protected areas, verification path and rollback. An agent does not need to understand the entire project to make a good change. It needs to understand the relevant part reliably and know when to stop.

The implementation workspace should therefore hold fewer sources and fewer permissions than the research workspace. It receives accepted foundations, not every lead that was discovered. It receives write access only to the required area. Dependencies, deployment, sending, deletion and cost-incurring actions remain separately gated.

The handoff is an artifact of its own

Between research and implementation, „continue" is not enough. A good handoff states the objective, accepted findings, rejected alternatives, assumptions, affected paths, acceptance criteria and unresolved decisions. It turns conversational context into a reviewable work state.

This prevents two common failures. First, the implementation agent does not have to reinterpret the entire source space. Second, it remains visible which selection a human or reviewer actually confirmed. The handoff is not administrative overhead. It is the point where meaning is translated into action boundaries.

Parallel work needs ownership rules

Several agents can research independently or work on separate modules. Without ownership and merge rules, however, speed and conflict increase together. Two instances may change the same file differently, work from diverging source states or overwrite one another without noticing.

For parallel implementation, separate branches or worktrees, assigned paths and explicit merge ownership are useful. For parallel research, each branch needs its own question and a shared result schema. A review combines the findings afterwards. Parallelism then becomes a controlled allocation of attention rather than uncontrolled multiplication.

Review is neither research nor implementation

Review also deserves a separate workspace. A reviewer should not merely repeat the same assumptions in more elegant language. It needs the brief, the proposed change, the acceptance criteria and the evidence. Its task is to identify divergence, missing tests, scope expansion and safety consequences.

This creates a simple separation: research expands the possible knowledge space. Implementation changes a bounded state. Review compares the change with criteria that were visible beforehand. The roles may be performed sequentially by the same model, but their artifacts and permissions must remain distinguishable.

Not every tool belongs in every workspace

Browser access is useful for research. Repository write access is often unnecessary there. An implementation agent needs files and tests, but not automatically email, calendar or production credentials. A publishing tool may prepare a final preview, yet it should send only after explicit approval.

The question is therefore not which model can do everything. It is which capability is required in this state, and what effect it may trigger. A dependable system distributes tools according to task, data zone and risk class, not according to technical availability.

The three-workspace model

# RESEARCH
Question · sources · findings · conflicts · uncertainty · open points
No external or irreversible effect.

# IMPLEMENTATION
Accepted task · bounded scope · permitted tools · tests · rollback
Only the approved change.

# REVIEW
Acceptance criteria · diff/artifact · test evidence · risks · decision
Approve, revise, hand off or stop.

Separating these workspaces does not slow good work. It prevents a rapid movement in thought from becoming a technical or organisational effect without anyone noticing. A capable AI system must do more than generate transitions. It must show which transition is happening, on what basis and with what authority.

All materials to download — the topic overview and the worksheet: