Build AI-First: Turn Your Hardware Into a Self-Hosted AI Company Brain

Build AI-First: Turn Your Hardware Into a Self-Hosted AI Company Brain

Companion to my talk at AI Tinkerers Orange County — June 2, 2026: "AI and the Business Startup Process." I'm David Parkhurst, Knight Radiant & Architect at Aitherium. This is the build log behind "AI Company Brains and Personal Agents" — what I built, why I built it this way, and how you can start tonight on the hardware you already own. RTX 5090 + DGX Spark under my desk, demoing through a Cloudflare tunnel back to my house.

There's a version of the AI-startup story everyone's selling right now: rent a frontier API, wrap it in a thin app, bolt on Auth0 + Vault + SendGrid + a vector DB + an observability SaaS, and pray the unit economics survive before the model provider eats your margin or your category.

I went the other way. For ~8 months — mostly solo — I've been building AitherOS: an AI-native operating system where the company itself is the software. Not a chatbot bolted onto SaaS. A company brain — a fleet of specialized agents, a from-scratch self-hosted services layer, and a cognitive loop that remembers, learns, and ships — running on my own hardware, zero cloud LLM spend.

This is the honest version of how it works, and how you can build the same way.

First, the receipts

If I'm going to claim one person can build a company's worth of software with agents, I should show the code, not just talk about it. Git-tracked source in this monorepo, today:

That powers 252 services across 24 domains, 1486 MCP tools, a fleet of specialized agents, a Next.js operator dashboard, a PowerShell automation framework, and a public SDK. One person. ~8 months. A single RTX 5090 and a DGX Spark in a homelab.

LOC is a famously bad productivity metric — that's not the point. The point is the question it forces: what kind of leverage makes ~4.5M lines of integrated, running system tractable for one builder? That's the whole talk. Here's the answer.

The thesis: build AI-first, local-first

Most "AI apps" treat the model as a feature. AI-first means the model is the substrate your architecture is organized around — and your job is to build the world it operates in: tools, memory, identity, money, comms, deployment. The app is emergent.

And local-first, because the moment your company brain depends on someone else's API, three things happen: costs scale with your success, your data leaves the building, and your roadmap is hostage to a provider's deprecation schedule. On your own hardware:

• Inference is a fixed cost, not a variable tax. A 5090 doesn't bill you per token.
• Your data never leaves. Customer records, internal docs, conversation history — all on metal you own.
• No lock-in. Swap models, fork services, walk away anytime.

The objection is always "local models aren't good enough." That stopped being true the moment I found the right shape for the system.

The core insight: small orchestrator + reasoning as a tool

This is the single most important idea, and the heart of the talk:

You don't need one giant model to do everything. You need a small, fast orchestrator that knows when to think — and a reasoning model it can call as a tool.

User Request
    │
    ▼
[ nemotron-orchestrator-8b ]  ← always resident, runs on one 5090
    │
    ├── ~90% of requests ───────────────► direct response
    │
    └── "I need to think harder" ──► calls the reason() tool
                                         │
                                         ▼
                                   [ Qwen3.6-27B reasoning ]  ← summoned on demand
                                         │
    ┌──── reasoning result ◄────────────┘
    ▼
 Response

• nemotron-orchestrator-8b is the always-on brain. Small, fast, comfortable on a single GPU. Its job is routing: understand intent, pick the agent, the tools, the depth. It handles the ~90% of requests that don't need a PhD.
• Qwen3.6-27B is not the default — it's a tool the orchestrator invokes (reason(...)) only when a problem warrants slow, deep thinking: root-causing a failed deploy, planning a multi-step migration, distilling a huge context down to the relevant slice.

An effort scaler picks the tier automatically (effort 1–2 → small model, 3–6 → orchestrator, 7–10 → reasoning), so compute is spent where it matters. And every LLM call routes through MicroScheduler — a priority queue + VRAM coordinator that does preemption, queueing, and model swaps. It's the air-traffic control that lets a homelab GPU behave like a fleet.

Builder takeaway: stop trying to make one model do everything. Compose a cheap router with expensive reasoning-on-demand, and local hardware punches way above its weight.

I rebuilt the SaaS layer (on purpose)

Here's the part people find crazy. Instead of wiring up Auth0 + Vault + SendGrid + an LDAP SaaS + a managed tunnel + a logging vendor, I built my own — from scratch, as services in the same brain:

• AitherIdentity — auth, RBAC, SSO, magic-link + OTP login, webhooks. The whole identity plane.
• AitherSecrets — a scoped secrets vault. HMAC-signed capability tokens, default-deny.
• AitherMail / SMTP — real outbound email with a priority queue (a login code never waits behind a newsletter blast).
• AitherTunnel — Cloudflare-tunnel orchestration; every public surface routed from internal Docker DNS, no open ports.
• AitherDirectory — an LDAP-style directory for users, tenants, contacts, distribution lists.
• Strata — the data/memory ingest plane: every session, decision, and output flows here.
• Chronicle — structured logging and the system's event spine.

"Why rebuild all that?" Two reasons.

Control. When identity, secrets, mail, and memory are your services, agents can operate them safely and deeply — provision a user, rotate a secret, send a verified email, write to the knowledge graph — all behind one capability system. You cannot give an autonomous agent that reach over a pile of third-party SaaS without it becoming a security incident waiting to happen.

Leverage. Each of these used to be a company. Building them with agents is the demonstration — the company brain building the company's own infrastructure. That's the real "50x" story, and it's not a slogan; it's 252 services of evidence.

AitherZero: turn your box into a self-hosted AI research lab

The glue that makes a homelab feel like infrastructure is AitherZero — a PowerShell-7 framework of numbered scripts (0000–9999) covering the whole lifecycle:

00-prerequisites/   10-initialization/   20-networking/
30-services/        40-deployment/       50-maintenance/
60-monitoring/      70-security/         80-testing/   90-cleanup/

One command bootstraps a node:

./bootstrap.ps1 -Mode New -InstallProfile Standard

And Docker profiles keep startup graduated — you don't boot all 196 containers to chat:

docker compose --profile chat-minimal up -d   # raw LLM chat (~20 containers)
docker compose --profile chat-full    up -d   # + personality + memory (~29)
docker compose --profile chat-agents  up -d   # + agent tool use (~31)

The single most underrated step for builders: automate your environment first. If standing up your stack is a 40-step wiki page, your agents can't operate it. If it's one script, they can. AitherZero does the unglamorous work — dependency install, GPU detection, orchestration, health checks, autonomous redeploys — so the agents do the interesting work on top.

The cognitive loop: memory, autonomy, and a training flywheel

A company brain that forgets everything between conversations isn't a brain. The part I'm proudest of is the loop that makes it get better on its own.

Real-time memory — graphs + embeddings. Every conversation, document, and decision is ingested into a unified memory graph with vector embeddings. Recall isn't just similarity search — it's spreading activation across a typed graph: decisions constrain plans, corrections outrank stale facts, supersession cascades. The brain knows who you are, what you decided, and what you're working on — in real time, not at training time.

Autonomous routines. Scheduled agents run proactive work on their own cadence — monitoring service health, triaging issues, drafting changelogs, summarizing the day. A 30-second "awareness tick" keeps the orchestrator situationally aware of the whole system.

Autonomous data collection → fine-tuning. This is the flywheel. The system watches its own best work — successful plans, good answers, clean fixes — and harvests them as training data. That feeds a search-distillation pipeline where the big reasoning model (Qwen3.6-27B) acts as a teacher and the small orchestrator learns to plan like it. The cheap, fast model keeps getting smarter at the exact tasks your company does, on data your system generated, on hardware you own. No data leaves. No labeling vendor. The loop closes.

That's the difference between renting intelligence and compounding it.

Claude Code as command & control

I plan with cloud intelligence and execute on local hardware. Claude Code is my command deck; AitherOS is the local infrastructure it drives — through 1486 MCP tools, all routed to local compute: code search (CodeGraph + Repowise), agent dispatch (forge_subagent), the memory graph (remember/recall/query_memory), git/filesystem/terminal, and local vLLM inference.

Claude Code → MCP → AitherNode → local services → vLLM → response

The same tool surface is consumed by Claude Code, Cursor, and Copilot — the closest thing to a universal agent API right now. Cloud intelligence for planning, local hardware for execution.

Five things I got wrong (so you don't have to)

The lessons that actually moved the needle:

1. Don't gate capabilities by effort — gate budgets. I first built effort levels that disabled reasoning and tools for "easy" questions. Easy questions got dumb answers. Fix: effort only controls max_turns / max_tokens / max_tool_calls. The model always has access to everything — it just gets less runway at low effort. A two-word question about quantum physics should still be able to call the reasoning model if the router thinks it needs to.

2. Truncation destroys context — use extractive compression. Hard-truncating context at 4K tokens lost headers, structure, the parts the model actually needed. Now I score every line (headers 5.0, code 3.0, key-value 2.0) and boost lines matching the query (+2.0/term), keep the highest-scoring lines, and rebuild in original order. Evicted content spills to a bus the next query can recall. ~75% of the signal in ~25% of the tokens.

3. One process owns the GPU, or nobody does. Three agents calling vLLM directly → OOM at 2 a.m. Now every call queues through MicroScheduler: priority preemption, per-model VRAM tracking, a fixed slot pool, and upstream token-budget declaration so the system predicts saturation before it hits. Zero GPU OOMs since.

4. Reasoning is a tool, not a tier. I used to route "hard" questions to the big model and "easy" ones to the small one. Wrong framing. The 8B orchestrator handles everything and calls the Qwen3.6-27B reasoning model when it decides it needs to. Turns out that's ~10% of requests; the other 90% are faster and cheaper without the round-trip.

5. Your system prompt is a 12-layer pipeline, not a string. Static prompts don't scale. Mine assembles: axioms → identity → rules → capabilities (HMAC-signed) → live system state → memories → affect → recent conversation → web search → code graph → execution plan → quality feedback. Each layer has a token budget; over budget, extractive compression kicks in and evicted content spills to lower tiers. The model always gets the most relevant context for this query.

What worked from day one: KV-cache compression (open-sourced as aither-kvcache, ~3.8× VRAM savings, more concurrent users, no quality loss); MCP for everything (1486 local tools, one surface for every client); and one YAML file — services.yaml defines all 252 services, their ports, dependencies, and health checks. That file is the reason one person can manage this without losing their mind.

What you can take home tonight

pip install aithershell aither-adk aither-kvcache

aithershell — a standalone CLI that works with Ollama, vLLM, or OpenAI directly (no AitherOS required):

aither --init                 # configure your LLM backend
aither "build me an agent"    # instant chat

aither-adk — the Agent Development Kit; a working agent in ~10 lines, auto-detecting Ollama → vLLM → OpenAI:

aither init myagent && cd myagent && aither run

aither-kvcache — drop into any vLLM instance for ~3.8× VRAM savings:

# add to vLLM args:
--kv-cache-dtype tq-t4nc

Hardware scaling:

From tinkerer to LLC (the "business startup process" part)

You built something cool — now make it real. Stripe Atlas gets you from side project to legitimate company in ~10 minutes: form your LLC (or Delaware C-Corp), get your EIN, open a bank account (Mercury/SVB pre-connected), and turn Stripe payments on immediately. ~$500 one-time, no ongoing Atlas fee.

Why it matters for AI builders specifically:

• Business accounts get higher API rate limits across providers.
• Liability protection — your agent gives bad advice? The LLC shields personal assets.
• Tax deductions — that 5090 and DGX Spark are now business expenses.
• Real contracts + billing — clients pay an LLC, and Stripe subscription billing is built in from day one.

If you're already running local inference and selling access (portals, consulting, agent-as-a-service), you should have done this yesterday. The LLC costs less than one month of cloud GPU rental.

If you take one thing from the talk

You do not need a 25-person team and a stack of SaaS subscriptions to build an AI-native company. You need:

1. A small local orchestrator that routes and knows when to think.
2. A reasoning model as a tool, summoned on demand.
3. A real services layer agents can safely operate — identity, secrets, mail, memory.
4. Automation that turns your box into infrastructure.
5. A loop that collects your own data and compounds your own model.

Put those five together and one builder with a homelab can do what used to take a funded team and a year. I've got ~4.5 million lines of running system that says so.

Build AI-first. Build it local. Build it so it builds itself.

Poke at the live system

• See it running: demo.aitherium.com — chat with Aither, take the guided tour, watch real GPU/queue stats tick.
• Build your own agent: pip install aither-adk — aither-adk on GitHub.
• Self-host the stack: AitherZero — bootstrap a node, run your own local inference.
• Get a hosted workspace: portal.aitherium.com.
• PyPI: pip install aithershell aither-adk aither-kvcache

— David Parkhurst · Knight Radiant & Architect at Aitherium · aitherium.com

Want the deep dive? Take the interactive architecture tour, or come find me after the talk.