Agentic Systems
Autonomous and human-supervised systems that plan, use tools, coordinate specialised agents and execute complex workflows.
- Planning
- Tool Use
- Memory
- Orchestration
- Guardrails
Applied AIAgentic SystemsEdge Intelligence
Intelligence, engineered for the real world.
We build the parts of an AI system that have to keep working when the model is wrong — evaluation, permission boundaries, fallbacks, and deployment into cloud, edge or air-gapped environments.
01 / Positioning
From models to working systems.
A model is only one component of an intelligent product. We design the reasoning, orchestration, data, evaluation and deployment layers required to make AI useful in production.
Most AI work fails at the seams — where a probabilistic component meets a deterministic system, a permission boundary, a latency budget or an operator who needs to understand what just happened.
Reference architectureScroll to trace one request through the system
- 01InputRequests, documents, sensor streams, events and system state arriving from the real world.
- 02PerceptionExtraction and grounding — turning raw signal into typed, referenceable representations.
- 03ReasoningPlanning, decomposition, constraint checking and selection of the next viable action.
- 04ToolsBounded access to retrieval, calculation, internal services and systems of record.
- 05ActionEffects committed to real systems, inside permissions, with an auditable trail.
- 06EvaluationAutomated and human review against task-specific criteria and known failure modes.
- 07LearningFindings routed back into prompts, policies, retrieval, datasets and model choice.
02 / Products
Products we build and run.
Alongside client engineering, VGM Labs builds and operates its own products — the same layers described on this page, applied end to end and maintained in production.
Every entry states its status, and only what is live is linked.
- Live
LawSpeak
LegalLegal research, drafting and document work in one workspace — case law and statute alongside a practice’s own files.
Built onwww.lawspeak.ai- Retrieval over legal corpora
- Document intelligence
- Speech transcription
- Machine translation
- In development
Hospital Management System
HealthcareAn intelligent hospital management system, currently in development — clinical and administrative workflow in one system, with AI applied where judgement is actually required.
Built on- Document intelligence
- Workflow automation
- Knowledge systems
03 / Capabilities
What we build
Edge Intelligence
Optimised AI systems designed to operate locally with lower latency, stronger privacy and reduced dependence on continuous cloud connectivity.
- On-device Inference
- Quantisation
- Small Models
- Offline Operation
Neuro-Symbolic AI
Systems that combine learned representations with explicit rules, constraints, search and structured reasoning.
- Reasoning
- Constraints
- Search
- Verification
- Knowledge Graphs
Generative and Multimodal AI
Applications that understand and generate information across text, images, documents, audio and structured enterprise data.
- LLMs
- Vision
- Documents
- RAG
- Multimodal Pipelines
04 / Index
Capability index
Eighteen areas of engineering. Each entry states the work, the disciplines it draws on, and what the resulting system can do — not a performance promise.
End-to-end delivery of software whose core behaviour depends on a model: interface, state handling, orchestration, persistence and the deterministic logic surrounding the probabilistic parts.
Disciplines
- Product architecture
- TypeScript / Python services
- Interface design
- State machines
System outcome
A deployable application, not a notebook or a demo endpoint.
Decomposition of a workflow into specialised agents with defined responsibilities, message contracts, shared state and an arbitration strategy for conflicting outputs.
Disciplines
- Distributed systems
- Planning
- Message contracts
- Concurrency control
System outcome
Work that exceeds a single context window is split, coordinated and recombined.
Retrieval pipelines over internal corpora: chunking strategy, hybrid lexical and dense retrieval, reranking, citation enforcement and permission-aware filtering at query time.
Disciplines
- Information retrieval
- Vector and lexical search
- Access control
- Evaluation
System outcome
Answers traceable to a source document the user is permitted to read.
Explicit representation of entities, relationships and rules so a system can answer questions that require structure rather than similarity.
Disciplines
- Knowledge graphs
- Ontology design
- Entity resolution
- Graph query
System outcome
Multi-hop and constraint-bound questions become answerable and inspectable.
Detection, classification, segmentation and tracking pipelines, including the calibration and pre-processing work that determines whether a model behaves in situ.
Disciplines
- Detection and segmentation
- Video pipelines
- Dataset curation
- Edge deployment
System outcome
Visual signal becomes structured events other systems can act on.
Layout-aware parsing, table and field extraction, classification and validation across scanned and digital documents, with confidence routing to human review.
Disciplines
- OCR and layout analysis
- Structured extraction
- Schema validation
- Human-in-the-loop
System outcome
Unstructured documents become typed records with a review path for low-confidence cases.
Dataset construction, parameter-efficient adaptation and held-out evaluation, applied when prompting and retrieval have been shown to be insufficient.
Disciplines
- Dataset design
- LoRA / adapters
- Preference tuning
- Held-out evaluation
System outcome
A model adapted to a domain, with the evidence to show adaptation was warranted.
Quantisation, distillation, pruning, batching strategy and runtime selection to fit a model inside a target latency, memory and power envelope.
Disciplines
- Quantisation
- Distillation
- Kernel and runtime selection
- Profiling
System outcome
A model that fits the hardware actually available, with quality changes measured.
Task-specific evaluation sets, scoring rubrics, adversarial and regression suites, and the harness that runs them on every change to prompts, retrieval or models.
Disciplines
- Test design
- Rubric and judge design
- Statistical comparison
- Regression harnesses
System outcome
Changes can be compared against a baseline instead of argued about.
Structured tracing of prompts, retrieved context, tool calls, token spend and latency, joined to outcomes so production behaviour can be reconstructed after the fact.
Disciplines
- Distributed tracing
- Structured logging
- Cost attribution
- Drift monitoring
System outcome
Any individual system response can be explained from recorded evidence.
Versioning for prompts, datasets, models and configuration; reproducible builds; staged rollout; and rollback that does not require a redeploy of the application.
Disciplines
- CI/CD
- Artefact and prompt versioning
- Feature flags
- Reproducible environments
System outcome
Model and prompt changes ship on the same disciplined path as code.
Threat modelling for model-driven systems: prompt injection, tool-permission escalation, data exfiltration through context, and secrets exposure in traces.
Disciplines
- Threat modelling
- Input and output mediation
- Least-privilege tooling
- Audit logging
System outcome
Autonomous components operate inside boundaries that are enforced, not assumed.
Model serving inside customer-controlled infrastructure — capacity planning, GPU scheduling, storage layout and upgrade procedure for an environment we do not administer.
Disciplines
- Containerised serving
- GPU scheduling
- Capacity planning
- Operational runbooks
System outcome
Inference runs where the data already lives, under the operator’s own controls.
Systems designed to function with no outbound network path: offline model and dependency distribution, deterministic builds, and an update process that survives isolation.
Disciplines
- Offline packaging
- Supply-chain verification
- Local vector stores
- Isolated evaluation
System outcome
Full functionality with no external dependency at run time.
Deployment to constrained targets — embedded accelerators, industrial gateways, mobile and browser runtimes — including thermal, memory and power behaviour under sustained load.
Disciplines
- On-device runtimes
- Small language models
- Memory budgeting
- Thermal profiling
System outcome
Local inference that degrades predictably instead of failing when connectivity drops.
Automation of multi-step operational processes where some steps require judgement: routing, escalation, approvals, retries and compensating actions.
Disciplines
- Process modelling
- Durable execution
- Exception handling
- Approval flows
System outcome
A process that completes reliably and escalates cleanly when it should not proceed.
Ingestion, normalisation, deduplication, incremental sync and lineage for the corpora and event streams an intelligent system depends on.
Disciplines
- Batch and streaming ingestion
- Schema evolution
- Lineage
- Data quality checks
System outcome
The system reasons over current, deduplicated, attributable data.
Connecting intelligent components to the systems that already run the business — identity, records, messaging and internal services — with typed contracts and explicit failure semantics.
Disciplines
- API design
- Identity and SSO
- Idempotency
- Contract testing
System outcome
Intelligence operates inside existing systems rather than beside them.
05 / Approach
Research depth. Production discipline.
The distance between a working prototype and a system an organisation can depend on is mostly engineering. We treat that distance as the substance of the work rather than an afterthought.
- 01
Understand
Define the problem, operating environment, data and success criteria.
- 02
Prototype
Validate the highest-risk assumptions using focused technical experiments.
- 03
Engineer
Build the complete application, orchestration, evaluation and integration layers.
- 04
Deploy
Optimise the system for its actual cloud, edge, on-premises or air-gapped environment.
- 05
Improve
Measure behaviour, evaluate failure modes and continuously refine the system.
06 / Deployment
Intelligence, where it needs to run.
Architecture should follow the operational environment — not force the environment to follow the model.
These are the environments we design for, and the constraints each one imposes. Where a verified engagement exists it will be documented as a case study.
One architecture, five destinations
CloudOperating characteristics
- Latency
- Network round trip dominates; typically hundreds of milliseconds per model call.
- Privacy posture
- Governed by provider terms, region selection and data-processing agreements.
- Connectivity
- Continuous connectivity assumed.
- Compute
- Elastic. Accelerator capacity is a commercial question rather than a physical one.
- Model size
- Largest available models, including frontier tiers.
- Reliability
- Depends on provider availability; needs fallbacks for rate limits and deprecation.
- Observability
- Rich tracing available, though model internals stay opaque.
07 / Research
Building beyond the current default.
We explore architectures that make intelligent systems more capable, efficient, verifiable and deployable.
These are the questions we are working on. Anything we publish about them will carry the method and the evidence behind it.
- R-01Agentic AI
Long-horizon agentic reasoning
How does a system maintain a coherent objective across dozens of dependent steps without accumulating error?
- R-02Neuro-symbolic AI
Neuro-symbolic problem solving
Where is the right boundary between a learned model and an explicit solver for a given class of problem?
- R-03Efficient Inference
Efficient model inference
What is the cheapest configuration that still meets a task’s quality bar on the target hardware?
08 / Company
An AI lab with a product mindset.
VGM Labs is an applied-AI company focused on turning advanced research and emerging AI architectures into dependable software systems.
We work at the intersection of models, software engineering, system design and real-world operational constraints.
How we work
- Evidence over demonstration
- A system is only understood once its failure modes are written down and measured. Evaluation is designed alongside the feature, not retrofitted after launch.
- Constraints first
- Latency budget, privacy posture, connectivity and available compute are treated as design inputs. Architecture follows the operating environment.
Client engagements stay confidential. Work appears here as a case study only when the client has approved it and the results have been verified.
Next
What should intelligence do next?
Bring us the workflow, decision or technical constraint that conventional software cannot solve.