# Why Neo works differently

Many assistants answer questions. Neo is built to carry work: to hold context across sessions, act through tools, and keep you in control while it does. This page explains the differences that matter in practice, so you know what to lean on—and what to verify.

## Durable context

A chat-only assistant starts from zero each session. Neo can retain stable preferences, decisions, and project state in durable memory, so you do not re-explain your role, your standards, or the project's history every time. You control what is remembered; see [Memory and knowledge](/docs/tools/memory-and-knowledge).

## Tool-enabled execution

Neo does not only describe work—when the relevant tools are available it performs it: browsing sources, reading and writing workspace files, producing artifacts, running scheduled tasks. The output of a request can be a finished deliverable rather than instructions for producing one.

## Controlled autonomy

Autonomy is bounded, not open-ended. Neo works independently inside the scope you set, and pauses for approval at the points you define—before sending, publishing, deleting, or committing to anything hard to reverse. You choose where the checkpoints go; see [Effective requests](/docs/getting-started/effective-requests).

## Workspace continuity

Work products live in a workspace, not in a scrolling transcript. Files persist between conversations, artifacts can be revised rather than regenerated, and a project can accumulate structure over weeks instead of being reconstructed from chat history.

## Structured knowledge

Beyond raw memory, Neo can maintain organized knowledge: source summaries, entities, decisions, and analyses that stay useful after the conversation that produced them. That makes the tenth week of a project cheaper than the first, not more confusing.

## Long-running work

Some work cannot finish inside one exchange: monitoring, recurring reports, multi-day projects, delegated investigations. Neo supports work that outlives the conversation that started it, with defined hand-offs and completion criteria; see [Long-running work](/docs/workflows/long-running-work).

## Transparent action states

When Neo acts, the state of the action should be visible and honestly labeled: drafted is not sent, scheduled is not done, and a delegated task reports what was actually completed. The guide's [response patterns](/docs/reference/response-patterns) describe the language to expect, and [verification](/docs/trust-and-safety/verification) describes how to check it.

## What this does not mean

None of this removes your judgment. Availability of specific tools varies by surface and workspace—see [Capability availability](/docs/reference/capability-availability)—and every deliverable still deserves review before it leaves your hands. The difference is that you review finished work with visible provenance, instead of assembling it yourself.