Personal AI Architecture

Personal AI Architecture: Memory, Retrieval, and Automation

This page documents a personal AI system that uses work context, scheduled processes, and layered retrieval. It also notes which parts might be useful in a university setting and which remain untested.

Architecture snapshot: October 4, 2026 · Reading layout updated September 5, 2026.

Automated jobs
95 enabled jobs
Durable memory
838 nodes · 1,360 pages
Context loading
3 memory layers

The pipeline in one glance: raw signals flow left to right through accumulation and synthesis crons into the durable knowledge layer, where the agent pulls them back out at the moment of conversation.

The Problem

Why context matters

A general chatbot can answer a question such as “who should I follow up with this week?” only in general terms. A system with permission to use meeting notes, commitments, and project context can give a more specific answer.

The limiting factor in this example is knowledge: the system needs the relevant context at the time of the question.

Email and calendar access can answer “what’s on my calendar,” but not “what does this meeting mean in the context of this project?”

The hard problem isn’t connecting data sources. It’s building a knowledge layer on top of them. A system that:

  • Captures raw signals consistently (meetings, emails, news, campus trends)
  • Synthesizes them into patterns over time (key collaborators, decisions, recurring themes)
  • Retrieves the right context at the right moment. Mention a colleague by name and the AI recalls your meeting history with that person, not every meeting you’ve ever had

In my experience, capture is the easier part. Synthesis and retrieval determine whether the accumulated information is useful later.

This page documents how I built that knowledge layer for myself: 95 enabled automated jobs routed through UC San Diego’s TritonAI gateway, entirely on open-weight models, with the primary inference path hosted on-prem. An 838-node knowledge graph, 1,360 wiki pages, a three-layer memory system, and a memory ecosystem that Claude Code, Codex, and the Hermes agent all read from and write back to. It also provides a starting point for considering whether parts of the pattern could be used beyond one person.

Why this matters now

Many AI products now combine chat, agent functions, and personal context. When that context is stored in a vendor-specific format, changing products may also mean losing or rebuilding it.

In this design, knowledge stays in my filesystem in open formats. Model routes can change without moving the underlying context into a vendor-specific store.

The design goal is to build a useful knowledge layer without placing the underlying institutional context in a vendor-specific system.

The Architecture

Three layers of context loading

A personal AI has a practical constraint: context windows are finite, institutional knowledge is not. You can’t load everything, but loading nothing gives you a chatbot with your name bolted on.

The architecture I settled on has three layers:

Layer 1: Always Loaded. A small fixed set of files the agent reads on every interaction: identity, user profile, curated long-term memory, observed work patterns, today’s and yesterday’s memory. ~50 KB total, cheap to load, enough for the AI to respond as itself with 48-hour awareness. Without it, every conversation starts from zero.

Layer 2: Loaded on Trigger. When the conversation mentions a person, technology, decision, project, or trend, the agent proactively reads the matching wiki page. Mention a colleague and it reads wiki/people/{person-id}.md. Mention a vendor and it reads wiki/tech-stack/{tool-id}.md. Ask “why did we go with X?” and it scans wiki/decisions/. In this system, 1,360 wiki pages form a reference library. A relevant page is retrieved when a matching person, project, technology, or decision is mentioned.

Layer 3: Loaded on Explicit Request. Deep-dive content (dated memory files, full transcripts, the raw knowledge graph) loaded only when you ask. “What happened in Tuesday’s meeting?” pulls the specific file. “Show me my full graph” loads and analyzes the JSON. Rare but critical fallbacks.

In this design, context is treated as a limited budget. The system loads a small default set and retrieves additional material when it is relevant.

Layer 2 adds triggered retrieval beyond the opening profile and prompt. It is how this system uses an accumulating wiki without loading every page at once.

The Pipeline

The daily rhythm that builds the knowledge layer

95 enabled jobs build the knowledge layer on a predictable daily rhythm. A typical weekday:

Morning accumulation (6–9 AM). Data-gathering crons. Calendar briefing pulls today’s events. AI news digest runs web searches scored against the knowledge graph, so the “news” is actually relevant. Opportunity scan reads the graph and hunts for campus AI projects matching my priorities. Student pain signal monitor scrapes Reddit, the UCSD Guardian, and the campus status page for recurring issues. Wiki ingest reconciles the graph against the wiki and creates stub pages for high-weight entities that don’t have one yet.

Evening synthesis (5:30–7:35 PM). Evening wrap triages emails and drafts replies. Granola meeting debrief extracts commitments, sentiment, and undercurrents from today’s transcripts. Daily reflection synthesizes everything into a narrative debrief. Context promotion moves the day’s signals into long-term memory — the closest thing to a dreaming phase the system has, and it runs at 7:35 PM, not 3 AM.

Weekly synthesis (Sunday 6 PM). Reads 7 days of opportunity scans and pain signals, extracts cross-day trends, and promotes the strongest patterns to long-term memory. That’s how “VPN failed Monday” + “VPN failed Wednesday” + “VPN failed Friday” becomes “VPN is systemically broken this week.”

The rhythm is what turns a pile of raw files into institutional knowledge.

The Durable Layer

Knowledge graph + wiki: brain stem and cortex

Two durable stores anchor everything:

Knowledge Graph
838 nodes · 894 edges

Nodes: people, technologies, vendors, decisions, projects. Edges: relationships (“meets_with,” “often_meets_with,” “uses”). Every node has a weight and a meetingCount. Fast, shallow, relational. Good at answering “who works on X.”

Wiki
1,360 narrative pages

Markdown pages mirroring the highest-weight entities: people, tech-stack, decisions, projects, concepts. Slow, rich, narrative. Good at answering “why did we choose X.”

Reconciliation: when a graph node crosses a weight threshold, a wiki page is auto-created as a stub and enriched over time by meetings and manual edits. The wiki-ingest cron runs at 9 AM daily, creating up to 8 new people pages and 8 new tech-stack pages per run, so even entities that never cross the “2+ meetings in one day” threshold eventually get promoted as meeting history accumulates.

Dedup: the graph pulls from multiple sources (transcripts, calendar, manual edits), so duplicates creep in. The same person under “First Last” and “Last, First,” or a vendor under slight spelling variations. A periodic dedup pass merges them at the graph level.

The wiki is also fed from outside the personal stream. A nightly sync mirrors 2,100+ pages from nine institutional Confluence spaces: runbooks, team docs, service desk procedures, build & release, AI governance. A second nightly sync pulls messages from scoped Microsoft Teams channels, so the agent sees the live conversations where decisions actually get made. “Your work world” is no longer just what you touch directly; it’s what your org has written down and what your team is talking about right now.

The graph is the brain stem: fast, shallow, relational. The wiki is the cortex: slow, rich, narrative. Together they’re a cheap institutional memory system.

The Inference Layer

Model allocation: matching jobs to capabilities

The inference layer is now deliberately simple: one capable default for reasoning, tools, and long-horizon synthesis, plus a faster model for the small set of lightweight recurring jobs that benefit from it. The one capability the primary lacks — vision — is offloaded to a vision-capable model behind the same institutional gateway, which returns a text description into the conversation.

As of October 4, 2026, all 95 enabled jobs run through TritonAI, UC San Diego’s institutional AI gateway. The fleet runs on a two-tier design: 60 inference jobs on open-weight models hosted on-prem — 55 on GLM 5.3 for reasoning, tools, and long-horizon synthesis, 3 on the faster GLM 5.3 Flash for lightweight recurring scans, and 2 on Gemma 4 31B for quick scan-and-check jobs. The other 35 jobs are deterministic scripts that never call a model at all. Four of the 60 inference jobs pair with monitor mode: a deterministic script checks the source first, and the model call is skipped entirely when nothing changed. Three fallback models (DeepSeek V4 Flash, Gemma 4 26B, Gemma 4 31B) stand ready behind the primary — a chain rebuilt from verified completions, since the gateway’s model listing advertises models that reject real requests — and a key-access monitor checks the gateway’s catalog twice a week and flags any scheduled route that stops being accessible before a job fires against it.

TierModelHostingUseScheduled jobs
Primary reasoning & agentic workapi-glm-5.3TritonAI on-prem · Z.ai GLM 5.3 (open weight)Main chat, tools, interactive sessions, and nearly all scheduled agent workInteractive + 55
Lightweight scheduled workapi-glm-5.3-flashTritonAI on-prem · Z.ai GLM 5.3 Flash (open weight)Fast scan-and-check jobs where reasoning overhead is wasted: feed watches, date reminders, marketing scans3
api-gemma-4-31bTritonAI on-prem · Google Gemma 4 31B (open weight)2
No inference needed—Local scripts (deterministic)Syncs, refreshes, health checks, and other jobs that run without a model call35
Fallback chainapi-deepseek-v4-flashTritonAI on-prem · DeepSeek V4 Flash (open weight)Automatic if the primary is unreachable — tried in order, each verified by live completion probe—
api-gemma-4-26bTritonAI on-prem · Google Gemma 4 26B (open weight)—
api-gemma-4-31bTritonAI on-prem · Google Gemma 4 31B (open weight)—
Counts current as of October 4, 2026. Every fallback rung is verified with a real completion call — the gateway’s model listing is not trusted, after it was found advertising models that reject actual requests.

Why GLM 5.3 is the default: its tool use, reasoning controls, and long-horizon behavior let one model cover work that previously needed several capability tiers. The current TritonAI virtual key advertises a 320K context window, and the local configuration clamps it to 128K rather than assuming the model’s theoretical maximum. Z.ai describes GLM 5.3 as an open model designed for long-horizon agentic work.

Why one primary model: when the fleet was spread across six models, a hub-side model swap or a key change could break a quarter of the schedule at once, and the multi-tier layout silently rotted — jobs drifted onto models they were never assigned to. Consolidating on one well-matched open-weight default removes that failure surface: one model to pin, one swap to run, one monitoring lane. A small second tier (Gemma 4 31B) covers the two jobs where a reasoning model is wasted overhead, and three fallback models stand ready behind the primary.

Strict fallback is a privacy boundary: every fallback rung — DeepSeek V4 Flash, Gemma 4 26B, Gemma 4 31B — is an open-weight model served by the same on-prem gateway. If the primary and all fallbacks fail, Hermes surfaces the failure instead of silently sending private context to a cloud provider. No fallback path ever leaves the institution.

How routing stays healthy: every scheduled job is pinned to an explicit provider and model, so a hub-side model swap can’t silently re-route the fleet — an unpinned job refuses to run rather than spend against a model it was never assigned to. A dedicated tritonai-key-access-monitor job probes TritonAI’s /v1/models catalog and catches identifier or access changes before a job fires against them.

Open-weight models, an institutional gateway, explicit fallback rules, and catalog monitoring keep the automation separate from any single model provider.

Current uses

What the system does

Building this was the hard part. Using it is where it pays off. What the system delivers today, the value it generates, and what else becomes possible once the foundation is in place.

What it does today

Daily briefings, delivered automatically

Calendar + email summary at 6:25 AM. AI news digest filtered through my priorities at 6:35. Opportunity scan of higher-ed AI projects at 7:00. Campus pain signals from forums and status pages at 7:30. All waiting before I open a laptop.

Meeting intelligence after every meeting

Transcripts processed for commitments (who promised what), sentiment (how people felt), participation patterns (who dominated, who stayed quiet), and undercurrents (what was implied but not said). Searchable across a 14-month corpus.

Weekly trend synthesis

A Sunday cron reads 7 days of signals and extracts patterns: which opportunities recurred, which pain points became systemic, which themes faded. The strongest get promoted to long-term memory.

Real-time conversational context

When I message the agent on Telegram, it loads long-term memory, work patterns, the last 48 hours, and pulls in wiki pages for any person, technology, or decision I mention. Feels like it just knows.

Auto-published public artifacts

The weekly UCSD AI newsletter auto-generates and publishes to /ucsd-ai-news. The personal AI digest auto-publishes daily to /ai-digest. The knowledge framework documents itself. You’re reading that output right now.

Cross-session continuity

Decisions made in conversation write back to the wiki. Observed patterns write to a patterns file. The framework is bidirectional. Read for context, write for continuity. Future sessions inherit what present sessions learn.

The value delivered

  • 1
    Time saved: 2–3 hours per week

    Research, meeting prep, email triage, news scanning, and follow-up tracking used to eat several hours a week. The crons do the gathering; I do the judgment. That time gets reclaimed for actual decisions.

  • 2
    Pattern recognition I’d otherwise miss

    Daily reports don’t tell you the VPN failed 5 of 7 days last week. The weekly synthesis does. The graph shows who I actually meet with most, not who I think I meet with most. Data surfaces patterns intuition can’t.

  • 3
    Institutional memory, not just personal memory

    Decisions, architectural choices, vendor evaluations, and their reasoning are preserved. “Why did we pick this over that?” has an answer. So does “when did we last discuss X?” Memory persists across sessions, weeks, and staff changes.

  • 4
    Never starting from zero

    Every conversation begins with 48 hours of recent context, curated long-term memory, and triggered wiki lookups. I don’t re-explain my world each time I ask a question, and the agent doesn’t need reminding who the key people and projects are.

  • 5
    Opportunities surfaced proactively

    The opportunity scanner and AI news digest find campus projects, industry developments, and trends matching my priorities. 60 seconds to review each morning. Without this pipeline, I’d miss them or spend an hour hunting.

What else becomes possible

Meeting prep automation

Before every meeting, auto-compile attendee wiki pages, recent interactions, open commitments, relevant decisions, and a one-page prep doc. No more walking in cold.

Proactive nudges

The agent notices patterns without being asked. “This problem has come up three weeks in a row. Here are the options you’ve already explored.” “This person has asked about the same thing five times. Worth a 1:1?”

Draft-first communications

Emails, memos, and responses drafted in my voice using my actual context. Not generic AI writing. Contextual writing grounded in what I’ve said and decided before. Review beats drafting from scratch.

Decision archaeology

“Why did we pick this architecture two years ago?” Immediate answer with the full reasoning, the voices that disagreed, and the tradeoffs considered. No more Slack/email archaeology.

Self-monitoring system health

The agent notices when data sources go stale, crons degrade, or the knowledge layer has gaps. Self-monitoring becomes self-repairing. The system maintains itself instead of waiting for a human to notice.

Domain-aware research

Instead of “search the web,” the agent does “search filtered through what I care about, scored against my graph, synthesized with what I already know.” Research becomes targeted, not exhaustive.

Programming agents with institutional memory

The memory ecosystem is shared, not exclusive. Claude Code and Codex on both of my Macs read the same wiki, knowledge graph, and memory the Hermes agent maintains — hooks inject that context at session start, and an MCP server lets them query it mid-session. Every coding session writes a recap back, and a nightly job folds those recaps into the wiki and decision log. Three agents, one memory. The knowledge layer isn’t locked to one agent anymore.

The Vision

Scaling to UC San Diego

Everything above is one person’s implementation. The interesting question: what if every UC San Diego staff member had one?

Privacy is the precondition

This only scales if privacy scales with it. Personal data never leaves the personal agent. Each tier above is opt-in, anonymized, or aggregate-only, never individual records flowing upward. Without that guarantee at every level, nothing ships.

Personal: the foundation. Every staff member gets their own agent, memory, wiki, and crons. Data never leaves their agent. I use this setup daily, but it has only been tested for one person. Extending it would require a repeatable deployment pattern: dedicated runtime, isolated data store, and a governance model that says “this is yours, private by default.”

Team: opt-in sharing, not opt-out. Team members choose what to share. The team wiki is visible to all members; 1:1s and personal notes stay private. Nothing crosses the boundary automatically. This is where governance gets interesting: who decides what’s shared, how do you handle a team member leaving, and how do you prevent context from leaking between people.

Pilot in progress: TritonAI Team Knowledge Vault

A team pilot began May 18, 2026: a 3-person shared Obsidian vault for the TritonAI core team (Brett Pollak, Shawn Munro, and Jeremy Wiles), sitting in a private GitHub repo and auto-syncing every 10 minutes via the Obsidian Git plugin. The vault has six shared sections: people/ (professional profiles, no 1:1 notes), projects/ (live status), decisions/ (ADRs), tech-stack/ (vendor evaluations), runbooks/ (how-we-do-things), and proposals/ (the only place agents are allowed to write).

Two contributor modes coexist. Type A (manual) edits pages directly in Obsidian; auto-sync handles the rest. That’s how Jeremy works today. Type B (agent-assisted) is how Shawn and I work: an agent reads evening-wrap, meeting debriefs, and opportunity-scan output, drafts updates into proposals/YYYY-MM-DD-{topic}.md, and a human (the owner of the page) reviews each one, about 30 seconds, before committing into the canonical page. No automation writes directly to shared pages. Having both modes live in the same vault from week one is a deliberate test. We want to see whether manual and agent-assisted contributors can coexist without one mode crowding out the other. Four cron jobs run the rhythm: nightly ingest at 8 PM weeknights folds team-vault changes into the personal knowledge graph, a proposals generator drafts new entries the same hour, a proposals monitor surfaces them at 9 AM, and a Monday-morning staleness check flags any page untouched for 14+ days.

Week-one activity. 25+ assets were updated in the first 48 hours: people cards, decision docs, project pages, runbooks, and tech-stack entries. All three participants were editing the vault, and the nightly ingest means a decision logged in the vault is in my agent’s context by the next morning. The Monday briefing now opens with a team-diff section. The four-week pilot window closed in June; the vault has stayed in daily use since, and the rhythm — proposals drafted nightly, surfaced each morning, staleness-checked Mondays — still runs.

What the pilot is testing. If the approach works for three people, the pilot can help assess whether the same pattern (shared Obsidian vault, GitHub backing, proposals-first agent writes, ~10 minutes of human review per week per steward) can extend to a larger group. Each tier would become “Layer 2” (triggered) for the tier above. If a UC San Diego campus offering ever ships, this is the architectural shape we’d propose: every team gets a vault, every team member gets an agent that reads it, no team’s vault is visible to another without explicit cross-vault permission.

Department: anonymized aggregates only. At WTS or Academic Technology Services, the useful view is patterns, not records. “Trending pain points this week” or “which vendors are we all evaluating”. No individual data, just signals that emerge from many agents, the way public health surveillance works. The system strips individual identity before aggregation; the dashboard never shows who said what.

Campus: statistical patterns only. TritonAI provides campus-wide AI services. The missing piece is connective tissue: aggregate department patterns up to institutional insights. Which departments struggle with the same vendor, which AI use cases are converging, what decisions would help everyone. This tier only ever sees statistical patterns, never individual records, never attributable content.

The tech mostly exists. The governance doesn’t. Sharing boundaries have to be first-class features, not bolt-ons. And campus data stewardship has to be comfortable with the model before anything scales beyond the personal tier.

Current status: I use the personal layer daily. The team layer has been in continuous use by three people since May 18. Department and campus layers are still design exercises, not shipped code. The pattern is there; the architecture is a starting point, not a finished product.

The open question is what it would take to use this approach more broadly while protecting privacy. That would require work across design, governance, procurement, and technology.

Evolution

This architecture isn’t done

Read the development history

It’s a living system, updated continuously. Some of what’s on this page will be obsolete in six months. That’s the point. Every change is in the git history of my brettpollak-website repo; highlights below for quick reference.

  1. October 4, 2026
    Weekly refresh: fleet steady at 95 jobs, graph and wiki grow

    No jobs added or retired this week; the fleet shape is unchanged at 60 inference jobs (55 on GLM 5.3, 3 on GLM 5.3 Flash, 2 on Gemma 4 31B), 35 deterministic scripts, 4 in monitor mode. The knowledge graph grew from 829 to 838 nodes and 885 to 894 edges. The wiki grew from 1,278 to 1,360 pages, with most of the jump coming from a new Claude Code memory sync that mirrors 74 session-memory pages into the wiki tree, alongside steady growth across people and decision pages.

  2. September 27, 2026
    Weekly refresh: fleet at 95 jobs, wiki passes 1,275 pages

    Three deterministic scripts joined the fleet and none were retired: a Silas contact-lens fitting reminder, a weekly agentshield audit, and a Granola actions inbox. A third tier appeared in the inference layer: three lightweight recurring scans now run on GLM 5.3 Flash (the X digest draft and two Steel City Gameday jobs), so the fleet shape is 60 inference jobs (55 on GLM 5.3, 3 on GLM 5.3 Flash, 2 on Gemma 4 31B), 35 deterministic scripts, 4 in monitor mode. The knowledge graph grew from 810 to 829 nodes and 866 to 885 edges, and the wiki grew from 1,179 to 1,278 pages.

  3. September 20, 2026
    Weekly refresh: fleet passes 90 jobs, wiki tops 1,175 pages

    Six jobs joined the fleet and none were retired: podcast-comment-draft, weekly-site-metrics, and four Steel City Gameday jobs (scg-daily-scan, scg-weekly-beat, scg-gameday, SCG daily traffic ping). Fleet shape is now 60 inference jobs (58 on GLM 5.3, 2 on Gemma 4 31B), 32 deterministic scripts, 4 in monitor mode. The wiki grew from 1,100 to 1,179 pages, and Sunday’s knowledge-graph rebuild left the graph at 810 nodes and 866 edges.

  4. September 13, 2026
    Weekly refresh: fleet at 86 jobs, wiki passes 1,100 curated pages

    One job joined the fleet (daily-x-digest-tweet-draft, an 8 AM X post draft built from the morning AI digest) and one was retired (harness-review-quarterly, whose mission-control targets no longer exist). The new job arrived unpinned and was pinned to TritonAI GLM 5.3, keeping the every-job-pinned rule intact. The knowledge graph grew from 873 to 886 nodes and 926 to 930 edges, and the wiki grew from 1,076 to 1,100 curated pages. Fleet shape is otherwise unchanged: 55 inference jobs (53 on GLM 5.3, 2 on Gemma 4 31B), 31 deterministic scripts, 4 in monitor mode.

  5. September 11, 2026
    Memory ecosystem goes three-agent: Claude Code, Codex, and Hermes share one memory

    The two-way bridge described on this page is now the default for every coding agent I run. Claude Code and Codex on both Macs get wiki, graph, and memory context injected at session start through hooks, query the same stores through an MCP server mid-session, and write recaps back to an inbox that a nightly job promotes into the wiki and decision log. Claude Code’s own durable memories mirror into the wiki in both directions. Fleet stands at 85 enabled jobs (52 on GLM 5.3, 2 on Gemma 4 31B, 31 deterministic scripts, 4 in monitor mode); the knowledge graph is at 873 nodes and 926 edges, and the wiki at 1,076 curated pages.

  6. September 9, 2026
    Evening update: graph crosses 860, wiki passes 1,044 curated pages

    The nightly team-vault ingest returned from a five-day deadlock and processed the backlog: the knowledge graph grew from 852 to 860 nodes and 888 to 904 edges, and the wiki grew from 1,038 to 1,044 curated pages. The homepage now carries a summary of this architecture with links into each section.

    September 9, 2026
    Weekly refresh: 86 jobs, vision offload, OpenClaw-era router paragraph retired

    Fleet grew from 83 to 86 enabled jobs (TritonAI roadmap auto-review, an Agent Wiki digest, a Resolution Companion marketing heartbeat), and monitor mode expanded from three jobs to four. Vision now offloads — GLM 5.3 is text-only, so image analysis runs on a vision-capable model behind the same TritonAI gateway and returns a text description into the conversation. The two-hour “autonomous router” this page described was an OpenClaw-era mechanism that never survived the migration; routing health rests on pinned jobs, catalog monitoring, and a fallback chain whose three rungs were re-verified with live completion calls today. Knowledge graph grew from 848 to 852 nodes and 884 to 888 edges; the wiki grew from 1,008 to 1,038 pages, led by 16 new people pages, 7 project pages, and 3 decision pages.

  7. September 6, 2026
    Weekly stats refresh: 83 jobs, graph +45 nodes, wiki crosses 1,000 pages

    Knowledge graph grew from 803 to 848 nodes and 844 to 884 edges. The wiki crossed a thousand pages, growing from 898 to 1,008 (+110): the largest single addition is a 60-page mirror of Claude Code work-session memories from the work Mac, plus new project pages for four TritonAI initiatives (comeback cohort agent, course redesign studio, recharge cost attribution engine, student voice intelligence engine). Four jobs joined the fleet (agent-session-ingest, which pulls Claude Code and Codex session recaps into the wiki; decision-brief-weekly; vendor-terms-watch; opportunity-validation-loop) and the daily enhancement sprint was retired. The fleet now stands at 83 enabled jobs: 52 inference (50 on GLM 5.3, 2 on Gemma 4 31B) and 31 deterministic scripts.

  8. September 2, 2026
    Runtime upgraded to Hermes v0.21.0; monitor mode and run continuity added; fallback chain rebuilt from verified completions

    The agent runtime moved from Hermes v0.20.6 to v0.21.0. Three monitoring jobs now run in monitor mode: a deterministic script checks the source first, and the model call is skipped entirely when nothing changed — the release-watch, blog-watch, and key-access jobs only “think” when there is something to think about. Seven reasoning jobs gained cross-run continuity, so each run starts from where the last one ended instead of from zero. Rebuilding the fallback chain surfaced a sharper lesson: the gateway’s model listing advertises models that reject real requests, so every fallback rung is now verified with a live completion call. Three of the four listed fallbacks were dead and were replaced with verified models (DeepSeek V4 Flash, Gemma 4 26B, Gemma 4 31B).

  9. September 2, 2026
    Diagrams redesigned; model fleet corrected to two-tier; stats re-verified against live system

    All four diagrams rebuilt with distinct visual grammars — pipeline rail, retrieval cross-section, daily-rhythm waterfall, and scaling bands — and every number on the page re-verified against the live system: 80 enabled jobs (49 inference + 31 deterministic scripts), 803 graph nodes and 844 edges, 898 wiki pages. The model fleet was corrected to its real shape: 47 jobs on GLM 5.3, 2 lightweight scan jobs moved to Gemma 4 31B, 31 script jobs with no model call. The old multi-model allocation table (GPT-OSS, Mistral Small/Large, Gemma 4 26B, Claude Sonnet) is retired; those tiers described a fleet layout that no longer exists after the GLM 5.2–>5.3 swap flattened every job to the primary. Also removed the fictional 3 AM “dreaming cron” — nightly memory consolidation actually runs at 7:35 PM, after the evening synthesis pass. A split-brain digest publisher job (midnight fires targeting a stale site clone) was found and retired.

  10. August 30, 2026
    Wiki grew +64 pages; model allocation corrected; cron count held at 65+

    Wiki expanded from 834 to 898 pages (+64), driven by 39 new people pages, 15 new decision pages, and 2 new project pages (regulatory-change-intelligence-agent, transfer-credit-articulation-agent). Enabled cron jobs held steady at 69 (65+). Model allocation table corrected: the fleet now spans four open-weight models (gpt-oss-120b, mistral-small, gemma-4-26b, mistral-large) plus 5 jobs on Claude Sonnet for deeper reasoning and 1 on DeepSeek V4 Flash Max. Knowledge graph held at 793 nodes and 837 edges (no drift).

  11. August 23, 2026
    Wiki surged +58 pages; enabled crons corrected to 65+

    Wiki expanded from 776 to 834 pages (+58), driven by new project pages including academic-integrity-case-triage-agent, behavioral-disengagement-engine, and tritonai-transfer-credit-intelligence-agent, plus continued growth across people and decision pages. Knowledge graph held steady at 793 nodes and 837 edges (no drift). Enabled cron jobs corrected from 77 to 69 (rounded to 65+) after retiring 8 one-shot reminder and dashboard jobs that had completed their purpose.

  12. August 16, 2026
    Graph grew +21 nodes, +21 edges; wiki +5 pages

    Knowledge graph expanded from 772 to 793 nodes and 816 to 837 edges (+21 each), driven by new people pages across ITS leadership and community college partners. Wiki grew from 771 to 776 pages (+5), with new and updated project pages including enrollment-aid-exception-agent, citizen-developer-program, and agentic-procurement-spend-optimization-agent. Enabled cron jobs held steady at 76 (no drift). One job retired since last week (architecture-review-monthly consolidated into this weekly review).

  13. August 15, 2026
    Platform migrated from OpenClaw to Hermes Agent

    Decommissioned OpenClaw after 8 months. Migrated 74 cron jobs to Hermes Agent (by Nous Research), bringing the total to 77 enabled jobs. All scripts, integrations, wiki (771 pages), credentials, and memory archives ported. Hermes provides the cron scheduler, agent runtime, Telegram gateway, multi-model gateway, skill system, and plugin SDK. Model allocation unchanged: GLM 5.2 remains the on-prem default via TritonAI with deepseek-v4-flash-max, gpt-oss-120b, gemma-4-26b, and mistral-small as fallbacks. OpenClaw uninstalled; 3.3GB backup archived.

  14. August 2, 2026
    Graph surged +136 nodes, wiki +89 pages

    Knowledge graph grew from 636 to 772 nodes and 680 to 816 edges (+136 each), driven by new people pages across ITS leadership and community college partners. Wiki expanded from 602 to 691 pages (+89), led by 20+ new decision pages including agentic CMS strategy, community college pilot structure, data governance three-council model, observability restructure, and HR redesign roadmap. New concept pages added: scenic-ai, uc-it-ai-council, and tritonai-research-administration-copilot. Enabled cron jobs steady at 69 (65+).

  15. July 19, 2026
    Wiki surged +58 pages, cron count corrected to 65+

    Wiki grew to 602 pages (+58), driven by new project pages including spa2-performance-management, splunk-opensearch-bifurcation, ai-training-video-series, ucla-health-partnership, bfs-cash-receipt-automation, observability-modernization, and ccc-partnership. Knowledge graph held steady at 636 nodes and 680 edges. Enabled cron jobs corrected to 65+ (rounded from 69) after retiring unused and one-shot reminder jobs.

  16. July 15, 2026
    GLM 5.2 became the on-prem default · proprietary automation routes retired

    Corrected the TritonAI catalog identifier from glm-5.2 to api-glm-5.2 and made GLM 5.2 the main agent, utility, active-memory, router, and default cron model. Repaired the two-hour router after the cron state moved to SQLite, replacing its Claude CLI decision path with direct on-prem GLM inference. The live fleet is now 90 enabled jobs: 81 inherit GLM 5.2 and nine lightweight jobs use DeepSeek V4 Flash Max. No scheduled job has a proprietary override, the main fallback list is empty, vision uses on-prem Gemma 4, and local model and cron canaries passed.

  17. July 12, 2026
    Wiki continued its rapid expansion — +55 pages, graph +3 nodes

    Wiki grew to 544 pages (+55), driven by new tech-stack entries (crowdstrike, databricks, litellm, glm-5, openai, and 10+ others), decisions (fde-program-restructure-2026-07, frontier-model-risk-mitigation-framework, student-scheduling-assistant-launch, and 25+ more), and new people pages across ITS leadership and TritonAI collaborators. Knowledge graph edged up to 636 nodes and 680 edges (+3 nodes, +6 edges). New project pages added: tritonai-developer-api, tritonbuild, and ai-contract-reviewer. New concept pages: ai-policy-navigator, hsdsc, preferential-rehire, research-portfolio-intelligence-agent, and ucsd-skills-library. Enabled cron jobs steady at 69.

  18. July 5, 2026
    Steady growth — knowledge graph +36 nodes, wiki +31 pages

    Knowledge graph expanded to 633 nodes and 674 edges (up +36 nodes, +36 edges). Wiki grew to 489 pages (+31), driven by new decision pages (citizen-developer-program-rady-engagement, crowdstrike-falcon-complete, hermes-enhancement-plan, hsdsc-inference-expansion, ta-matching-automation-accelerated), 15 new people pages, and 6 new tech-stack entries. No new cron jobs added; enabled jobs steady at 69.

  19. June 28, 2026
    Wiki growth accelerated — +81 pages, graph +31 nodes

    Knowledge graph expanded to 597 nodes and 638 edges (up +31 nodes, +21 edges). Wiki surged to 458 pages (+81), driven by new project pages (GrantIQ, Student Scheduling Assistant, TA Matching Algorithm, TritonAI Harness) and 15+ decisions added. No new cron jobs added; enabled jobs steady at 69.

  20. June 21, 2026
    Graph and wiki accelerated growth — knowledge graph +25 nodes, wiki +52 pages

    Knowledge graph expanded to 566 nodes and 617 edges (up +25 each). Wiki grew to 377 pages (+52), driven by 8 new people pages, 2 new project pages (tritonai-harness, canvas-onyx-integration), and 15+ decisions spanning TritonAI social layer architecture, Onyx contract renewal, AI Tutor Canvas tool naming, iMessage integration, and the FY27 budget win for ITS. Enabled cron jobs steady at 69.

  21. June 14, 2026
    Weekly architecture metrics update

    Graph grew to 541 nodes and 592 edges (up +156 nodes, +162 edges). Wiki expanded to 325 pages (+58). Enabled cron jobs rose to 69 (rounded 65+). Added new project pages for recent initiatives.

  22. June 9, 2026
    Router outage fixed · fleet rebalanced to ~99% open-weight · Gmail triage localized

    A platform upgrade silently moved cron job storage into the gateway’s internal store, which broke the model-router’s state digest — it had been failing every 2-hour cycle since June 3 with no decisions and no alerts. Patched the digest to read merged state from the gateway, verified the 52-test suite plus a live cycle, and the router is back on duty. The same storage migration explained why one earlier fleet edit never took effect (email-task-scanner was still running a model known to decorate sentinel outputs — now corrected through the gateway API). Rebalanced the fleet: five heartbeat-sentinel jobs moved off api-mistral-small-3.2-2506 to api-gpt-oss-120b, two file-editing weekly jobs with repeat apply-patch failures moved to deepseek-v4-flash-max, and both provider-quota-monitor and gmail-important-emails came off proprietary Claude Sonnet to local models (the Gmail swap verified with a live run before committing to it). Every single-model job gained a local fallback chain, and the default fallback order is now local-first: deepseek-v4-flash-max → api-gpt-oss-120b → claude-sonnet-4-6. New distribution across 73 enabled jobs: 47 on api-gpt-oss-120b, 7 on deepseek-v4-flash-max, 6 each on api-mistral-small-3.2-2506 and mistral-large-3-675b, 5 on api-gemma-4-26b, and exactly 1 on proprietary claude-sonnet-4-6.

  23. June 7, 2026
    Graph and wiki growth – nodes, edges, and pages expanded

    Updated knowledge graph to 385 nodes and 430 edges, wiki grew to 267 pages, and enabled cron jobs remain at 65+. Added several new project wiki pages (e.g., tritonai.md, databricks-platform-direction.md) reflecting recent initiatives.

  24. May 31, 2026
    Architecture stats refreshed – growth across graph, wiki, and crons

    Updated graph to 329 nodes and 374 edges, wiki expanded to 263 pages, and enabled cron jobs increased to 67 (rounded to 65+). 4 new wiki pages across projects and tech-stack. May 19 rebalance gains fully absorbed; identity-drift-review timeout bumped to 900s to prevent repeat failures.

  25. May 21, 2026
    TritonAI catalog refresh · key rotation · 57 jobs re-routed · catalog-change monitor added

    TritonAI rotated personal API keys and shipped a server-side catalog refresh that retired several models the cron fleet had been routing to — moonshotai.kimi-k2.5, nemotron-3-super-120b-instant, claude-haiku-4-5-20251001, and claude-opus-4-6 — and replaced them with claude-opus-4-7, gpt-5.5, gpt-5.3-codex, and deepseek-v4-flash-max. On-prem open-weight models also got an api- prefix (api-gpt-oss-120b, api-gemma-4-26b, api-mistral-small-3.2-2506) and are now segregated behind a separate on-prem key from the hyperscaler-proxied cloud tier. Rotated both keys, normalized every cron’s model assignment to the canonical provider/model path, and bulk-re-routed 57+ jobs in a single pass to prefer the on-prem open-weight tier — new distribution is 20 on api-gemma-4-26b (briefings & summarization), 18 on api-mistral-small-3.2-2506 (syncs & monitors), 14 on api-gpt-oss-120b (heavy synthesis), 7 on mistral-large-3-675b (long-form & deep research), 1 on deepseek-v4-flash-max (overnight code maintenance), and 2 explicit escalations to claude-sonnet-4-6 — provider-quota-monitor and gmail-important-emails — where a missed signal carries real downstream cost. Default agent fallback chain rebuilt: claude-sonnet-4-6 → claude-opus-4-7 → api-gpt-oss-120b. Added a new tritonai-key-access-monitor cron that fires Mondays and Thursdays at 6 PM PT, probes TritonAI’s /v1/models endpoint for both keys, diffs against a stored snapshot, and Telegrams a summary of any changes — with broken-job warnings if a current cron route is no longer accessible. Net effect: the next TritonAI catalog refresh surfaces itself before a cron fails.

  26. May 19, 2026
    Open-source rebalance · 11 jobs to gpt-oss-120b · aggressive efficiency

    Rebalanced 11 jobs from commercial models (claude-sonnet-4.6, mistral-large-3) to tritonai-prod/gpt-oss-120b based on actual workload patterns — news aggregation, event curation, script runners, and auditing tasks don’t need commercial reasoning. Kept claude-sonnet-4.6 for synthesis-heavy jobs (meeting debriefs, daily reflection, memory promotion), mistral-large-3 for web research + thesis generation. Net effect: ~$300–400/month institutional savings while staying on TritonAI’s open-weight platform. (Superseded by the May 21 entry above; meeting debriefs, daily reflection, and memory promotion have since moved off claude-sonnet.)

  27. May 17, 2026
    Architecture stats refreshed – growth across graph, wiki, and crons

    Updated graph to 250 nodes and 298 edges, wiki expanded to 247 pages, and enabled cron jobs increased to 56 (rounded to 55+). Added new project pages: gartner-eoi-2026, biobib-formatter, citizen-developer-program.

  28. May 10, 2026
    Architecture stats refreshed

    Updated graph to 222 nodes and 265 edges, wiki expanded to 219 narrative pages, and enabled cron jobs remain at 56 (rounded to 55+). No new cron jobs added this week.

  29. May 9, 2026
    100% local open-weight achieved · 31-job migration · Telegram routing fix

    Bulk-migrated 31 cron jobs onto TritonAI’s locally-hosted open-weight catalog. Every proxied closed-weight model retired in one pass: 14 jobs off tritonai-haiku (Claude Haiku 4.5 via proxy), 4 off tritonai-opus (Claude Opus 4.6), 3 off Codex / codex-mini (capped weekly cap + a model that no longer existed), 1 off or-haiku (OpenRouter Anthropic), 1 off Ollama gemma4 (slow on Apple Silicon). New endpoints brought in: TritonAI’s mistral-small-3.2-2506 for fastest light monitors, more weight on nemotron-3-super-120b-instant, moonshotai.kimi-k2.5, and mistral-large-3-675b. Each candidate probe-tested against a strict 50-token short-output prompt and a 400-token synthesis prompt before assignment; minimax-m2 and gpt-oss-120b-high failed the trap test and were excluded. End state: 48 of 48 enabled jobs on TritonAI, every model open-weight, zero ongoing third-party API spend on automation. Cross-provider canary retired — concentration risk now an explicit institutional bet. Separately, repaired a Telegram-DM routing collision: the heartbeat lane had quietly captured the bot’s direct-chat session and was returning HEARTBEAT_OK to every message.

  30. April 30, 2026
    Codex deprecation handled · all-TritonAI achieved · cron tuning

    OpenAI Codex deprecated gpt-5.4-mini on the OAuth route mid-morning, breaking 6 cron jobs that depended on it. Migrated 10 affected jobs to TritonAI in a single bulk patch — 9 to TritonAI open-weight models (Kimi K2.5 for synthesis, Mistral Large 3 for long-form, Opus 4.7 for heavy reasoning), 1 kept on OpenAI Codex (gpt-5.5) as a cross-provider canary. End state: 45 of 46 enabled jobs on TritonAI. Same day, tuned five high-frequency crons (-1,860 fires/month) and added two new TritonAI aliases for verified-clean light-monitor models: tritonai-mistral-small (Mistral Small 3.2) and tritonai-nemotron-instant (NVIDIA Nemotron 3).

  31. April 29, 2026
    OpenRouter dependency dropped · Platform runtime upgraded to 2026.4.27

    Migrated 9 remaining OpenRouter-paid jobs onto TritonAI (light monitors to tritonai-haiku; weekly deep-dive to tritonai-opus — Claude Opus 4.7 on raised institutional quota). Zero jobs on OpenRouter post-migration. Upgraded the runtime from 2026.4.23 to 2026.4.27 (skipping the 2026.4.24 bonjour-broken release) for cron correctness improvements, OpenAI-compatible empty-response retry, and mixed-version safety. Ran platform security audit — chmod 600 on the config file fixed a critical world-readable finding.

  32. April 28, 2026
    31-job migration to TritonAI open-weight models

    UC San Diego raised the TritonAI virtual-key budget. Migrated 31 cron jobs from a mixed OpenRouter / Codex / Google fleet onto TritonAI’s open-weight catalog: Kimi K2.5 for synthesis-heavy work (briefings, opportunity scan), Mistral Large 3 for long-form (newsletter, audits), gpt-oss 120B for single-shot agentic, Gemma 4 for mid-tier multimodal. Discovered along the way that the catalog’s reasoning flag was unreliable for short-output cron tasks — some “non-reasoning” models burned their token budget on chain-of-thought scratch and never produced final content. Two TritonAI model identifiers also turned out to need vendor prefixes (e.g. moonshotai.kimi-k2.5); fixed at the alias-registry level so the cron prompts stayed unchanged.

  33. April 26, 2026
    Graph stability + steady wiki growth

    Knowledge layer wiki coverage expanded from 185 to 189 narrative pages, bringing greater depth to the durable layer. Enabled automated jobs grew to 46 (from 40+), adding more coverage to the daily pipeline.

  34. April 24, 2026
    Citizen developer framework + accessibility audit + new monitoring crons

    Knowledge layer crossed 179 graph nodes and 185 wiki pages (up from 163/111 nine days earlier — a +67% jump in wiki coverage as graph-to-wiki reconciliation caught up with accumulated entities). Two new crons: a daily tritonai-model-hub-snapshot that diffs UCSD’s LLM gateway model catalog week-over-week into the Monday newsletter, and a Friday backlog-completion-scan that cross-references backlog tasks against the week’s meetings, debriefs, and sent mail to flag probable completions. An Accessibility Audit screen was added surfacing vendor accessibility statements across 150 enterprise systems. New wiki page: TritonAI AI Initiative Readiness Copilot.

  35. April 15, 2026
    Hybrid AI digest sourcing

    Replaced flaky generic web search with a hybrid pipeline: 14 curated RSS feeds (AI labs, arXiv, higher-ed tech publications) pulled fresh at 6 AM, plus site-scoped searches across major outlets (NYT, Bloomberg, WSJ, Wired, Ars Technica, TechCrunch). Added a fallback so the digest produces real content even when search APIs are offline, and loosened the diversity gate so digests reliably surface 5–7 articles.

  36. April 14, 2026
    Team chat ingestion + weekly deep-dive

    Added Microsoft Teams channel sync via MS Graph delegated scopes — scoped to high-signal channels, noise-filtered, chmod-600 on disk. New Sunday 2 PM deep-research cron picks one significant AI development each week and produces a 600–1000 word multi-source brief, separate from daily headlines.

  37. April 12, 2026
    Confluence integration (hybrid)

    Added the institutional Confluence wiki as a sixth data source. A nightly 4 AM cron mirrors 2,500+ pages from nine UCSD ITS spaces (AI Hub, WTS, BIA, Service Desk KB, Endpoint Management, Hybrid Cloud, Enterprise Architecture, Build & Release, CI Ops) into local cache, and an Atlassian MCP server handles realtime search. Wiki-ingest’s strategic-doc scanner auto-promotes high-signal pages into Layer 2 nightly.

  38. April 12, 2026
    Knowledge promotion pipeline fixes

    Repaired broken daily-reflection and context-promotion crons (timeouts bumped to 600s). Deduped 46 reversed-name person nodes (183 → 163). Added weekly-signal-synthesis cron for cross-day trends. Enhanced wiki-ingest with graph-to-wiki reconciliation and strategic-doc scanning. Documented three-layer context loading in AGENTS.md. Restructured MEMORY.md into 12 named sections.

  39. April 11, 2026
    Model migration off Anthropic + Ollama

    Migrated all 32 cron jobs off Anthropic Claude and local Ollama (quota and timeout issues). New allocation: Tier A (OpenAI gpt-5.4) for code and reasoning, Tier B (Google gemini-3.1-pro) for analysis, Tier C (gpt-5.4-mini) for fast monitors. Fallback: codex → codex-mini → gemini → gemini-flash-lite. Added a provider-quota-monitor cron every 30 min.

  40. Earlier 2026
    Graph + wiki established

    Built the initial knowledge graph from a 577-meeting transcript corpus (Feb 2025–Apr 2026). Set up daily crons for calendar briefings, AI news, opportunity scanning, and meeting debriefs. Added the wiki structure with SCHEMA.md and initial people/tech/decision pages.

  41. Future
    Team-level agents and beyond

    Team-level context sharing with privacy boundaries. Department-level anonymized trend aggregation. Campus-level institutional insights. Signal feedback loops so agents learn from human corrections. Mostly design work, not code yet.

Built on

The foundation of this system is Hermes Agent, a personal AI assistant framework by Nous Research providing the cron scheduler, agent runtime, Telegram integration, multi-model gateway, skill system, and plugin SDK the pipeline runs on. What you see here isn’t Hermes out of the box; it’s Hermes tailored, extended, and reshaped over months to fit a specific work context. The accumulation pipeline, knowledge graph reconciliation, three-layer context loading, and scaling vision all layer on top of that foundation.