Local AI runtime & agent orchestration

Localbots

A Go-based local agent framework and web studio: a manager coordinates specialist bots through one resident Qwen3 model, with no cloud API required after setup.

  • Backend
  • AI inference
  • AI training
Localbots interface
The local dashboard, captured in the repository evaluation assets.

The context

Localbots makes a small local language model usable across several specialist roles on one laptop. A manager plans and reviews tasks, while a local web studio exposes progress, results, files, and follow-up requests. Go coordinates the runtime, llama.cpp serves Qwen3-1.7B, and SQLite stores goals, runs, traces, and checkpoints.

My contribution

  • Built a Go CLI, loopback HTTP service, and local web studio for configurable specialist bots and manager-led task orchestration.
  • Coordinated a single resident model with serialized inference access and a bounded job queue, rather than loading a separate model for each bot.
  • Implemented schema-constrained planning, bounded retries, duplicate tool-call guards, context budgets, per-goal workspaces, and file-access grants enforced outside the model.
  • Persisted goals, tasks, runs, and traces in SQLite, with interrupted work surfaced for review instead of silently replayed.
  • Added experimental local QLoRA training, LoRA adapter packaging, compatibility/provenance checks, and comparisons against base and role-prompted configurations.

Challenges & solutions

Running multiple specialist roles within one laptop’s model and memory budget.

Shared one Qwen3-1.7B model served by llama.cpp, serialized model acquisition, and bounded queued work. Bots specialize through configuration and optional adapters rather than separate resident model copies.

Keeping small-model orchestration structured and recoverable.

Validated manager plans against a schema and real worker names, bounded retries and tool loops, and recorded task progress and checkpoints in SQLite.

Separating model suggestions from file-access authority.

Enforced granted filesystem roots in Go and isolated goal workspaces. File-tool grants are not a general sandbox for trusted executable plugins.

Evaluating adapter specialization without overstating its quality.

Built a separate QLoRA training/conversion path with pinned model identities, dataset checks, adapter manifests, and fixture comparisons. Reported synthetic results remain narrow experiments, not evidence of broad generalization.

Pipeline overview

A simplified view of the workflow.

  1. Studio / CLI goal
  2. Manager plans & reviews
  3. Specialist task execution
  4. Shared local model & tools

Scope & outcomes

Shared resident inference runtime
One model
Offline operation after setup
Local-first
Persistent goals, runs & checkpoints
SQLite

Public source and repository evaluation records are available on GitHub. The runtime is Windows-first, and small-model outputs still need human review. Adapter results are limited to the documented experiments; no broad quality or performance gain is claimed here.

Building something related?

Tell me about the problem, the constraints, and what success would look like.

Discuss a similar project