At Pickett Applied Technologies Laboratories, we don’t have a building full of researchers or a massive compute cluster. We have an small lab, a handful of good models running locally, and a very clear mission: develop practical, high-performance materials and systems that actually work in the real world.
For the past several months, I’ve been building something I call BORG Queen — an autonomous research orchestration system that helps me generate, evaluate, and refine technical ideas at a pace I could never sustain manually. This post is about why I built it, how it works, and what it means for the kind of research small teams and independent labs can do going forward.
The Problem I Was Trying to Solve
Like many solo researchers and small labs, I was spending too much time on the mechanics of research rather than the thinking. I would come up with a goal — whether it was a self-healing composite for unmanned systems or a new thermal protection approach — and then spend hours or days doing the following:
- Breaking the problem down
- Generating multiple possible approaches
- Researching materials and methods
- Tracking what I’d already tried
- Comparing results across iterations
Even with good local models, this process was fragmented. I was copy-pasting between terminal windows, notes, and documents. Worse, I was losing the thread between iterations. When I wanted to refine an earlier idea, I often had to dig through old Markdown files or try to remember what the model had suggested two weeks earlier.
I didn’t need another chatbot. I needed a system that could think with me over time.
How BORG Queen Came Together
BORG Queen started as a relatively simple script that ran 2-3 parallel hypothesis agents. Over time it grew into something much more structured. The name is partly tongue-in-cheek (a nod to collective intelligence), but the actual design is the opposite of assimilation — it’s about giving one researcher a reliable team of specialized agents that follow a consistent process.
The system is built around a simple but strict loop:
- a) Deeply understand the problem and any previous attempts
- b) Develop a clear plan
- c) Launch specialized agents to generate options
- d) Validate and correct the output
- e) Repeat until the goal is meaningfully advanced
This structure is enforced in the prompts themselves. The model isn’t just asked to “be helpful.” It is explicitly told to follow this sequence. That discipline has made a surprising difference in output quality.
Over time I added several important capabilities:
- A full graphical interface so I’m not living in the terminal
- Persistent storage (SQLite) so every hypothesis, rationale, and result is saved and queryable
- The ability to deliberately refine a previous iteration instead of starting from scratch
- Automatic generation of clean Markdown reports for every iteration
The result is that I now have a living record of research that I can actually use.
What Makes It Effective
Several design choices have proven especially valuable:
Local-first architecture. Everything runs on local models through Ollama. There is no telemetry, no data leaving the machine, and no dependency on someone else’s API. For defense-related and proprietary materials work, this isn’t just nice to have — it’s necessary. In the cyber-security realm, it’s just common sense.
Structured reasoning over raw creativity. Early versions sometimes produced flashy but impractical ideas. By forcing the model through an explicit understand-plan-execute-validate loop, the output became more grounded and useful. The model still generates creative ideas, but they’re now filtered through a more rigorous process.
All hypotheses are preserved, not just the “winner.” When the system generates ten hypotheses in parallel, all ten are saved. This has been surprisingly valuable. Sometimes the best path forward comes from combining elements of two earlier, non-selected ideas.
Refinement as a first-class feature. Being able to point at a specific previous iteration and say “improve on this” has changed how I work. It turns the system from a one-shot idea generator into something closer to a long-term research partner.
Human in the loop, but not doing data entry. I still make the important decisions — which direction to pursue, which previous result to build on — but I’m no longer spending hours formatting notes or tracking versions.
What This Means for Future Research
Tools like BORG Queen point toward a meaningful shift in how small teams and independent researchers can operate.
For decades, advanced materials development and complex systems engineering have been dominated by large organizations with big teams and expensive infrastructure. That made sense when the tooling itself was expensive and required large groups to operate. But the combination of strong local models, structured agent workflows, and persistent research memory changes the economics.
A solo researcher or very small team can now maintain a much larger effective “surface area” of exploration. We can generate and evaluate more ideas, track them more rigorously, and iterate faster than was previously practical. The bottleneck is shifting from idea generation and tracking to physical validation and testing — which is exactly where it should be.
I also believe this approach has implications beyond my own work. Many of the most interesting technical problems today sit in the gap between academic research and large corporate R&D. Small, focused teams working on specific hard problems often lack the infrastructure that big organizations take for granted. Systems that give those teams leverage without requiring them to become software engineering organizations themselves could meaningfully accelerate progress in materials, energy, defense, and other critical fields.
Where We’re Going Next
BORG Queen is still evolving. Current priorities include:
- Making the “Refine Previous” workflow even more seamless
- Improving how the system reasons about previous results when generating new hypotheses
- Developing more specialized drone models that are optimized for narrow technical tasks rather than general conversation
- Exploring longer-term memory and cross-campaign learning
The goal isn’t to replace human judgment. It’s to remove as much friction as possible between having a good idea and rigorously testing whether it actually works.
Final Thoughts
Building BORG Queen has been one of the more interesting engineering projects I’ve worked on in years. It sits at the intersection of materials science, systems thinking, and applied AI — exactly the kind of multidisciplinary work PAT-Labs was created to do.
More importantly, it represents a philosophy: that serious technical work doesn’t require massive teams or massive budgets if you’re willing to be deliberate about how you use the tools that are now available. A well-designed local system, guided by clear process and human oversight, can do work that would have required a much larger group just a few years ago.
We’re still early in figuring out what these kinds of tools can really do. But I’m increasingly convinced that the organizations that learn to use them effectively — not just as chatbots, but as structured research partners — will have a significant advantage in the years ahead.
If you’re working on hard technical problems with limited resources, I’d encourage you to experiment with building your own versions of these kinds of systems. The technology is accessible enough now that you don’t need a large team to get started. You just need a clear process and the willingness to iterate on the tools themselves.
That, more than any single model or feature, is what I think matters most.
Leave a Reply