Project Phoenix

Offline Grounded Domain Agent

The useful unit is not the naked local model. It is the harnessed domain system.

A local model becomes operationally useful when it is paired with a deterministic domain substrate, a grounding layer, explicit provenance, and a controlled escalation path. That combination is what this pattern defines.

4 Answer modes
6 Harness layers
1 Stable entrypoint
3 Reference domains

The Wrong Question

The common question in local-model discussions is too vague:

can a local model do useful work?

That hides the actual issue. What matters is not whether a naked model can answer plausibly from its own weights. What matters is whether a local system can remain useful when cloud support is absent or degraded.

The better question is:

what makes a local domain-answering system operationally useful offline?

The answer is a harness — a deterministic substrate underneath the model, with explicit provenance on every answer and a defined escalation path when raw model output is not enough.

Three Different Things People Call "Local LLM"

Raw

Model alone

The model sees only the user request. No verified context. This is the weakest serious local mode — plausible but not reliably correct on domain questions.

Grounded

Model + verified context

The model sees the question plus verified local evidence or a stable answer seed. Materially stronger. This is the default user-facing offline mode.

Implementation-Agent

Model inside a workflow

The model operates inside a deterministic workflow with tools, validation, artifact logging, and explicit trust boundaries. The strongest mode for capability claims.

The Core Claim

The biggest difference between local agent systems is often not raw model quality, but the quality of the runtime harness around the model.

raw local model → weak grounded local system → materially better implementation-agent → strongest

This is also why a very capable model inside a weak harness can feel unreliable, while a comparable model inside a strong harness can feel like a real working system. The harness determines what the model's capability actually produces in practice.

The right product framing is therefore not "offline chatbot." It is an offline grounded domain agent.

What an Offline Grounded Domain Agent Is

An offline grounded domain agent is a domain-specific local system with:

This means the product is not "a local LLM." It is a local domain-answering system with clearly separated rigor modes.

Why Great Models Can Feel Weak

Project-scale agent quality is determined less by raw model intelligence than by runtime engineering. Four gaps account for most of the difference:

Reliable Tool Loops

Plan, call tool, verify result, update state, continue. Silent failure destroys trust faster than any raw model weakness.

Persistent Working Memory

Plans, prior edits, tool outputs, process logs, and saved artifacts matter more than chat history alone.

Real Tool Awareness

A serious agent needs actual contact with files and tools — not a text simulation of a project.

Error Visibility

If the model is not forced to react to failure, it can narrate progress it did not actually earn.

Reference Implementation

TourAgent is the current reference domain. It demonstrates all six layers of the pattern in one implementation:

Three domains now expose the pattern through a shared multi-domain shell: touragent, iso13485, and globaltemperature.

TourAgent is the reference implementation, not the canonical home of the pattern. The architecture is domain-agnostic — any domain with deterministic local logic and a meaningful question surface is a candidate.