Local AI engineering capabilities.

Yes. All three of our local-AI products run on llama.cpp against GGUF model files: Orchestrator Studio's on-prem inference (Gemma-4-E4B for text, Qwen2.5-VL-7B for vision), Vexilo's 27B-class Excel specialist, and CrestBid AI's local drafting model. Each product also accepts an OpenAI-compatible or Anthropic endpoint if you'd rather point at a model you already run elsewhere — an OpenAI-compatible API is part of what llama.cpp gives us, so that swap doesn't change the product itself. We measure what we ship rather than repeat a model card's numbers: tokens per second on the actual target host (19.5 vs 9.0 tok/s on the same host in our research, a 2.2x gain), latency per document (2–5 seconds per document on an 8 GB laptop GPU for Orchestrator Studio), and a silent-error rate, which our research cut from 36% to 4% on our internal benchmark.

Sizing starts with the model's parameter count at the precision you plan to run it at — from full F16 down to a quantised format like Q4_K_M — plus the KV cache the context window needs, plus headroom for whatever else runs on the same host. In our own research sweep, Q4_K_M showed no measurable quality loss against full F16, which is why it's our default rather than a compromise. For the 27B-class model behind CrestBid AI's bid drafting, we recommend 48 GB of VRAM or unified memory for real headroom; below 24 GB, no configuration of that model fits at all. Four hardware classes cover most of what we size for: an 8 GB laptop GPU, where Orchestrator Studio runs comfortably (its reference machine is an RTX 4060); 24 GB, the floor for CrestBid AI's model to fit at all; 48 GB of VRAM or unified memory — an RTX A6000, an L40S, or a Mac Studio — which we recommend across products for real accuracy and performance; and 128 GB of unified memory on a private AI server such as an NVIDIA DGX Spark or an ASUS Ascent GX10, for dedicated on-prem capacity.

CrestBid AI's retrieval is graph plus vector, over your own document library, and never leaves your infrastructure; every drafted answer carries a citation back to the specific source claim it came from, including images ingested through a local vision model. Its cognitive flywheel only learns from answers a human has approved — it never fine-tunes on customer data, and nothing crosses between organisations. PostgreSQL with pgvector is part of the stack we build retrieval on in our delivery work more broadly.

We build orchestration into the products themselves rather than adopt a generic agent framework. Orchestrator Studio runs configurable pipelines — ingest, classify, extract, validate, route, act — with human review gates at the points that matter, 19 connectors (Outlook, Gmail, ServiceNow, SharePoint, SAP, Salesforce, Snowflake, and more), and built-in robots for browser and SAP GUI automation. Vexilo's Excel specialist runs a 19-tool loop with hard bounds: additive by default, it asks before anything destructive, and a single undo reverts a whole reply. Our LLM Engineering & Evaluation work builds on DSPy for the fine-tuning and evaluation loop behind it. Plainly: we have not shipped LangGraph or AutoGen in production; we build on DSPy and our own orchestration runtime, with deterministic validation — rules, lookups, reconciliation with tolerances — and a human-in-the-loop gate around what the model itself produces, since the model's own output is never treated as deterministic.

It's the architecture behind our Verification-Anchored Federation (VAF) research: a router sends each request to one of four LoRA specialists fine-tuned on a shared 1.2B-parameter backbone, a tiered verifier checks the output, and a conformal abstention gate holds anything it can't calibrate confidence for, at 95% coverage. We discard the model's own self-reported confidence entirely — calibration comes from the conformal prediction gate, not from asking the model how sure it is. That architecture is what took our silent-error rate from 36% down to 4% on our internal benchmark. A paper describing it, 'Verification-Anchored Federation: A Zero-Trust Harness for Reliable Local AI Deployment,' is in submission; we're not naming a venue until it's accepted.

Every LLM Engineering & Evaluation engagement gets its own evaluation harness, built around that specific use case rather than a generic public benchmark — measuring silent-error rate, abstention rate, and coverage. That's the same discipline our own research holds itself to, including when a result doesn't work: we tested a training-free approach to specialising a model without training it (a "context compiler"), it didn't hold up, and we published that finding rather than quietly dropping it. Abstention on solvable tasks currently sits at 24%, above the 15% target we're aiming for — we are driving that down without raising the silent-error rate back up, not claiming it is solved.