Skip to content
FlaskTrack Laboratory Operations & Data Platform
FlaskTrack tutorials · Local AI · Ollama · Hermes · MCP

Run a local AI laboratory assistant with Ollama, Hermes, and FlaskTrack

Ask questions about your laboratory, find the right records, and prepare your next action—with the model and agent running on your own hardware.

This Ubuntu walkthrough connects a model running on your own hardware to production FlaskTrack. Install Ollama, give Hermes access to your organization through MCP, and verify an agent task against your laboratory records.

Why run your own model?

Legitimate biology work can run into broad AI restrictions

If you work in biology, even a straightforward request can meet a refusal from a hosted AI provider. A question about an established laboratory workflow, an explanation of biological terminology, or help organising research notes can be caught by restrictions that do not account for the context of your work. Having to rephrase ordinary requests or switch services interrupts the task you actually came to do.

Screenshot of a ChatGPT refusal concerning a biology-related request.
A provider refusal encountered during biology-related work. Select the image to view it at full size.

Running a model locally gives you more choice over how your assistant behaves. With Ollama and Hermes, you can choose and evaluate a model for your laboratory’s legitimate tasks, inspect the agent configuration, and connect it to the FlaskTrack records it needs. You control the model and agent setup instead of depending entirely on one hosted provider’s behaviour.

Local models can still refuse requests, make mistakes, or struggle with scientific detail. Choose one against tasks you can verify, keep scientific review in the loop, and use FlaskTrack’s permissions to control what the agent may read or change. The practical benefit is a setup you can inspect and adapt as your work evolves.

Your model runs locally. FlaskTrack connects your laboratory.

An assistant does not need a hosted model to be useful. It needs a model that can select tools, an agent that can execute them, and a reliable interface to your records. Here, Ollama handles inference, Hermes runs the decision loop, and FlaskTrack supplies the laboratory tools.

For example: “Find the workflow used for banana multiplication, identify its protocols, and tell me what information is missing before we prepare a batch.” The assistant should retrieve the records and explain what it found, using returned IDs rather than invented references.

What runs locally and what connects to FlaskTrack

Ollama runs the downloaded model on your Ubuntu machine, and Hermes runs the agent loop alongside it. The agent connects over HTTPS to flasktrack.com to discover tools and access records in your organization.

This setup requires internet access to FlaskTrack. You do not need to install FlaskTrack, PostgreSQL, or file storage locally. Laboratory records returned by tools become context for your local model; prompts, conversation history, and any traces may also be stored on your machine. Use hardware and credentials approved for that data.

The goal is local model inference with the production laboratory platform. Keep cloud-model fallbacks disabled if you want inference to remain local.

Before you start

  • An Ubuntu machine with internet access and a FlaskTrack account at flasktrack.com. Choose known records for an initial read-only test.
  • A FlaskTrack organization ID and a dedicated API credential with only the permissions required for the exercise. Start with read-only access where supported.
  • Access to FlaskTrack’s remote MCP server at https://flasktrack.com/mcp, using Streamable HTTP. No local MCP server package is required for this connection. The REST helpers /mcp/tools and /mcp/call alone are not a substitute for an MCP transport.
  • Enough RAM and disk space for the downloaded model and its context. GPU acceleration is helpful; CPU or mixed CPU/GPU execution is still local.

We use qwen3.5:4b as a modest starting point. ministral-3:8b is another tool-capable option. Model quality varies: start with record lookup before asking a small model to produce complicated nested tool arguments.

An 8 GB GPU does not guarantee a 64K context will fit entirely in VRAM. This tutorial uses a larger context for Hermes and accepts CPU offload if necessary. Check actual allocation rather than treating model download size as a memory requirement.

Step 1

Install Ollama and download a model

sudo apt update
sudo apt install -y curl zstd
curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama
ollama pull qwen3.5:4b
ollama --version
ollama list

Complete this step while connected. Keep the installed version and model ID with your deployment notes so that later tests can be reproduced.

Step 2

Create a model with an explicit context budget

cat > /tmp/flasktrack-local.Modelfile <<'EOF'
FROM qwen3.5:4b
PARAMETER num_ctx 64000
EOF
ollama create flasktrack-local -f /tmp/flasktrack-local.Modelfile
ollama run flasktrack-local "Reply with one short sentence confirming you can respond."

Hermes documents 64,000 tokens for agentic work. That is a context setting, not a promise of GPU fit. If loading fails or becomes impractically slow, use a smaller model or more memory. Reduced-context experiments require trimming the tool surface and checking the actual prompt budget.

ollama ps

Look at the processor allocation. Partial CPU/GPU offload can be slower, but does not send inference to a cloud service. To try Ministral later, pull ministral-3:8b, change the FROM line, and rebuild the local alias.

Step 3

Keep Ollama on the local machine

After downloading your model, create a dedicated service override:

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/flasktrack-local.conf > /dev/null <<'EOF'
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"
Environment="OLLAMA_NUM_PARALLEL=1"
EOF
sudo systemctl daemon-reload
sudo systemctl restart ollama
curl -fsS http://127.0.0.1:11434/v1/models

Confirm that flasktrack-local:latest appears. The cloud-disable option applies to Ollama; it does not control Hermes or FlaskTrack network access. Keep internet access available for calls to production FlaskTrack.

Step 4

Install Hermes and create a dedicated profile

Install Hermes using its official installation instructions on your Ubuntu machine. If Hermes is already installed, keep using that installation.

hermes profile create flasktrack-local

Use a fresh profile rather than cloning a cloud-connected agent. This gives the tutorial separate settings and conversation state. If the name already exists, inspect and back up its configuration rather than overwriting it.

Edit ~/.hermes/profiles/flasktrack-local/config.yaml. Merge these settings into the new profile; do not duplicate existing YAML keys:

model:
  provider: custom
  default: flasktrack-local:latest
  base_url: http://127.0.0.1:11434/v1
  context_length: 64000
  ollama_num_ctx: 64000

providers:
  ollama:
    base_url: http://127.0.0.1:11434/v1

fallback_providers: []

updates:
  check: false

telemetry:
  shared_metrics:
    enabled: false
    send: false

Inspect all auxiliary model settings as well as the main model. Keep enabled auxiliary tasks on the local model, and remove any cloud fallback or task-specific remote override. A local main-model URL alone is not proof that every supporting operation is local.

Step 5

Connect Hermes to FlaskTrack

Place the following values in ~/.hermes/profiles/flasktrack-local/.env, replacing the two placeholders with your own credentials. Keep this file out of source control:

FLASKTRACK_ORGANIZATION=YOUR_ORGANIZATION_ID
FLASKTRACK_API_KEY=YOUR_API_KEY
HERMES_API_TIMEOUT=1800
chmod 600 ~/.hermes/profiles/flasktrack-local/.env

FlaskTrack’s MCP server listing identifies io.github.Santurce-Software-LLC/flasktrack as a remote server using Streamable HTTP at https://flasktrack.com/mcp. Add this server entry to the same profile’s config.yaml; Hermes connects directly, so there is no MCP package to install locally for this setup:

mcp_servers:
  flasktrack:
    url: https://flasktrack.com/mcp
    enabled: true
    timeout: 120
    headers:
      x-organization: "${FLASKTRACK_ORGANIZATION}"
      x-api-key: "${FLASKTRACK_API_KEY}"

Hermes resolves the environment references when connecting. The credential belongs in the HTTP headers, not in a user prompt. This is not a secret sandbox: do not give the agent unrestricted file or terminal access to its own credential files.

The remote MCP server handles the protocol connection; Ollama still handles model inference on your machine. The separate REST endpoints /mcp/tools and /mcp/call are useful for direct integrations, but should not replace the MCP server URL in this Hermes configuration. See the FlaskTrack agent integration documentation for organization-scoped authentication and tool permissions.

Step 6

Expose only the tools this assistant needs

hermes -p flasktrack-local tools

In the tool selector, enable the connected FlaskTrack MCP toolset for the CLI and disable unrelated built-in tools, especially web search, browsing, terminal execution, and other external connectors. Use the names shown by your installed Hermes version. Keep the same restriction on the API-server platform if you enable the gateway later.

For a smaller prompt, filter the server to the exact read operations needed for your task. Discover and review the actual tool names first; then add tools.include under mcp_servers.flasktrack. Use the server-native names, not the mcp_flasktrack_ display prefix. A prompt asking for read-only behavior is not an authorization boundary; enforce access with the credential and exposed tools.

If discovery fails, check authentication and standard MCP compatibility first. Enable skip_preflight: true only when a valid MCP POST endpoint is being rejected because its HEAD/GET probe returns a different content type. It cannot turn the REST tool catalog into an MCP server.

Step 7

Run your first laboratory task

hermes -p flasktrack-local chat

Begin with a request you can verify against known records in your FlaskTrack organization:

Use only the connected FlaskTrack tools.
Find workflows whose names contain "banana".
Return the matching names and record IDs.
If nothing matches, say so. Do not create or modify anything.

The useful result is not just a plausible paragraph. Look for an executed FlaskTrack tool call, a successful result, and matching record IDs. Open FlaskTrack and check those records.

Then try a second step:

Using the workflow I select from those results, retrieve its linked
protocols where the available tools permit it. Summarize what is recorded
and identify missing information. Do not invent laboratory instructions,
record IDs, quantities, or relationships. Do not modify records.

This is the agent loop in practice: retrieve, inspect, use the returned identifiers, and retrieve again. Tool results are evidence; text that merely describes a tool call is not execution.

Step 8

Verify local inference and production tool calls

Keep your internet connection active and verify both parts of the workflow independently:

  1. Open FlaskTrack, select the intended organization, and identify a record you can check.
  2. Start a new Hermes conversation using the flasktrack-local profile. Ask for a different known record so the result must come from a fresh lookup.
  3. Confirm that Hermes executes a FlaskTrack MCP read tool successfully, then compare the returned record ID and fields with FlaskTrack.
  4. Run ollama ps during generation. Check Hermes’s resolved model and provider endpoint: inference should use flasktrack-local:latest at http://127.0.0.1:11434/v1.
  5. Check available request or audit evidence for the FlaskTrack call without logging credentials. Inspect auxiliary model settings and confirm there are no unintended remote-model overrides.

Acceptance criterion: a fresh question produces a successful production FlaskTrack tool result and an answer generated by local Ollama. A plausible answer alone does not demonstrate either connection. Without internet access, FlaskTrack lookups will fail even if Ollama can still generate text.

Optional: expose the same agent through the Hermes gateway

The CLI proves the model and MCP connection first. A gateway lets a local application use the agent. Configure the profile’s API-server adapter and authentication using the documentation for your installed Hermes version, then start it:

hermes -p flasktrack-local gateway start
hermes -p flasktrack-local gateway status

Use the callback URL printed by status. With a shared listener on port 8642, the profile-specific URL may be:

http://127.0.0.1:8642/p/flasktrack-local/v1

Preserve the entire path when the client builds request URLs. The unprefixed listener can select the default profile. Begin a new session after changing the profile or model, and avoid client overrides unless needed. If specifying a model, use flasktrack-local:latest.

When status says the profile is managed by the default-profile multiplexer, restart that shared process with hermes gateway restart. Verify the resolved profile and provider endpoint in logs if a request still reports a missing Ollama endpoint. Adding a cloud fallback would hide the failure and defeat the purpose of this setup.

Move from lookup to reviewed actions

Once retrieval works, ask the assistant to prepare a proposed batch or workflow change as a draft in the conversation. Have a person review it before enabling the relevant mutation tools and permissions.

Use actual schemas from the deployed tool catalog. Arrays must be JSON arrays, objects must remain objects, and identifiers must come from the correct entity type. If FlaskTrack returns a validation error, inspect its field path and expected type, correct the argument, and use bounded retries. Do not guess whether a timed-out write succeeded: inspect the resulting records before retrying.

FlaskTrack remains the authority for permissions, organization scope, validation, and any applicable compliance or electronic-signature requirements. Running a model locally does not grant it additional rights or replace scientific review.

Troubleshooting

“Provider ollama has no endpoint configured”
Inspect the profile used by the actual request. Check model.base_url and providers.ollama.base_url, the gateway’s profile path, client overrides, and whether the running process loaded the latest settings.
“Model not found”
Compare the requested name with ollama list and /v1/models. A name in Hermes configuration does not create an Ollama model.
No FlaskTrack tools appear
Check the organization header, credential permissions, MCP handshake, server enablement, tool filters, and the selected platform’s toolsets.
The model prints a tool call instead of executing it
Check that the model supports tools and that Hermes receives structured tool calls. Verify a simple read operation before attempting a multi-step workflow.
The machine becomes slow or runs out of memory
Inspect ollama ps, system RAM, and GPU allocation. Reduce concurrent work, use a smaller model, or reduce the context together with the prompt/tool budget. Keep the Hermes and Ollama context settings aligned.
It works online but fails after disconnecting
Check internet connectivity, the production URL, organization credentials, permissions, and MCP transport configuration. Local model availability does not establish a connection to FlaskTrack.

Optional: local observability

A self-hosted Langfuse deployment can help you compare model responses, tool arguments, timing, and failures. It requires explicit instrumentation; installing Langfuse does not automatically trace Hermes. Choose where traces are stored deliberately, and test that a model response and a FlaskTrack tool call are captured as expected.

Capture the requested and resolved profile, provider, model, and endpoint before inference. That exposes routing errors which never reach Ollama. Exclude credentials and authorization headers, and choose deliberately whether laboratory prompts and tool results belong in traces.

Reference documentation

Configuration references checked October 29, 2026. Match the instructions to your installed versions and verify local inference and production tool calls before relying on the workflow.

Build around your laboratory

Start with one useful task. Keep control of the whole system.

A local assistant can make laboratory records easier to work with while keeping inference on your infrastructure. Start with a verified lookup, add reviewed actions, and expand around the tasks your team actually performs.

Want help deploying custom software like this? Talk to Santurce Software about AI integrations and custom agent workflows → You can also explore its separate Santurce Software MCP server listing.

Screenshot preview