Field notes
About
I’m Nathan Keilar. I build systems that automate expert work, and I run the infrastructure they live on. I’m the founder of Hunted Hive, a development studio in Brisbane, and of CNXION and FutureForce.ai — a marketplace platform and an agent platform built out of it.
As an undergraduate I wrote a thesis on using multi-agent systems to integrate distributed generation into a national power grid — autonomous programs negotiating with each other to keep a physical network stable. That was about fifteen years before “agents” meant what it means now, and it turns out to have been good preparation. Most of what I’ve done since has been some version of the same problem: getting independent systems to cooperate reliably enough that you can trust the result.
Most of my work sits in the unglamorous half of software — the pipelines that turn a manual expert process into something a machine does reliably, the operations that keep it running, and the audit trail that proves it did the right thing. I work end to end, architecture through to the servers, mostly because the interesting problems are at the seams.
§What I work on
Automating expert judgement in regulated domains. Document-heavy processes where being wrong has consequences: compliance review, conveyancing, valuation, reconciliation. The hard part is rarely the model. It’s hostile inputs, evidence you can defend, and a workflow a domain expert will actually trust.
AI systems, end to end. The agent pipelines that build software, the verification that stops them shipping nonsense, the hardware they run on, and the gateway in front of them. I’m opinionated about adversarial review: an agent grading its own work finds far fewer problems than a fresh one trying to break it.
Making models fit where they shouldn’t. Low-bit quantization, CPU inference, and the economics of owning your compute instead of renting it. I like the constraint — it forces you to understand what the model is actually doing.
Self-hosted infrastructure. A private fleet of around sixty machines, managed as code, with a runbook per service and a written record of every mistake worth not repeating. I run my own compute partly on economics and partly because operating the thing you built teaches you what you got wrong.
§For scale
Numbers are a blunt instrument, but they answer the obvious question. Across roughly a hundred and forty repositories I’ve pushed about eighteen hundred commits in the last ninety days. I’ve built a dozen or so MCP servers, run around twenty applications on infrastructure I operate myself, and keep the whole estate documented well enough that a stranger — or a future me — could pick it up.
None of that is the interesting part. It’s just evidence that the opinions further up this page were paid for.
§How I think about it
Content and systems should outlive their tooling. Write the recovery command while the system still works. Prefer things one person can keep alive for twenty years over things that need a team to stay upright.
That’s most of my engineering philosophy, and it’s why this site is a folder of markdown files in git — if every other layer disappeared tomorrow, the writing would still be here.
§Work with me
I take on architecture and build work, AI adoption strategy, and advisory engagements — usually where something needs to move faster than the current setup allows, or where a manual process should have been a system a while ago.