Technical work / Current and hands-on

Systems I build,
run, and recover.

A Proxmox host running more than 30 virtual machines and containers, the software that watches, deploys, and recovers it, and AI agents, working across several model families, that help build and operate it.

Scope: personal infrastructure plus one small-business client, not enterprise customer production. AI agents implement substantial parts of the code and configuration. I set the goals, architecture, and boundaries, choose the models, require the evidence, and make the consequential decisions.

01 / Systems in operation

Three systems.
Each one running.

Each case follows the order a technical evaluator asks about it: the problem, the architecture, how it is operated, and what happened.

Case 01 / Personal infrastructure

An operational control plane

A private, read-only service that shows what is actually running, what is backed up, and which facts have gone stale.

Live verifiedDocumentation derivedUser suppliedInferredUnknown

Problem: Dozens of services share one environment, and documentation and dashboards can each be wrong in different ways. I wanted one view that kept documented expectations apart from live observations, and said how old each observation was.
Architecture: A typed Python service with SQLite and Alembic migrations, run in Docker Compose on a dedicated VM behind private HTTPS. Read-only collectors query the Proxmox API, Prometheus, service health checks, and the UPS through an API role scoped to auditing. Every fact carries an evidence class.
Operations: Releases deploy only from reviewed commits with a recorded rollback target. The container runs as a non-root user with a read-only filesystem and no Linux capabilities. The deploy tool keeps a crash-safe journal; on recovery it checks that journal against the running container, image, and database, and stops if they disagree.
Result & learning: A database-lock incident first looked like a timeout. Raising the timeout did not hold; profiling showed a retention job stuck deleting rows through unindexed relationships. New indexes and small committed batches fixed it, verified live before the incident was closed. The first plausible fix was only a hypothesis.

Case 02 / Personal infrastructure

A backup and recovery program

Turning “backups succeed every night” into an evidenced answer to “what can we restore, and in what order?”

Backup exists Restore exercised Integrity verified Recovery accepted

Problem: Backup jobs reported success, which is not the same as knowing what can be restored after a given failure. Some recovery paths also depended on the very systems they were meant to protect.
Approach: A read-only audit of the hypervisor, storage, backup server, and network produced an inventory, a dependency map, and a findings register. Remediation was staged, with each phase approved before any change. Runbooks cover single-guest, boot-disk, host, storage, backup-server, and total-site loss.
Operations: Restore validation exercises the real backup data path rather than checking that snapshots exist: data restored from backups must pass integrity checks, and off-site archives are extracted and inspected rather than assumed. A separate review decides which recovery claims to accept.
Result & learning: The work exposed an undetected failure in an off-site backup path. That led to real restore validation, a redesign of parts of the recovery approach, and monitoring of the backup artifacts themselves. Remediation is ongoing. A backup that exists is not a recovery that has been demonstrated.

Case 03 / Working method

Directing AI agents inside a harness

Agents do real engineering, research, and operations work here. They do it inside a structure that defines what they may touch and what counts as done.

Goal & constraints Agent execution Evidence Independent review Correct or ship

Problem: Agents can produce days of work in hours. They can also change the wrong thing, skip a check, or declare success without proof. A clever prompt does not fix that; the environment around the agent has to.
Harness: Persistent project instructions agents read before acting. Tool and access boundaries, with production authority granted explicitly and narrowly. Work items with a goal, exit gates, and required evidence, tracked by a small coordination service separately from each agent run.
Operations: Agents run long, goal-directed loops on branches: investigate, implement, test, and repair until the exit gates pass. Restricted host accounts limit what they can execute. Infrastructure changes need a reviewed commit, a recorded rollback path, and live proof before the work is closed.
My role: I define the goal, architecture, and constraints; choose the models; challenge conclusions; require tests and verification; use a separate model for adversarial review; and make the architecture and risk decisions. Then I operate what gets built.

02 / Model selection · Multi-model workflows

Choose the model
for the task, not the vendor.

Reasoning depth · Latency · Context · Cost · Independent review

No single model is the right choice for every stage of a piece of work. I treat model capability, reasoning depth, latency, context size, cost, and volume as an engineering decision, made per task. One goal often moves through several models before it is finished.

High-reasoning frontier models are worth their cost for architecture, difficult diagnosis, security and recovery analysis, and final judgment. Faster, lower-cost models are better for broad evidence gathering, repository archaeology, mechanical changes, and repetitive validation. Review comes from a different model, which is less likely to share the author’s blind spots.

Plan & adjudicate High-reasoning model
Architecture, ambiguous decisions, diagnosis, security and recovery analysis, final calls.
Investigate & execute Fast, cost-efficient model
Evidence gathering, repository archaeology, well-specified implementation, repetitive checks.
Review Independent model
Adversarial review of the plan and the result, ideally from a different model family.
Close Evidence, correction, verified result
Findings go back to the worker until the checks pass.

In practice, as of September 2026: frontier models from OpenAI and Anthropic at several tiers, DeepSeek and other cost-efficient models for high-volume work, and open-weight models on local hardware through Ollama. They run through Codex, Claude Code, and OpenCode, often with planning, execution, and review assigned to different models, and through a LiteLLM-based router that meters tokens and latency per model. Reasoning depth starts low and is raised deliberately where the judgment involved is worth the cost.

Architecture explorer

Follow the task. See the boundary.

Conceptual view

Local audio path

AudioWhisper ASRTranscript

Transcribed locally, then passed into a downstream workflow.

01
Input, task & context
A request or transcript enters the workflow.
02
Agent orchestration & custom tooling
Task decomposition · Context management · Agent coordination

CodexClaude CodeOpenCodeOpenClaw

Tool use & integrationsMCP · REST APIs · Webhooks
03
Model selection & routing
Match the task to a model, a reasoning depth, and an allowed endpoint.

LiteLLMLocal / hosted endpoints
↙ Local inferenceOllama
Open-weight models on local hardware
Within the local inference boundary

↘ Hosted inferenceModel APIs
OpenAI, Anthropic, DeepSeek, and others
Crosses an external service boundary
04
Validation & fallback paths
Check the result against the task. Revisit context, tools, or model selection when needed.
↓ Result to downstream workflow

A conceptual view of how work flows through agents and models in my lab, not a single production AI application. A routing layer connects options; it does not erase their boundaries.

Path 01 / Local inference

Keep inference
on local infrastructure.

Ollama runs open-weight models on local hardware. The system still needs task decomposition, context management, tool permissions, and validation.

Data & trust: Inference stays local. Tool calls need their own boundary review.
Cost: Local compute and model capacity.
Operations: Local endpoints, resources, and model availability.

Path 02 / Hosted inference

Cross the boundary
deliberately.

A LiteLLM-based router connects agent workflows to hosted models from several providers, so the model can change without changing the workflow.

Data & trust: Selected context leaves the local inference environment.
Cost: Provider usage, model selection, and call budgets.
Operations: Service availability, API behavior, and fallback choices.

Path 03 / Audio into the workflow

Start with audio.
Route the transcript.

Whisper turns audio into text on local infrastructure. That transcript becomes input and context for downstream agent, tooling, or business-process workflows.

Data & trust: Local transcription does not make every later step local.
Next decision: Choose the model, tools, and context the task requires.
Validation: Check transcription and downstream results against the task.

The boundary is part of the design. Local inference and hosted services have different data, security, cost, and operational boundaries. The model is one component; orchestration, context, tool access, routing, validation, and fallback paths determine how the wider system behaves.

03 / Client work · 2024–Present

Modernize the process,
not just the toolset.

For an established, multi-decade field-services business, I rebuilt commercial operations around connected systems: inbound lead capture and CRM routing, automated pricing, programmatic invoicing, and customer payments.

The work also covered custom email domains, API-driven customer communications, and targeted digital marketing.

Scope: implemented client work; no outcome metrics published

Field services / Connected operating flow

Capture & route the enquiry
Inbound lead pipelines and custom CRM routing.
Price & communicate
Dynamic automated pricing and API-driven customer communications.
Invoice & collect payment
Programmatic invoicing and online customer payments.

A simplified view of the business functions connected by this work. Client identity, operational details, and credentials remain private.

What changed, and what is documented

A legacy business gained connected workflows across acquisition, pricing, invoicing, and payment. The documented evidence is the implementation scope; no time-saved, conversion, or revenue metric is claimed here.

The connection to enterprise work

Better questions.
Earlier in the evaluation.

When a security team asks how a vendor handles credentials, rollback, or data leaving its boundary, I have had to answer those questions for systems I run. That doesn’t make me the vendor’s engineer. It makes me a seller who can keep pace with one, and who knows when to bring one in.

Explore the commercial evidence

Start a conversation

Selling AI or infrastructure
to technical buyers?

Let’s talk

Three systems.Each one running.

An operational control plane

A backup and recovery program

Directing AI agents inside a harness

Choose the modelfor the task, not the vendor.

Model roles in a multi-model workflow

Follow the task. See the boundary.

Modernize the process,not just the toolset.

Better questions.Earlier in the evaluation.

Selling AI or infrastructureto technical buyers?

Three systems.
Each one running.

Choose the model
for the task, not the vendor.

Modernize the process,
not just the toolset.

Better questions.
Earlier in the evaluation.

Selling AI or infrastructure
to technical buyers?