Build an Autonomous Research Orchestrator

Suppose you need to follow a sample for three days, a fermentation for two weeks, a machine through hundreds of cycles, or a vineyard through a growing season. The difficult part is rarely taking one measurement. It is taking the same measurement reliably, preserving its context, noticing an unexpected change, and deciding what should happen next.

This tutorial builds that system with Nora.

By the end, your observer will be able to:

• run a declared experiment on a schedule without keeping an LLM online;
• collect measurements, images, audio, model outputs, and task outcomes;
• examine its own journals for shifts, gaps, saturation, disagreements, and relationships that were not named in advance;
• present a finding with the measurements that support it;
• ask a person one resolvable question through chat or Telegram;
• turn a confirmed reply into structured scientific context; and
• learn a new sensor or analysis method through validation and repeated tests.

The executor and research engine run on a small RISC-V board, a laptop, or a cloud VM. Start with your own files: physical instruments, Telegram, Supabase, and Goidanich are optional. Application chapters add domain-specific meaning and communication after the general research loop is working.

Begin with a Research Situation

Choose one of these as a mental model. You can change applications later.

The tutorials use all five examples, but every chapter produces a reusable piece of one system.

The Finished Experience

A successful deployment is quiet most of the time.

08:00  The observer completes its scheduled measurements.
08:02  New rows and artifacts enter the local notebook.
08:03  The research engine compares them with the subject's own history.
08:04  Ordinary variation is stored without a notification.
14:20  A persistent change appears in one channel.
14:21  Related channels and recent operations are checked locally.
14:22  The remaining uncertainty would change the next experiment.
14:23  One evidence-linked question reaches the operator.
14:41  The operator answers in ordinary language and confirms the structured record.
14:42  The next bounded experiment is queued.

This is proactive computing in a scientific setting. The software does not need a person to remember the right question at the right time. It also does not decide that a correlation is causal or that a proposed operation occurred.

Try the Local Research Loop

The engine uses standard-library Python, so this demonstration needs no board and no account.

git clone https://github.com/vbaulin/nora.git
cd nora
mkdir -p /tmp/nora-demo/monitors

python3 - <<'PY'
import datetime as dt
import json
import random

random.seed(1)
now = dt.datetime.now(dt.timezone.utc)
rows = [
    {
        "timestamp": (now - dt.timedelta(minutes=(48 - i) * 30)).isoformat(),
        "lux": min(100.0, round(random.gauss(86, 15), 1)),
        "temp_c": round(21 + random.gauss(0, 0.4), 2),
    }
    for i in range(48)
]
open("/tmp/nora-demo/monitors/light_probe.jsonl", "w").write(
    "\n".join(json.dumps(row) for row in rows)
)
PY

printf '%s' '{"mode":"cycle","state_dir":"/tmp/nora-demo/state","journal_dirs":"/tmp/nora-demo/monitors","pack_dirs":[]}' \
  | ./skills/research_agent/run.sh

The light values repeatedly reach 100. The engine identifies a possible measurement ceiling:

{
  "status": "success",
  "raised": ["lux piles up against 100 instead of passing it"],
  "investigated": [{
    "subject": "light_probe",
    "analysis": "ceiling_saturation",
    "sample_size": 48,
    "verdict": "material_unresolved"
  }]
}

Nobody supplied a rule about lux. Nora inspected the timestamped numeric channels and selected an analysis that matched the observed shape. The temperature values did not support a finding, so the engine said nothing about them.

Read the saved studies with mode=findings. Keep the loop running with the unattended research service. Each cycle studies a bounded part of the queue, including an untested discovery. Computation-only follow-ups happen locally; a person is involved when an observation, interpretation, or changed physical procedure needs them.

The generic engine returns structured findings. A human-facing application adds its own explanation and delivery rules; the vineyard chapter demonstrates that layer through Telegram.

Why a Small Local Observer Changes the Cost of Research

Many studies fail to collect dense longitudinal evidence because expert time, instrument integration, network access, or cloud processing is limited. A small local runtime changes the division of labor:

• instruments perform the repeated observation close to the source;
• compact journals preserve months of measurements without one LLM call per sample;
• local analyses remove routine false alarms before they consume attention;
• confirmed human observations enter the same timeline as sensor and model results; and
• reusable skills reduce the cost of connecting the next instrument.

This does not make a low-cost board equivalent to a laboratory instrument. It makes the board a persistent assistant around the instrument: one that can follow a method, retain context, and prepare the next decision.

What You Will Build

flowchart LR
    Q["Question"] --> T["Repeatable experiment"]
    T --> I["Instrument or dataset"]
    I --> N["Local evidence notebook"]
    N --> R["Automatic investigation"]
    R --> F{"Finding changes a decision?"}
    F -->|no| N
    F -->|yes| H["Human question"]
    H --> D["Confirmed decision or observation"]
    D --> T

Nora uses four cooperating parts:

Learning Path

The chapter titles follow what you will accomplish, not the repository layout.

1. Give the AI a laboratory, not a shell: connect open-ended reasoning to stable physical execution.
2. Turn a question into a repeatable experiment: describe steps, expected results, retries, and local monitoring.
3. Teach Nora a new instrument: package, test, and reuse a sensor or analysis capability.
4. Keep the scientific notebook trustworthy: preserve source, freshness, uncertainty, and failed experiments.
5. Let evidence start the conversation: ask one question with enough context for an ordinary-language reply.
6. Use idle time for discovery: find patterns automatically, test them locally, and remember refuted leads.
7. Run your first observer: start on a laptop, move to a board, and inspect the resulting artifacts.
8. Build an application for your domain: add your own subjects and questions; use Vineyard Guard as a complete field example.

What the System Can Learn

Several different processes produce durable change. The distinction matters when you interpret the result.

None of these turns temporal order into causality. A controlled experiment, independent measurement, or appropriate statistical design is still required for a causal claim.

Where Nora Runs

The static Go executor builds for riscv64, amd64, and arm64. Skills that need hardware identify that requirement and remain inactive on a host without the device. The off-board deployment guide covers systemd, containers, and cloud VMs.

Continue

Start with Chapter 1: Give the AI a laboratory, not a shell.

For a compact version of the entire course, use the single-page tutorial.

Method note

The chapter map uses the relationship-first approach of PocketFlow Tutorial Codebase Knowledge. The commands and runtime claims are checked against the current repository.