By Z. Aw | Published 21 Apr 2026 | Updated 14 Aug 2026

What is Lyra?

Lyra is the CRM + ERP I built for Altronis. I use it every day to run the business - contacts, companies, proposals, invoices, contracts, projects, expenses, meeting prep, a unified communications inbox, and a quality dashboard. Nothing unusual about the list. What is unusual is the design principle: Lyra is built to be driven by AI agents, not clicked by humans.

What that actually means

Most CRMs assume a human opens the page, fills the form, presses save. Lyra assumes an agent read an email, decided what to write, and is now posting the update through an API - and that a human will check the diff later. Every mutation writes an audit log row with the agent id, the reason, and the before/after values. Every write path has a confirm-gate when it touches money. Every aggregator query reads the source object's own state, not a denormalised display field.

A practical example: when a new email arrives from a known contact, Lyra auto-drafts a reply in the Communications tab with the original thread quoted and the right people CC'd. I approve it with one click and Lyra pushes a composable draft straight to my Outlook Drafts folder - ready to edit and send. The whole loop runs without me touching a keyboard until the final approval.

What is actually in the box

• Backend. Python + FastAPI on SQLite in WAL mode. We ran a cloud database for the first two months, then decommissioned it: one local file, snapshotted hourly, is simpler to reason about, trivially portable, and never leaves the machine.
• Frontend. React + Vite with an Apple-dark design system. Every page is agent-inspectable and human-readable.
• Connectors. Outlook (IMAP + OAuth2), Gmail, Microsoft Graph for calendar, LinkedIn (deep-link composer), Himalaya for direct IMAP draft push with the correct flags so Outlook treats remote-created drafts as send-able.
• Agents. Five role agents (chief, sales, delivery, finance, governance), each with a strict tool allow-list, so the finance agent physically cannot push a sales draft. Mutations queue behind a confirm gate; money moves need a typed confirmation. The model chain falls through local models on a Strix Halo mini PC, zai GLM-5.3, and NVIDIA NIM. The agent does the writing; Lyra does the bookkeeping.
• Ops surface. Systemd timers for the pull loop, the daily briefing, the T-24h meeting prep, retainer auto-invoicing, and a quality watchdog. Nothing runs in a queue that a human cannot see.

The agent remembers, on a schedule

Since June, Lyra maintains its own memory. Exact facts (figures, invoices, the live business plan) are never retrieved from an index: the agent reads them from the database at answer time through typed tools, so they cannot go stale. Fuzzy recall runs on a hybrid keyword + vector store with recency-weighted scoring: a changelog entry ages in weeks, a reference document in a year, and an old exact match can lose at most half its score. A nightly job feeds the knowledge base every project document, the business plan, and the last 48 hours of git commits, then compresses old daily changelogs into monthly summaries written by the local model. Ask Lyra what shipped this week and it answers from its own commit history.

Why self-hosted, not SaaS

I do not want to hold your customer list. That is the honest answer. CRM data is sensitive - contacts, pricing, pipeline, margins. Hosting that for other companies would turn Altronis into a trust business before it is a product business, and the first breach would end the company.

Lyra runs on our own hardware: a mini PC on a shelf serves the backend, the database, the models, and the nightly jobs, and the phone app installs straight from the browser over a private network. That is the same private, on-prem pattern Altronis installs for clients: your data lives in your building, in a database you can copy with one file, behind your own network. Nothing about it requires our cloud, or anyone's.

What it has taught me

Agents need audit trails more than features.The hardest production incidents are not agents failing; they are agents succeeding in ways the operator did not expect. A paid-flip on an invoice nobody approved. A contact stage that stayed at "won" even after the proposal was rejected. A forecast reading the wrong field and producing zero. Every one of these happened to me in the last month. Every one was caught because every write path logs who did it and why.

Object models drift fast when agents are writing to them. Human users keep fields roughly consistent because they see the form. Agents do not. You need validators that reject inconsistent states, not Excel-style acceptance. I shipped seventeen "object-model sync" fixes in a single session because I let agents write freely for a week and then audited what they actually persisted.

Your autopilot is only as good as its commit discipline. Agents that implement a task but forget to commit do not count. I now run my autopilot with a salvage heuristic that auto-commits abandoned work and a hardened prompt that makes commit step one, not step eight. It matters more than the model choice.

How this connects to Altronis

When a client asks me to build an AI-driven ops system, I am reasoning from the one I run on myself. The pattern - narrow role agents, audit trail on every mutation, aggregators that read source-of-truth fields, one-click deploy to the client's own tenant - is the same whether it is a CRM or an invoice OCR pipeline or a proposal generator.

If you are figuring out how to bring agentic AI into your own back office without turning over your customer data to a third-party SaaS, Lyra is the reference architecture. Licensed to run in your tenant, audited from the outside, upgraded on your schedule.

Last updated 10 June 2026.