The best model for an AI task is not always the biggest or newest one. It is the model that can complete the task within the user’s privacy policy, context budget, device capacity, cost, and reliability requirements. Nerva’s planned router should make that tradeoff visible.

Five questions before routing

Nerva can evaluate a task in this order:

  1. Privacy: must the context stay local?
  2. Capability: does the task require code reasoning, vision, audio, or a large context?
  3. Size: will the selected model fit the context without losing important details?
  4. Cost and quota: is an external request affordable and available?
  5. Fallback: what happens if the chosen route fails?

This avoids a common mistake: sending every request to a remote premium model even when a small local model is enough.

A simple routing table

Task Sensible first route Reason
Explain one local function Local model Small, private context
Review a large architecture Approved provider or capable local model More context and reasoning
Inspect a secret-bearing config Local-only or redact first Sensitive data
Run a test Model proposes; local tool executes Tool access is separate
Compare two model answers User-selected routes Explicit experiment

The router should recommend, not secretly decide that private data is safe to upload. If a provider is unavailable, Nerva should offer a new route for approval rather than silently switching.

For Nerva, model choice is part of the task record. A developer should be able to see whether a result came from a local GGUF model, a configured API, or a fallback after an explicit decision. That makes the system easier to understand and makes the word “local-first” meaningful in practice.

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 routing by privacy, capability, and response cost. 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 using a local model for repository summarisation and a stronger provider only after an explicit review. 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 what happens when the preferred model is unavailable. 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.