Learn · AI methods
The concept map showed what each AI idea does and does not establish. This page goes deeper on the three that matter most for a private, human-first workflow: running a model on your own machine, giving it tools, and coordinating those tools, and at every step, where the judgment stays with you.
After this guide you will be able to:
On this page
A local model is an AI model that runs on your own computer instead of a company's server, with no cloud call, no API key, and no account. Runners like Ollama and llama.cpp now put open models in the 7-to-8-billion-parameter class within reach of a modern laptop, and smaller task-specific models run on almost anything.
Install a runner, pull a model, and point it at one bounded question at a time: draft first-cycle codes, suggest which passage of a source bears on a claim, flag inconsistent terminology. The model answers a narrow local question; the record and the decision stay with you.
What it does not do: decide truth. A local model is still a language model, and fluent output is not supported output. Our own laptop test found the honest limits: can a local model check your citations?
An agent is a model given tools and a loop: it decides an action, takes it, observes the result, and decides the next one. With the right tools it can retrieve a source, run an analysis, and write out a table, pursuing a goal over several steps rather than answering a single prompt.
Real research work is multi-step, and the steps depend on each other. An agent can carry a chore across those steps (fetch, extract, compute, format) without you hand-copying between tools. That is genuinely useful for the mechanical parts of a workflow.
The safe way to use an agent in research is to decide, in advance, what it is allowed to do on its own. Sort every step into three kinds of node:
Deterministic, checkable work: parse a citation file, compute an effect estimate, render a plot, hash a protocol, compare two files.
Judgement-shaped work offered as a suggestion: classify a study design, flag a citation that may not support its claim, propose assumptions to check. Output is a proposal or a warning, not a verdict.
Consequential calls that block what comes after them: approve the research question, accept an inclusion decision, judge risk of bias, sign off on an interpretation. These wait for a qualified person.
What it does not have: authority. Being able to perform a step is not the same as being entitled to decide it, and only the second protects a research record. The agent proposes and does the mechanical work; a person disposes and signs.
Orchestration is coordinating several bounded tools and agents over a graph (a defined order of steps with their dependencies) instead of asking one large model to do everything at once. Think of it as a workflow diagram the system actually runs, not a single "do my research" prompt.
Under the hood this needs three things working together, covered next: a place to keep the graph (memory), a way to retrieve from your own material (RAG), and a way to retrieve along relationships (GraphRAG). The orchestration layer walks that structure and routes what it finds to the right node type: automatic for executable steps, a flag for assessments, a gate for human decisions.
What it does not guarantee: that the workflow is scientifically appropriate. A perfectly coordinated graph can still be built around the wrong question. Orchestration keeps the work orderly and its consequences traceable; it does not make the design sound.
These three are the machinery that makes local orchestration worth having, each closing a gap the one before it leaves:
Put together, locally: your material stays on your device, the model works from it, the relationships are explicit, and a change anywhere can be traced to what it affects. Each of these is explained from the ground up in the concept map.
Stack all of it (a private local model, given tools, coordinated over a graph with memory, RAG, and GraphRAG) and you have a capable, private, inspectable assistant. You still do not have something that can be the researcher.
Every layer here decides where to look and what to show you, faster and more privately than before. Not one of them decides what is true or what is sound, because that is a judgment made by a qualified person about a specific claim, in light of specific evidence and assumptions. Running the model locally does not move that judgment onto the machine; it just keeps the work on your device. Making it agentic does not grant it authority; it only lets it do more steps. Orchestrating it well does not make the science right; it makes the consequences of a change visible so a person can review them.
The one line to keep. Local, agentic, and orchestrated change where the work runs and how well it is tracked, not who decides. Done honestly, this stack does not replace the researcher's judgment; it makes that judgment better-documented and easier to defend.
See the local, human-first approach in the tools.
Vahtian's research tools are built on exactly this division of labour: run on your own device, keep the human deciding, and record the trail. StudyVahti helps you plan a defensible study before data collection; QualiVahti Local is the packaged local qualitative workflow: transcription, coding under your review, a codebook, evidence maps, and an audit trail, on your own computer.
Start with the AI-concepts map for the whole stack in one table. Then see can a local model check your citations? for an honest laptop-model test, is it ethical to use AI on interview data? for the privacy case, and AI qualitative coding, human-reviewed for the division of labour in practice. More guides are on the Learn page.