Multi-step AI work becomes confusing when the interface shows only a spinner and a final paragraph. A task manager gives the user a timeline: what Nerva understood, what it is doing now, which step needs approval, and what remains unverified.

Nerva is an upcoming local-first agent, so the task manager should work even when a task uses a local model and never touches the network. It should also make provider failures and permission denials ordinary states rather than mysterious errors.

A task is more than a prompt

The task manager can represent a request as small checkpoints:

1. Understand request       complete
2. Select repository files   complete
3. Explain likely cause      complete
4. Propose code change       waiting for review
5. Run focused test          not started
6. Verify final diff         not started

This structure prevents the agent from presenting a plan as if it were already executed. It also gives the user a natural place to stop, edit the scope, or deny a later step.

Checkpoints make failures recoverable

Suppose a test command fails because a package is missing. The task should remain paused at the failure instead of silently installing dependencies, changing the lockfile, or trying a different directory. The manager can show the error and propose a new step with a new permission request.

That is especially useful for backend work, where a seemingly harmless recovery can change a database, use a credential, or contact a remote service.

Resuming should not replay dangerous work

A resumed task should know which steps are complete and which approvals have expired. Nerva should not repeat a file write just because the user reopened the task. It should re-check the current diff and workspace state before continuing.

The task history should record the model route, selected context, approvals, tool results, and verification. That history becomes a debugging aid and a review trail for work on projects such as CryptoEx or SentinelFi.

The best task manager is not the one with the most status badges. It is the one that makes the next action, its scope, and its evidence obvious.

The useful design question

The useful question here is not whether an AI agent can produce an impressive demo. It is whether the workflow stays understandable when the task is incomplete, the repository is messy, or the model is wrong. For this part of Nerva, the focus is making a long task observable and resumable. That means each state should have a visible owner, a small input, and a result that another part of the system can inspect.

A concrete scenario

Consider a dependency-install failure that should pause instead of mutate a lockfile. A good Nerva run would first state the scope, identify the files or operation it needs, and show the next proposed step. It would keep the original request separate from model-generated instructions. If an action needs approval, the user would see what will happen before it happens. Afterward, the task history would retain the command, result, and verification status instead of reducing everything to a confident paragraph.

This approach also makes a failure useful. A denied permission, unavailable provider, missing package, or changed file is information about the task state. Nerva should preserve it and explain the smallest recovery option. It should not silently broaden the request, retry a side effect, or claim completion because a model supplied plausible-looking text.

What I would test first

For an early implementation, I would test three paths: a normal successful run, a denied action, and an interrupted run resumed after the workspace changes. The key test is whether a checkpoint still matches the current workspace. In each path, the interface should make clear what Nerva knows, what it proposed, what actually ran, and what remains unverified.

Useful acceptance checks include:

  • the user can inspect the selected context before model execution;
  • sensitive paths and credentials are excluded or redacted;
  • every side effect has a narrow permission decision;
  • failures remain attached to the step that caused them;
  • a final answer links to evidence instead of implying that unrun work succeeded.

Nerva is still an upcoming project, so these are design and implementation goals rather than claims that a finished product already provides them. That distinction matters: a trustworthy agent should earn confidence through observable behavior, not through a feature list.

A small review checklist

A practical review should end with a small decision, not a vague promise. Write down the scope, the expected result, the permission required, and the check that will confirm it. Then try the same flow with a refusal or missing dependency. If the interface explains that case clearly, the design is ready for a more realistic prototype; if it hides the problem, adding another feature will only make the workflow harder to trust.

The design is informed by the boundaries I have had to think through in CryptoEx and SentinelFi: backend work becomes easier to review when context, permissions, side effects, and verification are explicit.