Why I started building a local model workforce

I started building this system to finish my PhD while holding down a full-time job. CLI coding harnesses were becoming useful enough to change how I worked, but I kept asking one frontier model to plan, remember, implement and review everything. The supposed automation still needed constant supervision. I wanted the work to be easier to complete and the knowledge produced along the way to remain mine.

I had already spent more than a year experimenting with local models. This system's current lineage began in December 2025, as Claude Code was becoming widely adopted. I started two private environments: PhD Knowledgebase, which became Nuthatch, and Agentic-Orchestrator, which became Hillstar.

Together they gave me structured access to research knowledge and reproducible orchestration for bounded work. They supported a Mouse Phenome Database phenome-classification manuscript and other doctoral publications. I was also fine-tuning DNABERT-2 for the research and using small local models through Hillstar for scoped implementation.

Another instruction file was not the whole answer

The promise was appealing: describe an objective and let the model plan, implement, test and revise it. Repository instructions, skills, plugins, MCP servers and orchestration frameworks could help. They could also load more context, repeat rules and add dependencies without making it any clearer which control actually governed the work.

This was not only my experience. Across model ecosystems, practitioners described invented objectives, idle agents, long-session degradation and substantial effort spent on work nobody requested.

Tang and colleagues examined related failures in 20,574 coding-agent sessions from 1,639 repositories. Among validated misalignment episodes, 38.33% involved developer-constraint violations, 22.58% inaccurate self-reporting, and 10.20% self-initiated overreach. Effort or trust costs appeared in 90.50% of episodes; 91.49% of visible resolutions required explicit developer correction. Those are figures about the identified episodes, not a failure rate for every agent session. The screenshots below illustrate the kinds of problems involved.

Practitioner evidence: three common forms of agent friction

Instructions can change behaviour without improving the result

A descriptive study of 253 CLAUDE.md files found build commands, implementation details, architecture and test instructions. That tells us what developers put in these files. It does not tell us whether the files make a task more likely to succeed.

Gloaguen and colleagues tested that question across multiple models and coding agents. Repository context files did not generally improve task success and increased inference cost by more than 20% on average. Agents usually followed the instructions. Extra requirements could send them exploring more broadly and make the task harder. The authors recommend keeping the files for minimal, non-standard requirements and testing their effect.

In more than 5,000 controlled Claude Code runs, Zhang and colleagues found that individually beneficial rules were negative constraints, such as not refactoring unrelated code. Individually harmful rules were positive directives. Random and mismatched rule sets performed as well as curated sets on their discriminative subset. That is a reason to test what an instruction does, rather than assume a larger instruction bundle is better.

My own result was narrower. An untouched 4B base model did not reliably return the typed Implementer output I needed. Fine-tuning taught it those delivery conventions and role behaviour. Repeating the complete operating method in Markdown would otherwise keep expanding the prompt as the system grew.

I later ran a controlled 27-case comparison with the same fine-tuned checkpoint, tasks, inference profile and deterministic controls. The only changed factor was a representative CLAUDE.md/AGENTS.md bundle.

This does not make every repository instruction harmful. Project-specific commands, invariants and exceptions are still useful. The result belongs to this fine-tuned Qwen3.5-4B model, this bundle and this evaluation. A larger model may cope differently. I want stable role behaviour learned where that helps, and short repository-specific instructions tested where they are needed. Fine-tuning changes what a model is likely to do. Schemas, hooks, mediated tools, isolation, tests, review and human approval constrain what it may do.

Useful extensions still need to earn their access

Skills and plugins can package useful procedures, but they are dependencies with consequences. Installing one may expose source code, credentials, files or APIs. MCP servers add useful capabilities and also extend the security boundary.

That is not an argument against reuse. It is an argument for checking provenance, versions, privilege and runtime access. The May 2026 TanStack compromise put 84 malicious versions across 42 packages into the release path. Research into MCP servers and agent skills describes related risks. Another layer should earn its place rather than arrive on the strength of its demo.

I have a similar concern about Andrej Karpathy's LLM-Wiki proposal. A derivative wiki can be useful, but model-written revisions can make errors persistent and harder to trace back to a source. Ingestion and maintenance also cost something. I want the structured knowledge without letting its generated summary replace the attributable evidence.

How I split the work

The diagram looks busy. The working idea is less intimidating: separate the decisions that one long model conversation was trying to hold together.

First, the user and Planner agree what the feature must do. Hillstar routes that approved task by complexity. An Implementer works inside the controlled runtime, an independent Reviewer checks the result against the rubric, and a human decides whether accepted work can proceed.

The Planner and Reviewer stay scoped to a feature, and different features can use different models. That limits the context each model receives. Using more than one provider also means less of the product's knowledge needs to be given to any one external company.

Cheng-Yuan Lee's FrontierCode analysis describes another reason for that split: higher reasoning effort can bring more unrequested scope. I do not think users should have to accept that as the price of capability, or be told they are using the tool incorrectly while another tightly prepared demo is presented as typical work.

Why reasoning effort affects role assignment

What I have built

These components are at different stages. Some are usable; others still need integration and hardening. The expandable sections describe what I have built without implying that every path is production-complete.

Vogelkop: a unified, multi-model research environment

The research environment grew into Vogelkop. It brings knowledge retrieval, model orchestration, references, citation networks, Markdown writing, task boards and a terminal into one UI. Those are selected capabilities, not a claim to describe everything the application does.

The terminal and orchestration layers support remote HPC connectivity, Slurm-managed compute, configurable coding harnesses, local inference, cloud providers, and DGX Spark endpoints. The workflow design supports Snakemake and existing genomic workbench tooling.

Different models and services take different jobs instead of placing the whole research workflow inside one general model or provider. The same constraints apply throughout: task-bound context, mediated access, reproducible execution, review and human authority.

I pushed a demonstrable version to my private GitHub repository on 29 June 2026. Anthropic announced Claude Science the next day. The coincidence is worth noting as independent convergence, not foreknowledge or product equivalence. I later demonstrated Vogelkop privately to the Dennis Lal Research Group. At the date of this article it is not in public preview, and I am describing only part of it. Dennis Lal Research Group

Select the image to open the full-size view.

×

The interface represents months of integration across knowledge systems, orchestration, providers, local inference, scientific workflows, tasks, references and compute. I hope the screenshot makes that shape visible. It does not explain the architecture, statistical methods or operational decisions needed to build it.

Other people are working towards similar arrangements

The recent posts below do not validate my architecture. They do show other researchers and builders asking related questions about workflows, specialised models and control of institutional knowledge.

Industry signals: the posts in their own words and context

The emerging conclusion is not “never use frontier models.” It is that models should remain replaceable components inside an organisation's own knowledge, evaluation, orchestration, and learning system.

Where this work is taking me

I conceived and built this work independently, outside my current role. It began as a way to make my own research easier, contribute to the open-source environment and develop my skills.

I approached it as a Data Scientist and ML Engineer. It kept crossing into knowledge engineering, ML platforms, fine-tuning, evaluation, agent architecture, secure execution, orchestration, research computing and AI governance.

The hard part is not claiming that any one of those fields is new. It is understanding how they fit: retaining provenance, choosing models without giving away the workflow, constraining execution, testing outcomes and turning reviewed corrections into owned knowledge.

I expect organisations will want to do more of this with the knowledge they already hold. They may initially hire outside help for a fine-tune, an evaluation or a security review. Repeatedly treating those as unrelated engagements could become expensive. My expectation is that internal roles connecting them will begin to appear over the next six to twelve months. That is a forecast from the date of this article, not an observed industry result.

I am less optimistic about large organisations that keep the work in separate silos. They risk duplicating effort and choosing disconnected solutions. The useful distinction is not size alone, but whether an organisation can evaluate and adopt the pieces together.

These products are not a finished commercial suite. Some are usable now; some need more integration and hardening. I built them outside my day job while working towards my PhD. Their value, to me, is the sustained work of putting a system together, not a claim that a screenshot proves it complete.