Avectes AI
Learn how work connects.
Explore what comes next.
Two research directions: NORA, learning from business workflows. MIRA, exploring specialist language models, beginning with software engineering.
01 / NORA
Give the model eyes
on the business.
NORA is planned as a model trained from scratch on business workflows, learning how work moves and where it gets held up.
Each module would give NORA another view: customer relationships, work, service delivery and commercial activity. Together, those observations could reveal where a workflow breaks down.
The Systemic Object Model, or SOM, connects records and events to their business context. That gives NORA related observations to learn from, with approved data kept in its organization’s scope.
NORA
Why did profit fall on this day?
Look across the business, then follow the related evidence.
- HostingSite unavailableAvailability observation
- SchedulingServices interruptedDelivery observation
- BookingsCancellations recordedBooking observation
- InvoicingRevenue lowerCommercial observation
- Related customer
- Related service
- Event time
Potential contributor
Could the outage have interrupted service delivery?
A possible connection to investigate alongside cancellations, revenue and costs.
A lower-profit day is a question to investigate.
An outage in one part of the business can leave clues elsewhere. The aim is to trace related service, booking and commercial records so people can examine a possible contributor, rather than search each module separately.
02 / MIRA · RESEARCH
Specialized intelligence.
One shared foundation.
MIRA explores focused specialists built on an open-weight language model. We would begin small: one Rust and Avectes engineering specialist worth building.
Start with useful engineering work.
The first experiment would fine-tune a suitable base on our GPUs, combining learned engineering patterns with retrieved, current repository context, tools and compiler feedback. Held-out tasks, tests and AvSuite evaluation would establish whether adaptation helps.
If that specialist proves useful, other domains could follow. A shared foundation could then serve separately versioned adapters, with an external Expert Router choosing a specialist for each bounded task or subtask.
Proposed architecture · request flow
“Investigate this failing Rust test.”
One bounded task, with retrieved context and tools.
External task / subtask routing
Low confidence → fallback or review
Separately versioned checkpoints
First specialist to evaluate
Future specialization
Future specialization
Selected compatible low-rank weights
Exact base + revision compatibility
Shared base + selected adapter
Bounded memory · request isolation
Findings · evidence · uncertainty
Check conflicts and evidence. Choose the next bounded task for the Expert Router.
Learning a specialty. Serving a request.
LoRA trains small, low-rank updates while keeping the foundation’s weights frozen. QLoRA trains adapters through a frozen, four-bit quantized base to reduce training memory needs. Serving those adapters is a separate engineering problem.
The serving study asks a separate question: how could compatible specialists share one resident base, while keeping each request’s adapter, evidence and resource use explicit?
Bring only the needed adapters closer.
A proposed path from storage to active memory.
- Cold adapter bankS3 or local SSD / NVMe
- CPU RAMStaged adapter weights
- GPU VRAMActive adapter working set
The shared base stays resident. Adapter weights and KV cache share bounded memory budgets. Optional prefetch, eviction and backpressure manage demand; each adapter is an update, not another base model.
Four different ways to serve specialists.
Selection, replacement, movement and concurrent execution solve different problems.
- 01 / Resident selection
- Request + adapter IDAlready-resident weights
Choose an available adapter for this request without reloading the shared base. Concurrent requests need request-specific selection, not a global mutable set_adapter switch.
- 02 / Compatible hotswap
- Prepared slot: adapter ASame slot: adapter B
Replace compatible weights in one prepared slot. Tensor transfer still takes work; target layers and rank capacity must fit the slot and engine.
- 03 / Paging and prefetch
- Cold or staged weightsGPU working set
Stage weights before or when needed, managing transfer time, queues, cache misses and eviction within memory budgets.
- 04 / Heterogeneous batching
- Requests A + BOne shared-base batch
Serve different requests with their own adapters concurrently over the same base. This needs an engine that supports multi-adapter batching, rather than serial replacement of one slot.
Compatibility, trust and evidence between specialists
A precise model and adapter contract
Check the exact foundation model and revision, architecture, tokenizer, target layers, ranks and scaling. A compatible in-place hotswap requires the same target layers or a supported subset and may require preparing sufficient rank capacity before compilation.
Approved loading and isolated state
Use approved, versioned checkpoints and manifests with provenance, checksum, compatibility, regression and rollback checks. Loading belongs to a trusted control plane, never arbitrary public adapter paths or URLs. Cache identity must include the base, adapter, task and isolation scope.
A council passes evidence between invocations
An external Expert Router would classify tasks and subtasks, with a low-confidence fallback. It is distinct from internal token or layer routing such as MoE or MoLE. A proposed Council of Experts would pass versioned findings, evidence, limitations and uncertainty between bounded invocations, preserving disagreements.
Rust, security and operations would be separate calls. Reusing prior KV state requires validation or recomputation.
What would earn the next experiment?
Quality before a larger council
Compare the specialist with the shared base and other adapters on held-out domain tasks, compiler and test proofs, AvSuite evaluation, routing failures and cross-domain regressions. Retrieved context keeps changing code, APIs and customer facts outside the model’s weights.
Measure serving behavior on the chosen system
Collect cold and warm load, slot-swap, queue, time-to-first-token, throughput and end-to-end latency measurements. Track CPU, GPU and KV memory, cache hits, prefetch, evictions and mixed workloads.
Research and implementation references
Adaptation: LoRA and QLoRA. Shared-base serving studies: S-LoRA and Punica.
Serving and adapter APIs: LoRAX (historical), vLLM multi-LoRA and its prefix-cache design, plus PEFT hotswap and loaded-adapter management. LoRAX was archived in October 2026; it is a historical adapter-exchange reference.
Adjacent internal expert research: MoLE and OD-MoE. These study routing within a model, distinct from MIRA’s proposed external task router.
03 / RESEARCH PLAN
Earn the next step.
For MIRA, each stage depends on what the previous experiment can demonstrate.
- 01
Rust engineering first
Select a suitable open-weight base and evaluate a small Rust/Avectes specialist with retrieval, tools, compiler feedback and held-out AvSuite tasks. Base, model size and training remain open.
- 02
More domains, if it works
Explore additional specializations only if the first experiment succeeds and a concrete domain need justifies the work.
- 03
Council of Experts, if justified
If several specialists prove useful, study shared-base serving and a Council of Experts. The council would compare evidence, preserve conflicts and choose another bounded task; routing and serving need their own qualification.