The orchestrator is deliberately stateless: it loads and saves state externally at each step, so a conversation can be resumed or moved between workers. Tools are discovered rather than hard-wired, and each is rate-limited independently. A question is decomposed into sub-questions that run in parallel where they do not depend on one another, which is what keeps a multi-source answer inside a usable response time. The critic agent exists because the failure mode that matters in analytics is not a crash but a confident wrong number. When the critic cannot support a figure from the retrieved evidence, the assistant says so rather than smoothing it over.

Training data is treated as a first-class artefact rather than a prompt: schema definitions, question-and-query pairs and documentation are ingested into a local vector store and versioned alongside the code. The model provider is swappable, which matters when the database is not allowed to be reached by a hosted model. Generated SQL is shown before it runs, and read-only credentials keep an unlucky generation from becoming an incident. The three front ends share one service, so a query answered in Slack and the same query in the web UI take the identical path. What made it useful in practice was less the generation than the training loop: every corrected query goes back into the store and the same question stops being wrong.

Requests are classified and routed to a specialist rather than handled by one general agent, and the database agent retries its own failed queries instead of surfacing them. A caching agent matches new questions against previous ones by similarity, which cuts both cost and latency on the questions people actually repeat. The security agent sits on both sides of the exchange, screening what goes to a model and what comes back, so a single component owns that concern instead of it being sprinkled through the others. Splitting the roles this explicitly made each one testable on its own, which is the part that carried over into the later version. Its limitation was the flip side of the same choice: the routing lived inside agent conversations, and when it went wrong there was no graph to look at.

Converting a book takes minutes on a GPU, so the interesting part is not the conversion but everything around it. The queue has to survive a restart without losing a job someone has been waiting ten minutes for, and progress has to mean something to the person watching rather than jumping from nothing to done. Access is handled with time-limited tokens issued per user, because a single GPU cannot serve an unbounded audience and the limit needs to be a policy rather than a queue that quietly grows. An admin side shows worker health and the current backlog, which is what tells you whether a stuck job is the file or the machine. The conversion itself is the same pipeline as the single-user tool; nearly all the code here is the operational shell around it.

The book is split into passages and indexed for full-text search before the call, so an answer can cite a specific place rather than paraphrase the whole thing. Audio is recognised locally and the reply is spoken through the system voice; the call itself is joined through the Zoom web client under browser automation, which avoids needing anything installed on the meeting side. Recognition runs continuously but the assistant only acts when it hears its own name, because a book club is a conversation between people and an assistant that answers unbidden ruins it. Latency is the real constraint: an answer that arrives after the discussion has moved on is worse than no answer, so retrieval is local and the index is built ahead of time. Quoting the source passage turned out to matter more than the answer itself — it lets the group argue with the book rather than with the assistant.

The work is split into independent units so an agent can dispatch them in parallel and each result can be validated on its own. Every piece of evidence carries the source it came from, and sources are labelled by how open they are, so whoever consumes the report can discard any tier they do not want to rely on. The output is schema-validated rather than free text, which is what makes it usable as an input to something else instead of as something a person has to read and retype. Anything the sources do not support is left empty rather than guessed — a blank cell is information, an invented one is a liability. Written as an agent skill rather than an application, it is a set of instructions and schemas a coding agent executes, so it fits wherever that agent already runs.

A CVE record tells you a library and a version range; it rarely tells you which classes matter, and that is the thing you need to know whether your code is exposed. The agent pulls from advisory databases and source hosting, matches descriptions against class names, and returns structured output rather than prose. Where a fix commit is linked, the changed classes are the strongest available signal, so the commit is read in preference to the prose description. It works without search API keys, falling back to a simpler retrieval path when they are absent. Every class it names carries the reference that produced it, because an unsourced list of class names is not something anyone should act on.

Rebuilding the agent as an explicit graph made the retry and fallback behaviour visible instead of buried in control flow. It processes repositories and commits linked from a CVE record, extracts what it can from non-repository references, and emits JSON. Both the model provider and the search backend are swappable, which is what lets the same graph run against a hosted model or a local one without touching the logic. When a node fails it degrades to a weaker source rather than aborting, so a partial answer with named sources beats no answer. Together with its predecessor and the JVM vulnerability service, it is the third pass at the same problem, each one moving further from manual work.

The application itself is closed, but two artefacts of it remain public and must stay reachable: the privacy policy and the terms and conditions, both linked from outside this site. They are the reason those two files are excluded from every cleanup, and the reason this entry exists at all rather than being dropped. Expo was chosen to get one codebase onto Android without a native toolchain, which was the right trade at the time and is why the project shipped. What is left is the least interesting part of the work and the only part that still has to run. It is listed here because a portfolio that quietly omits the things that ended is not an honest one.