Platform · for developers and investors

A control plane for orchestrating neural models

agime.ai is not a chatbot. It is a custom system whose product is the logic of managing and dispatching external and local neural networks. One engine. Many surfaces. Built by an agent fleet, and orderable by agents.

Back to the product See the architecture

Thesis

One orchestration engine, adapted per case

Every product is the same control plane, pointed at a concrete job. Not a bundle of apps — routing, dispatch, and memory under one roof.

Products as adaptations of one engine
ProductThe same engine, adapted to…
LIZa private, per-person dispatcher of models with persistent memory — voice + text
AGIME Personal AIa provisioned, resold bot running our orchestration logic on third-party compute
Free chatorchestration across free provider tiers with a local-GPU floor
Billingmonetization of the orchestration, sold to others as a service
law.agime.aithe orchestration adapted to a legal-assistant vertical
Agent APIthe orchestration made programmable — agents order any of the above

The one-engine claim is falsifiable, which is the point. LIZ, the personal-AI fleet, the free chat and the billing rail are not five codebases in a trench coat; they are the same router, the same provider registry, the same memory layer, configured per case. When the engine gains a capability, every surface inherits it. When one surface finds a bug, every surface loses it. That leverage is how a company this small ships five products without lying about any of them.

The consumer pages never say any of this, on purpose. A person buying a private AI does not need the word “orchestration”; they need to know their words stay in their own unit and a human answers when something breaks. The sophisticated register lives here, and only here.

Architecture

Isolation by process, not by query

The expensive decision, made on purpose. It caps how many people we can serve per machine, and it is the reason “your own instance” is a fact rather than a slogan.

How one user maps to one isolated assistant Phone and browser clients reach the public portal, which authenticates the account in Postgres and binds it to one of ten LIZ units. Each unit is a separate process with its own SQLite database and its own vector-memory collection. All ten units share a GPU that runs the language model and speech recognition. Phone Android app · voice Browser web console · text Telegram your own bot Portal accounts · sessions trial · billing Postgres binds exactly 1 of 10 LIZ · unit 1 own process SQLite + vectors LIZ · unit 2 own process SQLite + vectors LIZ · unit 3 own process SQLite + vectors LIZ · unit 4 own process SQLite + vectors GPU qwen2.5 14B whisper v3-turbo Every link between the portal and a unit is mutual TLS. A unit holds one tenant’s data and nobody else’s. There is no shared row to leak. Capacity is enforced in the schema, not in a config file: unit_id must be 1–10.
Ten units is not a launch-day placeholder. It is what one machine holds when every tenant gets a real process, and raising it is a hardware decision.
Model
qwen2.5-abliterate:14b — dense, non-thinking, ~10 GB VRAM, held warm on our GPU. Chosen over a 30B mixture-of-experts that leaked its reasoning into replies. The fallback chain on the pilot fleet is local too, so a reply does not quietly leave the building.
Speech → text
whisper large-v3-turbo on CUDA, optional in place of the phone's own recogniser. 305–431 ms on 5.5–5.7 s utterances (p50 332, p95 431).
Memory
SQLite per tenant for the record, a vector collection per tenant for semantic recall. Both readable and editable from the console.
Transport
Mutual TLS from the portal to every unit; each unit listens on loopback and refuses an unsigned client.
Sessions
scrypt password hashes, httpOnly cookie sessions, single-use reset tokens, and every session revoked on a password change.
Orchestration core
Shared router in tactical-backend/lib/llm.js (tier / LIZ_ROUTER_MODEL, egress-guard). Free-routing chain and the provider/provision layer sit on the same dispatch path. Extraction into lib/orchestrator/ is the P47 lane.

The market position, stated plainly. A $20 subscription buys a seat in someone else’s shared cloud; a roughly $4,000 desktop box buys private weights plus a system-administration hobby. This architecture is the slot between them: structural privacy — a tenant’s data has no shared row to leak, by schema, not by policy — without buying the box, plus a human service layer on top. The moat is not model quality, and we never claim it is: a frontier model out-benchmarks a dense 14B every day of the week. The moat is that the dispatcher, the memory, and the accountability all belong to the user’s unit. Hard questions can be routed to bigger external models under the user’s own egress policy, while the life story stays on the private core. Privacy here is a property of the topology, not a promise in a settings page.

Built by agents

Shipped by an autonomous agent fleet

This platform is itself built and operated by agents. The products are orderable by agents through one API. That is the demonstrative story — not a slogan on the front door.

Concretely: this repository is worked by a fleet of coding agents under one orchestrator, with a human owner approving what ships. The same discipline the platform sells — bounded autonomy, checkable state, a person on the hook — is the discipline that builds it. Anyone evaluating the company should price the engine and the operating method together; the products above are proofs of the engine, not the asset itself.

Delivery Autonomous agent fleet
Release gate Human owner approval
Public web Checking…

Public source: /health.json

User-facing pages stay plain on purpose. This page is for the people who want the orchestration ideology. Everyone else should get a LIZ.