Discover more

Zorp turns an uncertain question into a defensible answer using evidence: question, investigation, sources, evidence, conflicting evidence, reasoning, validation, answer or artifact. This page is the long tour of the project itself, taken from its README, its docs and its decision log.

Zorp is pre-alpha. Everything below marked as built is built and tested in the repository; anything that is not says so.

What Zorp is

A research agent for scientific discovery, where research is not restricted to academia. A technical decision (should we migrate off Kafka), a competitive teardown, an investment thesis, a due-diligence package, a market question and an academic hypothesis are the same shape of problem to Zorp.

A confident answer is not a defensible one. An LLM will produce a fluent answer to a hard question in seconds. What it will not do is tell you whether to believe it, what evidence it weighed, or what it found that pointed the other way. Zorp treats that gap as the actual problem: a question becomes an investigation, the investigation produces an evidence record, and the record is what the answer is accountable to.

It is a Rust workspace, MIT licensed, built by Aviskaar. Its execution layer started as a fork of quecto, a minimal, vendor-neutral harness for LLM agents, and was extended deliberately with the primitives evidence-based investigation needs.

Three ways to run it

Any OpenAI-compatible endpoint works, including a local one such as Ollama, LM Studio or vLLM. With a local model, nothing leaves the machine.

zorp-agent: The agent in the terminal. Line oriented on purpose: no full screen mode, so piping, scrollback, selection and screen readers keep working. A chat REPL with history, Tab completion and slash commands.
zorp-web: A browser chat on http://127.0.0.1:7777 with the artifact beside the conversation: streamed answers, a Files pane, voice input, projects, branching and a model picker. It works in a workspace you choose and in no directory at all until you have.
Zorp.app: The native Mac app, a universal .dmg written in Swift. It runs the same server in process through a Rust bridge.

curl -fsSL https://raw.githubusercontent.com/aviskaar/zorp/main/install.sh | bash

export ZORP_BASE_URL="http://localhost:11434/v1"   # or any OpenAI-compatible endpoint
export ZORP_MODEL="qwen2.5:7b"

zorp-agent "<task>"                      # the agent, in the terminal
zorp-web --workspace ~/research          # the chat UI on http://127.0.0.1:7777

Tracks and the Kill Threshold

A track is the unit of investigation: one question, one evidence record, one history. It holds the registration (hypothesis, metric, Kill Threshold), every attempt rather than only the one that worked, and the checkpoints where a person decides whether the investigation continues.

The Kill Threshold is a number a human supplies that says, in advance, what would prove the investigation wrong. It is written to a file, hashed and committed to git before any evidence is gathered, so a run cannot quietly rewrite what it set out to test. The agent never proposes it, and only a human can move it. When a run crosses the line, the record says why it was killed. Track data lives in DuckDB.

Four capabilities, and what is deliberately not one

The research work is four bounded layers on top of the track foundation, all built and tested, behind the research feature of zorp-agent.

validate: Is this question worth investigating? A novelty and feasibility check that must search for existing evidence first. Without a search-capable tool it fails fast rather than scoring a question against nothing, and a tool that only searches your own notes does not count.
investigate: Gather evidence through staged, pre-registered attempts. Every attempt is recorded along with the conditions it ran under, written before it runs, because a condition recorded afterwards describes a different run.
co-write: Draft the artifact from what the track recorded. A human is always the author of record.
deliver: Match a finished draft against real venues, conferences and journals via live search, and write a ranked shortlist for a person to review.
critique (a gate): Audits the draft against the evidence record and revises what the record does not support, within a bound. The audit is code; the model only inventories claims. It refuses if the record moved under it, so it cannot touch the Kill Threshold.
panel (a reader): Adversarial review: several reviewers read one target through code-defined lenses, none sees the others, and agreement is counted in code. Reviewers get a read-only tool set, and a panel is launched by a person, never by a model.

Research capabilities →

aryabhatta, the discovery layer

A record of what every investigation attempt expected and what actually happened, plus readers that look for structure in it: conditions, expectations, calibration, detectors, partition, rerun, anomalies, families and inquiry. It is a record and readers, not a fifth capability, and it ships no command on purpose.

Only investigate writes to it. With forecasting switched on, the agent states a forecast before each attempt, and the expectations module refuses a forecast once its outcome exists, which is the one guarantee that separates a prediction from a postdiction. Calibration then compares stated confidence with what happened, band by band, and is a go or no-go a person reads before anything is built on the ledger.

Two rules hold it up. Detection is code and the model only interprets. And no detector may read a column holding model-authored text, or what the agent speculated today becomes an observation tomorrow.

Inside the workspace

Zorp-specific capabilities live in their own crates or clearly named modules, separate from the inherited harness code, so each can be tested and reasoned about on its own.

zorp: The core crate: model transport and raw primitives. One HTTP agent for all model traffic, with a connect timeout, an idle read timeout, and one bounded retry policy for 429, 502 and 503.
zorp-agent: The agent: tools, reasoning, verification, sessions, MCP, telemetry, and the research capabilities.
zorp-web and web/: The browser chat server and its TypeScript UI. Model output is rendered by building DOM nodes, never by assembling HTML strings.
zorp-desktop: Zorp.app, kept outside the Cargo workspace so desktop dependencies never slow down Linux CI.
zorp-track: The research foundation: tracks, evidence records, git-backed pre-registration, checkpoints, and aryabhatta.
zorp-mcp: MCP client and server integration, with trust on first use.
zorp-search: Web search over Tavily or a self-hosted SearXNG. Off by default, and the only built-in tool that sends anything over the network.
zorp-skill: Discovery and parsing of Claude Code compatible skills. A skill body is untrusted input: it can grant no tool and loosen no approval.
zorp-recall and zorp-voice: Local conversation search and local voice transcription, both behind a loopback guard shared through zorp-loopback.
zorp-train: Developer mode: tokenizer training, model recipes, pretraining on Apple Metal through MLX, and a registry that serves a checkpoint back into the model picker.
zorp-eval and zorp-stub: Evaluation. A scripted provider on loopback that gates every pull request, a compatibility suite against live providers, and benchmark runs on public datasets.
erbga: A standalone genetic algorithm for graph community detection, validated against published benchmarks and used as the large-graph backend of the search layer.

Local first, in practice

Owning your intelligence is enforced in code rather than promised in copy.

Recall and memory: Search your own conversations, and quote earlier ones into a new turn, with embeddings from a local Ollama. Conversation text goes to a loopback address or nowhere: no remote provider, no flag that adds one, redirects and proxies off, and tests that count connections to prove it.
Voice: Transcription runs on a local Qwen3-ASR server bound to loopback. There is no cloud fallback, and a transcript is editable text that is never sent on its own.
Your settings, your key: One settings file shared by both surfaces, with no field for the API key, so there is nothing to leak a secret through. zorp-agent doctor reports a key as set or not set, never its value.
Your state: One list of everything Zorp keeps on the machine, read by both the terminal and the browser, so clearing it means the same thing everywhere. Nothing in it touches a workspace file.

The rules it will not break

Most of the design is a handful of rules applied everywhere, each with a test that fails if it stops holding.

A person launches, a model does not: No tool starts a panel, an investigate run, an ensemble, a training run or a compaction. The agent has tests that list its tools and say so.
Detection is code: Wherever something is judged, code decides and the model interprets. A model asked whether it likes its own draft will like its own draft.
Model text is never evidence: Titles, summaries and findings a model wrote are kept out of the columns that recall, memory and the detectors read.
Failure is loud: A timeout names itself, a stream that ends early is an error rather than a short answer, and every retry says so on stderr. A measurement that did not happen is never scored as a zero.

Where it is going

Zorp RL is the training side: pretrain, fine-tune, use the model in Zorp, observe, and feed the logs back so models retrain on how they are actually used. Pretraining and serving a checkpoint work today in developer mode; fine-tuning, the feedback loop and automated training are planned.

Also not done yet: a published investigation trace from start to finish, a grounded-versus-baseline evaluation, and a systems paper about Zorp itself.

Go deeper

The repository is the source of truth, and its decision log records why things are the way they are, one decision per file.