Why bizs.dev needs a harness
bizs.dev is the public interface to serious agent infrastructure. Once a product exposes autonomous loops (tools, memory, retrieval, multi-step plans), ad-hoc prompts and invisible RAG stop being enough—you need governed compute and traces you can read.
itsApp runs several agents per user. At on the order of 10,000 users you already have a large number of agents in flight; growth only multiplies that. Harness engineering belongs in the design from the start: at that scale you cannot run or debug the system from scattered logs and hand-edited prompts alone.
A harness is that layer: it turns product intent into structured runtime behavior. It decides how prompts are represented, how tools and retrieval plug in, how context grows across steps, and how the system reflects without losing the plot. Without it, every team reinvents brittle glue and debugging stays archaeology.
The Ghost Engineer approach is our name for that harness on GitS: the same runtime ideas as the open-source design spine, expressed as engineering discipline rather than one-off scripts.
What the Ghost engine solution is
The Ghost engine solution is a harness: structured runtime behavior that turns intent into inspectable LLM call chains. Prompts, tools, context, reflection, and policy are first-class data the runtime can decode, budget, and log—not opaque strings you edit by hand and hope match production.
These five are the harness design we ship on the Ghost engine: concrete choices, not generic LLM advice. They match the talk above; ground each one in your deployment when you present.
Prompt decoupling and a unified data model
Structured intent in the model; composed prompts at runtime—never one frozen mega-string.
- Unified data model. Prompts live as schemas and records the runtime reads, not opaque blobs.
- Decoupled presentation. Messages and roles materialize from that model on each step.
- Data-driven structure. The loop expands from data; the full run is not pre-baked as a single paste.
Context retrieval as a tool call
Retrieval is explicit in the harness—not a silent preprocessor in front of the model.
Context retrieval is a tool call the agent can invoke or skip, like any other capability. Strategy—when to look things up, what to trust, when to stop—stays with the model and harness policy, not with a separate pipeline that always injects chunks before the agent thinks.
Context on the call chain, under constraints
Context accrues stepwise on the chain; constraints keep cost, risk, and policy visible.
Each LLM hop adds evidence on the call chain. Growth is bounded by explicit constraints: action points, tool-call budgets, and caps—so behavior stays legible, not an unbounded sprawl.
Reflection: Ghost Whisper, tasks, memory
Reflection is first-class: Whisper, tasks, and memory—not an afterthought in the prompt.
The scene uses Ghost Whisper with structured tasks and memory consolidation. The system can re-read state, reprioritize, and merge durable memory without stuffing the main prompt every turn.
Logged LLM call chains
The full chain is a first-class artifact: logged end to end for tuning, triage, and proof.
Every hop in the LLM call chain is recorded: meta harness tuning from traces, inspection when something breaks, and reporting for anyone who needs evidence—not a vibe check.
Where this leads
Because we collect harness data with a JSON core (call chains, config, outcomes in a canonical shape), the whole story is machine-readable. That is the prerequisite for argumentative meta harness improvement: an outer loop where an LLM reads traces and proposals, argues about what failed and why, and iteratively improves the harness that steers the inner LLMs (prompts, routing, policy), not just one-off edits by hand.
The next post on this blog will go there: meta harness improvement as a deliberate practice, grounded in JSON-native telemetry. For now, this page stays a scaffold for your talk: tighten each block with concrete bizs.dev and Ghost engine examples as you record or present.