Personal AI Architecture
Building a Personal AI That Actually Knows You
Generic AI is generic. Useful AI knows your people, projects, decisions, and trends. Here’s how I built one that does — and how the pattern could scale across UC San Diego.
Last updated: June 7, 2026 · This page evolves as the architecture evolves.
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.
Why generic AI isn’t enough
Ask any stock chatbot “who should I follow up with this week?” and you get generic productivity advice. Ask one that actually knows you — who’s been in your meetings, what you committed to last Tuesday, what’s trending on campus — and you get something useful.
The gap isn’t model intelligence. The big models are already smart enough. The gap is knowledge: the AI needs to know your world, at the right moment.
Most personal-AI projects stop at “connect to my email, read my calendar.” That’s table stakes. It answers “what’s on my calendar” but not “what does this meeting mean in the context of the project I’ve been driving for six months.”
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
Most people build the first piece and call it done. The second and third are where personal AI actually becomes useful.
This page documents how I built that knowledge layer for myself: 65+ automated jobs routed through UC San Diego’s TritonAI gateway — predominantly open-weight models hosted at SDSC — a 385-node knowledge graph, 267 wiki pages, and a three-layer memory system. It’s also a design pattern that could scale to thousands of staff at UC San Diego, giving every person a personal AI that understands their work world.
Every major research lab is converging on the same thing: a single app that turns chat into an agent, and uses your context — your memory, your files, your history — as the lock-in. Switch vendors and you lose it.
The approach on this page flips that. Knowledge lives in my filesystem, in open formats, under my control. Any model can plug into it; any model can be swapped out. The context layer is the moat — and it doesn’t belong to the vendor.
The question isn’t “can AI do this?” — it’s “how do you build the knowledge layer without handing your institutional memory to a vendor?” This is my answer.
Three layers of context loading
A personal AI faces a brutal 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. ~15 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/. This is the biggest unlock: 263 wiki pages that would otherwise sit unused become a live reference library, pulled in silently the moment they’re relevant. It feels like the AI “just knows,” not like it’s doing a lookup.
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.
The key insight: context is a budget, not a pantry. You don’t load everything; you load the right things at the right time.
Most personal-AI projects skip Layer 2 entirely — they read a long profile doc and call it done. Without triggered retrieval, the system can only use what fits in the opening prompt. Layer 2 is how an accumulating wiki becomes live knowledge.
The daily rhythm that builds the knowledge layer
65+ cron 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.
Night consolidation (3:00 AM). A dreaming cron consolidates short-term memories into long-term, the way sleep does for humans.
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.
Knowledge graph + wiki: brain stem and cortex
Two durable stores anchor everything:
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.”
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 5 new people pages and 5 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,500+ 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.
Model allocation: matching jobs to capabilities
Different jobs need different models. A 30-second token-refresh check shouldn’t run on the same model that drafts a weekly newsletter, and a deep architectural review needs reasoning depth a light monitor would waste. Each cron is routed to a model class that fits its work shape.
As of May 27, 2026, all 64 enabled jobs run through TritonAI — UC San Diego’s institutional AI gateway, with on-prem inference at the San Diego Supercomputer Center for the open-weight tier and hyperscaler-proxied capacity for the larger frontier models. ~94% of jobs run on open-weight models; the remaining 3 monitor jobs escalate to Claude Sonnet 4.6 because false negatives there carry real cost. Seven model variants split the load:
| Tier | Model | Hosting | Use | Jobs |
|---|---|---|---|---|
| Briefings & summarization | api-gemma-4-26b | TritonAI on-prem · Google Gemma 4 26B (open weight, multimodal) | Daily briefings, meeting debriefs, wiki/page refreshes, multimodal extraction | 17 |
| Fast monitor & sync | api-mistral-small-3.2-2506 | TritonAI on-prem · Mistral Small 3.2 (open weight) | Health checks, syncs, threshold alerts, shell-runner parsing, token refresh | 18 |
| Heavy synthesis | api-gpt-oss-120b | TritonAI on-prem · OpenAI gpt-oss 120B (open weight) | Opportunity scans, signal synthesis, blockage radar, LinkedIn candidate ID, TritonGPT intel | 16 |
| Long-form & deep reasoning | mistral-large-3-675b | TritonAI · Mistral Large 3 675B (open weight, cloud-proxied) | Weekly AI deep-dive, architecture & harness reviews, newsletter, LinkedIn drafts, vision tracker | 7 |
| Monitor escalation | claude-sonnet-4-6 | TritonAI · Anthropic Claude Sonnet 4.6 (proprietary, cloud-proxied) | Provider quota monitor, important-email triage — jobs where a missed signal has real downstream cost | 3 |
| Complex reasoning | tritonai-sonnet | TritonAI · Anthropic Claude Sonnet 4.6 (proprietary, cloud-proxied) | Granola meeting debrief — deep commitment extraction from transcripts | 1 |
| Code maintenance | deepseek-v4-flash-max | TritonAI on-prem · DeepSeek V4 Flash Max (open weight, code-specialized) | Overnight code maintenance for Mission Control (build, test, lint) | 1 |
Why predominantly open-weight on TritonAI: the gateway runs on-prem at the San Diego Supercomputer Center, the open-weight tier is served on UCSD compute, and the institutional virtual-key budget covers cron-driven workloads with no personal-tier API charges. Open weights also remove the “model rugpull” risk — when OpenAI deprecated gpt-5.4-mini in late April it broke six of my crons in a single morning, and when TritonAI itself retired Kimi K2.5, Claude Haiku 4.5, and Nemotron 3 Super in May it broke 17 more. The fix in both cases was a one-line alias change because no specific model is load-bearing in the architecture.
Why three jobs on proprietary Claude Sonnet: three cron jobs escalate to Claude Sonnet 4.6 because false negatives there carry real cost: provider-quota-monitor (catches outages and quota exhaustion before they cascade), gmail-important-emails (surfaces actionable messages buried in volume), and granola-meeting-debrief (deep commitment extraction from transcripts where extraction quality has direct downstream value). Everything else stays on the open-weight tier.
Why no cross-provider canary anymore: the old architecture kept one job on OpenAI Codex specifically to detect TritonAI-wide problems from outside. That worked until Codex itself hit a weekly cap and silently broke the canary. The lesson: the canary’s job is just to alert, and TritonAI already has rich health endpoints that do that more reliably. Concentration risk is real, but it’s now an explicit institutional bet rather than a hedged compromise.
How models get matched: each cron declares an explicit provider/model path (e.g. tritonai/api-gpt-oss-120b); the gateway routes accordingly. Rebalancing — e.g., moving a job to a different model — is a one-line config change, not a code change. A dedicated tritonai-key-access-monitor cron now runs Monday and Thursday evenings to probe TritonAI’s /v1/models endpoint for both keys, diff against the previous snapshot, and Telegram any change that would break a routing rule before a cron fires against it.
Provider lock-in is the moat AI vendors want. Open weights on institutional infra, wired through a gateway, with active monitoring of the model catalog — that’s how the moat stays from forming around your automation.
What this actually does
Building this was the hard part. Using it is where it pays off. What the ecosystem delivers today, the value it generates, and what else becomes possible once the foundation is in place.
What it does today
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.
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.
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.
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.
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.
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
- 1Time 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.
- 2Pattern 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.
- 3Institutional 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.
- 4Never 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.
- 5Opportunities 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
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.
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?”
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.
“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.
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.
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.
Scaling to UC San Diego
Everything above is one person’s implementation. The interesting question: what if every UCSD staff member had one?
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. This is proven — it works for one person, and the architecture is replicable. The hard part isn’t the technology; it’s the 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.
The team tier is no longer hypothetical. The first instance launched 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.
What we’ve seen in week one. 25+ assets updated in the first 48 hours — people cards, decision docs, project pages, runbooks, tech-stack entries. Not a write-once-and-die artifact: all three of us are editing continuously, 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. Pilot duration is four weeks; a structured retrospective is scheduled for June 15 to decide whether to expand to the full WTS team next.
The strategic reason this matters. If this works at three people, the same pattern — shared Obsidian vault, GitHub backing, proposals-first agent writes, ~10 minutes of human review per week per steward — should plausibly scale through WTS (a dozen+ people) to ITS leadership and onward. Each tier becomes “Layer 2” (triggered) for the tier above. If a UCSD 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. Individual identity is stripped 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.
Proven vs. speculative: the personal layer works; I use it daily. The team layer is now also shipped — live for three people since May 18 with a structured retrospective set for June 15. 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 real question isn’t “can we do this?” — it’s “what would it take to do it responsibly, at scale, in a way a 30,000-employee university can actually adopt without violating anyone’s privacy along the way?” That’s a design + governance + procurement project, not just a technology one. Worth having the conversation now, while the personal-AI space is still small enough to shape intentionally.
This architecture isn’t done
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 mission-control repo; highlights below for quick reference.
- June 7, 2026Graph 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.
- May 31, 2026Architecture 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.
- May 21, 2026TritonAI 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.
- May 19, 2026Open-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.)
- May 17, 2026Architecture 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.
- May 10, 2026Architecture 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.
- May 9, 2026100% 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.
- April 30, 2026Codex 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).
- April 29, 2026OpenRouter dependency dropped · OpenClaw 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 OpenClaw 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 openclaw security audit — chmod 600 on the config file fixed a critical world-readable finding.
- April 28, 202631-job migration to TritonAI open-weight models
UCSD 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.
- April 26, 2026Graph 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.
- April 24, 2026Citizen 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. Mission Control gained an Accessibility Audit screen surfacing vendor accessibility statements across 150 enterprise systems. New wiki page: TritonAI AI Initiative Readiness Copilot.
- April 15, 2026Hybrid 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.
- April 14, 2026Team 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.
- April 12, 2026Confluence 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.
- April 12, 2026Knowledge 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.
- April 11, 2026Model 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.
- Earlier 2026Graph + 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.
- FutureTeam-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.
The foundation of this ecosystem is OpenClaw — a personal AI assistant framework providing the cron scheduler, agent runtime, Telegram integration, multi-model gateway, and plugin SDK the pipeline runs on. What you see here isn’t OpenClaw out of the box; it’s OpenClaw tailored, extended, and reshaped over many 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. Without OpenClaw as the starting point, none of this would have shipped.
This page is hand-maintained, not auto-generated. Metrics are as-of snapshots — the number of nodes, pages, and crons changes as the system evolves. For the live state, see github.com/bpollak/mission-control. Questions, ideas, or corrections? Get in touch via the contact page.