AEGIS v1 is archived. Here is what replaces it

I've shut down AEGIS v1 and archived github.com/hikmahtech/aegis. The code stays public and MIT-licensed. You can still read it, fork it and learn from it. It just won't get fixes, releases or answers to issues any more.

AEGIS itself isn't going away. It is being rebuilt as version 2, and version 2 is not open source. This post explains why, what v2 looks like, and what is already running on it.

What v1 was

AEGIS v1 was one system that did everything for one person: my tasks, email, money, research, and the alerts from the machines in my house. Three services shared one Postgres database. A Temporal worker ran every workflow on one task queue. A handful of named agents each owned a slice of the work, and every time one needed me, it asked through the same approval card.

I open-sourced it in July, and the ideas in it held up. One primitive for every interruption. Durable workflows that survive a weekend of waiting for my tap. Local models first. An audit line for everything that matters. None of that is changing.

What went wrong with one system

The shape was the problem, not the ideas.

• One deploy for everything. A fix to bank-statement parsing redeployed the code that restarts services in my homelab. Every change carried the risk of every other area.
• One database for everything. The accounting tables and the alert tables lived side by side. Nothing stopped one area from reading or writing another's rows, so over time some did.
• Nothing could leave. If someone wanted just the bookkeeping part, there was no way to give it to them. It came with my task manager, my research feeds and my infrastructure agent attached.

The last one matters most. The bookkeeping lane is useful to people who aren't me. To hand it to anyone, it has to stand on its own.

What v2 is

Version 2 splits AEGIS into separate products. I call each one a vertical. Each has its own database, its own worker and API, its own UI and its own deployment. Each customer gets their own deployment too, starting with me as customer zero.

They share code, not state:

• An SDK for everything the verticals have in common: worker and API bootstrap, connectors with fakes for testing, an encrypted credential vault, model routing with a daily token budget, approval cards, settings and migrations.
• A UI kit of shared React components, so every product's inbox and settings page look and behave the same.
• Two running services: the Temporal cluster and the LiteLLM proxy. Nothing else is shared at runtime.

Verticals talk to each other only over HTTP, through a token-gated route with a written contract. No vertical imports another's code or reads another's database. That rule is what lets one of them ship to a customer alone.

What is running on it

Books went live on 6 October 2026. It takes bank statements, card alerts and SMS in, reconciles them, and posts the result to a plain-text hledger journal. Anything it is unsure of becomes an approval card, and my answer becomes a rule, so it asks less over time. It writes my real books now, and v1's money lane is switched off.

DevOps went live on 8 October 2026. It took over the homelab alert intake and investigations that v1's infrastructure agent used to do. It ran in shadow beside v1, with every write switched off, until the cutover. Now it is the only thing that receives my alerts. Apart from one automatic restart per problem per hour, every restart, scale or rollback waits for my approval.

Assistant, research and development each have a first milestone live. The rest of v1's areas each have a planned home.

How a lane moves without breaking

Books tried every operating pattern first. Three of them are worth stealing for any rewrite of a live system:

1. Shadow, then cut over. Books wrote to a separate journal branch while v1 kept writing the real one. I diffed the two until every difference had an explanation. Then, on one day, v1's lane went off and Books took over the real journal.
2. The old system is the oracle. The statement parsers were ported as-is and must produce the same row ids v1 does. A parity script compares the two databases, read-only on both sides, against a pinned v1 commit.
3. One writer for the system of record. Every write to the journal goes through one function, gated on a watermark that only moves when a statement is reconciled. Nothing else can write a block.

v1 lost one lane at each cutover. On 8 October 2026, with Books and DevOps live, I shut it down. Areas that have no v2 product yet are paused until theirs is built.

Why v2 isn't open source

v2 is built to be sold, product by product, so its code is private.

The patterns aren't secret. They are all in v1, which stays readable, and I'll keep writing about them here: what moved, what broke, and what the split cost. If you forked v1, your fork is yours. It just won't get anything new from me.

What happens to the repo

• It is archived on GitHub: read-only, MIT-licensed, nothing deleted.
• The v0.1.0 release is the clean first public version. The main branch shows v1 shrinking as lanes moved to v2.
• Older posts on this blog link the repo. Those links keep working, and each post now says the code is archived.
• The AEGIS page and how it works still describe v1 in full, because that is the code you can read.

If one of the v2 products fits a problem you have, or you want the same pattern built on your own data, that is the work I do for clients. If you are deciding whether an AI workflow is safe to trust in production at all, start with the AI workflow teardown.