Agentic AI Development and LLM Systems
Multi-agent systems, retrieval pipelines and self-hosted inference, built to run in production rather than in a demo.
Context
There is a workflow eating staff hours that looks like it should be automatable, and probably is. What blocks it is almost never the model, which is the part of agentic AI development everyone expects to be hard. It is that the pilot which demoed well cannot be trusted with real data, that the inference bill scales with usage in a way nobody modeled, that the information the agent needs is spread across a project management system, a shared drive and four years of photographs, or that the data is not allowed to leave the building at all. The engineering that fixes those is unglamorous: a retrieval layer that returns the right rows, agents in isolated containers with credentials scoped to exactly what they need, local models carrying the work that does not need a frontier model, and an audit trail showing what the system did and what it cost.
Scope
What this covers
- 01Agentic AI development on a custom multi-agent framework built from the open-source OpenClaw project: per-agent configuration, multi-agent gateways, lossless context compaction, cron scheduling, a plugin architecture and a proxy backend.
- 02Isolated-container agent deployment: each agent provisioned in its own LXC container with scoped access to infrastructure, so the blast radius of a mistake is the container rather than the estate.
- 03Least-privilege agent-to-agent handoff, including scoped sub-agents that hold restricted SSH access and a deploy key for one repository and nothing else.
- 04Hybrid retrieval pipelines on PostgreSQL: pgvector with halfvec HNSW indexes, trigram text search and PostGIS, combined rather than chosen between.
- 05Media understanding pipelines: structured description, transcript and visual-detail extraction from images and video, embedded and indexed for semantic search.
- 06Self-hosted inference: LM Studio, Ollama, and a LiteLLM gateway on Docker Compose with PostgreSQL providing unified routing across hosted and local models for a whole agent fleet.
- 07A GPU serialization proxy that arbitrates a single shared GPU between services, with just-in-time model loading, VRAM cooldown management, priority lanes and cross-service queuing.
- 08Model routing for cost: latency-sensitive paths on hosted models, batch and background work on local models, with the split made explicitly instead of by default.
- 09Model Context Protocol server integration, agent skill and tool design, and prompt and context engineering as an engineering activity with tests behind it.
- 10Vision and language model benchmarking on the actual corpus a client owns, rather than on public benchmarks that do not resemble it.
- 11Observability for agentic AI development: token usage tracking, transcript auditing, and tooling that shows where an agent wasted effort or looped.
- 12Integration into the systems people already use: messaging surfaces with per-group agent routing, project management platforms, and databases with an immutable audit log.
- 13Compliance-driven builds, including platforms designed against IRS Publication 4557 requirements for safeguarding taxpayer data.
Record
Work behind this
Delivered work, stated as facts rather than claims. Programs and employers are named where naming them is what makes the record checkable. Clients are not.
Questions
Questions technical buyers ask
How is this different from the AI Integration page on this site?
That page is a productized version of this work: agents that live inside the messaging apps a field team already uses, built for construction and similar trades. See AI Integration for that. This page is the engineering underneath it, sold as contract work: the retrieval layer, the isolated container pattern, the self-hosted inference and the cost controls, built against whatever systems you already run.
Can this run entirely on infrastructure we control?
Yes, and for regulated or sensitive data that is the reason to build it this way at all. Local inference through LM Studio or Ollama behind a LiteLLM gateway, the vector store in your own PostgreSQL, the agents in containers on your own hypervisor. A hybrid split is also normal: sensitive retrieval stays local while a hosted model handles reasoning on redacted context. What matters is that the boundary is a design decision somebody wrote down.
How do you keep an agent from doing something it should not?
By construction rather than by instruction. Each agent runs in its own container with credentials scoped to the one system it needs, filesystem and SSH access limited to that scope, an immutable audit log of what it did, and a human approval step on anything irreversible. A prompt asking an agent to be careful is not a control. A credential it does not hold is.
What does a first engagement usually look like?
One workflow with a measurable before and after. Something that currently takes a named number of hours per week, where the output can be checked by the person who does it today. That produces a real number to judge, including running cost, rather than a demo that impresses in a meeting and never reaches production.
Start a technical conversation
Describe the system, the constraint and the deadline. An engineer answers.
Tools and platforms we work with: Model Context Protocol. LiteLLM and LM Studio. Ollama, WhisperX, and a custom GPU serialization proxy. PostgreSQL 15 and 16 with pgvector halfvec HNSW, pg_trgm and PostGIS. Self-hosted Supabase with connection pooling. Qwen3 and OpenAI embeddings. Python, Node.js and TypeScript. Docker Compose on Proxmox LXC.