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.
VGM Labs builds AI-first software and intelligent systems that reason, act and operate across cloud, edge and constrained 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 / 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
- Quantization
- 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
03 / 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.
Quantization, distillation, pruning, batching strategy and runtime selection to fit a model inside a target latency, memory and power envelope.
Disciplines
- Quantization
- 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.
04 / 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.
- Written problem statement with a measurable definition of success
- Operating envelope: latency, privacy, connectivity, compute
- Data inventory and access assessment
- Explicit list of what the system will not do
- 02
Prototype
Validate the highest-risk assumptions using focused technical experiments.
- Narrow experiments targeting the assumptions that would invalidate the design
- A first evaluation set drawn from real inputs
- Baseline results and a recommendation, including "do not build this"
- Architecture decision record with the options rejected
- 03
Engineer
Build the complete application, orchestration, evaluation and integration layers.
- Production application with the deterministic logic around the model
- Orchestration, permissions, guardrails and failure handling
- Evaluation suite wired into continuous integration
- Integrations against identity and systems of record
- 04
Deploy
Optimise the system for its actual cloud, edge, on-premises or air-gapped environment.
- Environment-specific build, with model optimisation where required
- Observability: tracing, cost attribution, quality signals
- Staged rollout plan and tested rollback procedure
- Operational runbook and handover documentation
- 05
Improve
Measure behaviour, evaluate failure modes and continuously refine the system.
- Review of live behaviour against the original success criteria
- Incidents and edge cases folded into the regression suite
- Prioritised changes to prompts, retrieval, models or policy
- Verified improvements shipped on the same path as code
05 / 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.
06 / Research
Building beyond the current default.
We explore architectures that make intelligent systems more capable, efficient, verifiable and deployable.
Open questions, not published results. Write-ups appear here once they exist and their claims have been checked.
- R-01Agentic AI
Long-horizon agentic reasoning
How does a system maintain a coherent objective across dozens of dependent steps without accumulating error?
Interest here is in externalised plan state, checkpointing, and mechanisms that let a system detect that its current approach has stopped working and revise it rather than repeating it.
- 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?
Practical interest in using models to interpret and formalise a problem, and deterministic search or constraint solving to answer it — so that the answer is checkable rather than merely persuasive.
- R-03Efficient Inference
Efficient model inference
What is the cheapest configuration that still meets a task’s quality bar on the target hardware?
Quantization and distillation trade quality for footprint unevenly across task types. The question is which capabilities degrade first, and how to detect that on a task-specific evaluation set rather than a general benchmark.
- R-04Agentic AI
Tool-using language models
How should tools be described, scoped and validated so that correct selection is the default rather than the exception?
Interest in schema design, argument validation, and error messages written for a model reader — treating the tool interface as an ergonomics problem rather than an API afterthought.
- R-05Evaluation
Evaluation of autonomous systems
How do you evaluate a process rather than a single output, when the same objective admits many valid trajectories?
Attention on trajectory-level scoring, partial credit, cost-aware metrics, and the reliability of model-based judges compared with human review on the same set.
- R-06Multimodal Systems
Multimodal understanding
How is grounding maintained when evidence for one answer is split across a document’s layout, an image and a database record?
Interest in cross-modal citation, resolving conflicts between sources of different reliability, and preserving spatial structure through extraction.
- R-07Edge AI
Small and specialised models
Which production steps are better served by a small task-specific model than a general one?
Classification, extraction, routing and reranking are often high-volume and narrow. The question is where a compact model matches a large one on the task while fitting a constrained target.
- R-08Neuro-symbolic AI
Reliable structured generation
How is output made schema-valid and semantically correct, not merely parseable?
Constrained decoding solves syntax. The open part is semantic validity — referential integrity, unit consistency, and satisfaction of domain constraints — and where that check belongs in the pipeline.
07 / Work
Selected work.
Selected work currently being documented.
Rather than publish approximations, this section stays empty until each build can be described accurately — what it does, what it establishes technically, and where it runs. Areas currently being written up:
- 01Multi-agent workflow prototypeAgentic orchestrationIn documentation
- 02Edge inference demonstrationOn-device inferenceIn documentation
- 03Neuro-symbolic reasoning experimentConstrained reasoningIn documentation
- 04Document intelligence systemStructured extractionIn documentation
Client engagements appear only as verified case studies, with the client’s approval.
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.
- Explicit boundaries
- Autonomous components run inside defined permissions, with auditable actions and a human intervention path. Capability is bounded on purpose.
- Handover as a deliverable
- Documentation, evaluation datasets and operational runbooks ship with the system. A system another team cannot operate is unfinished.
Next
What should intelligence do next?
Bring us the workflow, decision or technical constraint that conventional software cannot solve.