To get AI to think consistently, I had to teach it how to think like a person.

Built like a brain — by convergence, not by design.

Both the human brain and grāmatr solve the same problem: how to process variable-complexity inputs efficiently under resource constraints. The solutions converged independently.

These aren't metaphors. They are convergent solutions to the same computational problem. The brain evolved these architectures over 500 million years. grāmatr implements them in software.

How the system gets smaller and faster.

Most AI memory tools work like filing cabinets — store everything, retrieve when asked. grāmatr works like a student. It studies your interactions, builds increasingly accurate models of your intent and preferences, and progressively optimizes its own classifiers to serve you faster with less data.

On day one, every request goes through a general-purpose language model with a full context payload. As interaction data accumulates, grāmatr's classification pipeline improves at the platform level — training LoRA adapters using Low-Rank Adaptation (Hu et al., 2021) that improve routing and classification for all users. These adapters don't replace the base model — they sit on top of it, lightweight parameter-efficient layers that encode patterns without full model fine-tuning. Personal adapter training — a premium feature — adds an additional layer that encodes individual workflow patterns for even faster, more accurate routing.

Classifier progression timeline

The flywheel math: every classified request produces a feedback tuple — the original prompt, the classification decision, and the outcome quality signal. That tuple becomes training data. Better training data produces more accurate classifiers. More accurate classifiers produce better routing. The cycle compounds.

grāmatr's classification pipeline has processed over 4,189 routed requests with 1,761 learning corrections from active production use — a single-user dataset that drives the progressive learning cycle. That feedback loop is what collapsed a 40,000-token system prompt to 1,200 tokens.

The numbers (publicly visible on GitHub).

The routing engine went live on March 21, 2026. The difference in output is measurable in any git client.

These are not estimates. Run the commands yourself:

# Commits per day (grāmatr repo)
git log --oneline --since="2026-03-21" --until="2026-03-29" | wc -l

# Version deployments
git log --oneline --all | grep -i "bump" | wc -l

Per-user encryption. Row-level security.

Per-user encryption

Every piece of data in grāmatr's knowledge graph is encrypted and isolated per user. The architecture enforces this at the database level, not the application level — meaning a bug in application code cannot expose one user's data to another.

User interaction data is stored in both a vector semantic database (pgvector on PostgreSQL) and a structured object database. Both enforce user-scoped access. Even grāmatr staff cannot query another user's knowledge graph.

Row-level security

PostgreSQL row-level security (RLS) policies enforce user isolation at every query. Every table carries a user_id column. RLS policies automatically filter every query to the authenticated user's scope. There is no application-layer "WHERE user_id = ?" that a developer could forget — the database enforces it.

No data flows between tiers automatically. Every cross-tier share requires explicit admin authorization.

Open source acknowledgments.

grāmatr's routing engine was influenced by patterns from two open-source projects by Daniel Miessler:

• Fabric — MIT License, Copyright (c) 2025. Pattern-based AI workflow orchestration.
• PAI (Personal AI Infrastructure) — MIT License, Copyright (c) 2025. Personal AI routing architecture.

Brian discovered these projects via the Network Chuck YouTube channel in February 2026. The routing patterns in PAI provided the conceptual foundation for grāmatr's decision router — the inflection point that turned a knowledge graph into a context engineering pipeline.

References