Agent knowledge systems

The agent-era answer to “where does the work live”: software built around agents that gives them the context, tools and methods for a particular kind of work — the knowledge-work analogue of what coding harnesses did for codebases. If Software factory is the agent pipeline as code, this is the agent workplace as code: knowledge and workflows modeled so agents can follow, check and improve them.

The thesis (Heinrich / ars umbris, 2026-09-30)

Three things you need when working with agents over time (@arscontexta article captured, 2026-10-01):

1. Knowledge and work that persist — the next session picks up the work with its context: a decision stays connected to its evidence and assumptions, and to the work building on it; connections can be followed and reconsidered when something changes
2. A system that fits the way you work — not three SaaS silos (CRM + project tool + spreadsheet) holding one promise’s three sides; custom apps built with your agent over your own data, in one workspace, evolving with the practice
3. A reusable foundation — domain knowledge and established practices modeled as workflows (a research protocol, pre-promise checks); views over data (evidence table, commitments planner); another practitioner can reuse and adapt the foundation

Make a knowledge base work like a codebase

Software has ways to keep a growing codebase understandable, maintainable, changeable — the claim is knowledge needs the same patterns:

• a custom type system for the domain (YAML type definitions; markdown notes get typed frontmatter with typed references, e.g. feature: "[[account export]]")
• diagnostics for missing information and broken references (“this record is missing a required field”, “this reference points to the wrong kind of object”) — lint for knowledge
• packages you can import and compose (deps: in repo.yaml; type: claim::evidence-review — the qualifier names the package supplying the type; separately-maintained knowledge bases join one queryable graph)
• an IDE to navigate and refactor the work; version history for how thinking changes

Ars umbris implements this as a type engine + agent framework + host app: the engine reads repositories as one typed graph; the agent framework serves tools over MCP and delivers skills in the harness’s native format (adapters exist for Claude Code and Codex; others buildable). The bet: coding agents were built for codebases — navigate, change, act on diagnostics — and organizing knowledge the same way transfers those abilities to research or running a company. Domain-specific work concentrates in reusable packages instead of per-field harnesses.

The examples that make it concrete

• Commitments: a commitment type (feature*, deadline, source*) links a delivery promise to the feature and the conversation it came from; sales gets a pipeline view, engineering a planning view, over the same objects. When an integration slips, the agent follows the structure and surfaces the review; the post-mortem (“we repeatedly promise before checking integration work”) becomes a check in the method itself, visible before the next decision is accepted
• Evidence review: a researcher with ten papers supporting one conclusion — until typed grounding records (stance: asserts/denies/observes, basis: observed/reported/inferred) expose that several reuse the same dataset. “Apparent agreement between ten papers” becomes “investigation of the evidence behind it”. Crucial honesty: structure “doesn’t settle whether the claim is true… but it gives you structure you or your agents can follow and check semantically”
• Packages: an evidence-review package (types + methodological knowledge + skills/tools + review interfaces); au-govern — agents checking what the type engine can’t judge, like whether a cited passage actually supports a claim; legal-review packages connecting facts to authorities and interpretations

How this garden relates (the mirror)

This vault is a hand-rolled instance of pattern 1 and parts of 3: persistence via markdown + git (Digital gardens), provenance via clippings, a shared schema (SCHEMA.md, manifest), skills for methods, qmd over the graph, publish: as the (untyped) gate. What ars umbris adds is exactly the missing middle: typed references with diagnostics — wikilinks here don’t know if they point at the right kind of thing, and nothing reports a claim missing its grounding. The package graph (separately-maintained KBs as one queryable graph) is MoC discipline made importable. The au-govern idea — agent-judged checks over engine-checkable structure — is the same split as this vault’s verify gate (script-checkable) vs review (human/agent-judged).

Harness engineering (the everything-around-it layer)

@ishaansehgal (Omnara): “every team building a serious agent ends up drawing this tree — sentry spent ~4 months and 100k lines on theirs; stripe, shopify, harvey, ramp, sierra built their own. The harness isn’t the hard part. Everything around it is.” The quoted thread (kushbhuwalka, on their pre-Eve “god agent” fluffles — credit card, phone number, patched browser) names the failure mode precisely: “there wasn’t one specific thing that was hard, it was that the surface area of shit that can go wrong is unbounded” — automations, subagents, channel integrations; they ported to Eve’s scaffolding “to focus on agent behavior instead of the intricacies of a Slack integration.” The tree itself (vision-transcribed, full directory map in clippings/x-2106907683664318855.md) is a tree dump of /Users/ai — the agent’s home directory as harness: agent/ (composition), auth/ (bootstrap; Infisical canonical), automations/ (“one primitive for schedules, events, http, manual”), channels/ (slack/email/phone/webhooks/console), memory/ (“markdown plus a derived FTS5 index”), state/ (“runtime; never converged by a deploy”), tools/ (MCP manifests + harness charter) — and the machine-only block (projects/, notes/ = “not canonical memory”).

Harness engineering vs contextmaxxing, separated: harness engineering is the system around the agent (channels, state, auth, scheduling, subagent topology — the unbounded surface area); contextmaxxing is the material fed into it (docs, ADRs, runbooks, seeds inside the codebase — comprehension as a function of tools). The fluffles tree is both at once: the directory structure is harness engineering; the annotations (“operating docs; live state under…”, “bootstrap only; X is canonical”, “never converged by a deploy”) are contextmaxxing — every path carrying the sentence an arriving agent (or human) needs. One without the other fails: a perfect harness with an opaque home is a black box; perfect docs with no harness never touch production. The discipline’s empirical base: arXiv:2609.00006 (eleven-harness source-code study: 29 patterns, no frameworks imported, no vector retrieval, skills>MCP 9/11, harness = platform). Kin: Pi agent harness (the minimal-harness pole), pi durable (state discipline), Agent sandbox (the trust boundary), the KISS arc (the tree is also a restraint — 22 entries, one level).

Open

• (open: is 2027 really the year this becomes mainstream knowledge work, as Heinrich predicts?)
• (open: the MCP + native-skill delivery (Claude Code/Codex adapters) vs MCP reconsidered’s “OpenAPI with intelligent tool discovery” — same composition critique, different layer)
• (open: does the typed-graph approach compose with Human Agents Workspace’s signed-event substrate, or do they solve different problems?)

Related: Software factory · Human Agents Workspace · MCP reconsidered · Digital gardens · Hermes Agent

The counter-thesis: documentation over recall (liao.gg, captured 2026-10-05 + HN 49945933)

“Agents don’t need memory, they need documentation.” The attack on the memory-plugin ecosystem: every plugin is the same architecture — transcripts → snippets → vector DB → top-5 injection per prompt — “a lottery over RAG snippets.” The failure modes: similarity ranks closeness, not correctness/currency; snippets lose context and motivation; the past is treated as truth while the codebase changes daily; agents can’t search for what they don’t know they’re missing; and the store is unauditable (“10,000 embeddings in SQLite — which are stale? which are secretly shaping behavior?”). The human analogy: nobody rewatches a 3-year-old meeting recording; people write things down.

The proposed fix — operator-memory (OSS) (aerovato, TS): a Markdown “brain” (instructions, specs, decisions, research, indexes) the agent consults before and updates after work. The loop changes from prompt → build → forget to prompt → consult → build → update. “No vector databases. No embeddings. No summarizers, curators, updaters, dreamers, or any other token-burning background daemon.” Everything is a plain document you can read, commit, and share.

Tension with this note’s own position (and with OptChat below): the garden is both — documents as the knowledge layer, hybrid search (qmd) as the recall layer over them. The critique lands hardest on snippet-extraction memory; it doesn’t touch document-grounded memory with an audit trail.

The name for this position: contextmaxxing (@arvidkahl, 2026-10-01, captured → clippings/x-2105714739380973975-thread.md, quoting @dhh on agent-code review). Kahl’s list is liao.gg’s thesis generalized beyond memory: “docs, ADRs, customer ICP descriptions, runbooks, schema commentary, all must live INSIDE the codebase, not just attached to it” — plus process contextmaxxing (every agentic conversation + changes tracked and attached to the ticket/PR) and representative dev/test data (“seeds aren’t dummy data”). The closing line is the epochal one: “Comprehension is now a function of our tools, not a state of our minds.” The Karpathy LLM-wiki pattern this vault runs is contextmaxxing at the knowledge-base layer (queryable docs as the agent’s world), and liao.gg is contextmaxxing argued from the memory-plugin failure side; the dhh quote adds the review half — adversarial agent reviews + automated tests + spot checks, because “there’s no future where you’re manually reviewing every line of agent code.

The precise definition (@ashwingop/Sentra, 2026-10-05, captured → clippings/x-2053539041770164648.md): “Contextmaxxing does not mean stuffing the largest possible prompt. That is just token maxing wearing a different costume. Context maxing means maximizing relevant, permissioned, evidence-backed context per AI action.” The right context = “prior decisions, constraints, owners, failed attempts, open questions, promises, contradictions, and source evidence that matter for the task” — sometimes 500 tokens, sometimes a graph lookup or a compact state object. Corollaries worth keeping: memory as economic infrastructure (without it every agent burns tokens rediscovering what the company already knows; with it, tokens go to judgment/execution/verification); compiled-over-retrieved (RAG at query time “keeps making the model re-derive what should have been compiled already” — citing Karpathy’s LLM wiki gist and Garry Tan’s GStack/GBrain); bigger context windows don’t solve this (“the bottleneck moves from ‘can I fit it?’ to ‘what belongs here?’”); and the metric shift — useful context per token, verified outcome per token, not tokens used. Vendor caveat: Sentra is selling a “company brain,” but the definition and the economics are vendor-independent.

Agent Memory Repo: the OSS standard from Cognition (Dreaming)

walden_yan (1,636❤ / 125k views; Cognition’s Walden Yan) announcing the open-sourced memory format + cognition’s Dreaming tweet + the spec (11.1 KB, captured): across sessions Devin builds a memory graph of how you like to work, and “at night” the Dreaming agent self-improves memory — spot patterns → new entries; merge duplicates, remove stale records, check sources to resolve contradictions. Format, verbatim from the spec: git + markdown, graph relationships ([[path]] cross-links rooted at the memory root), historical records (every entry carries source: session link + added: date; updates append rather than overwrite), MEMORY.md as loaded-at-session-start entry point (“keep it short: only what every session needs, plus links”), agent pushes after every edit with no human in the loop. Use cases: personal memory · agent swarms (parallel agents push to one repo; git flags conflicts) · team memory (a lesson from one support investigation reaches everyone’s agents) · multiplayer composability (Bob’s memory repo cloned into the session VM; agent tracks who said what, writes to the right repo, asks when unclear). The vault mirror is exact — this garden already IS an Agent Memory Repo: MEMORY.md=00 Home, entries=log.md bullets w/ source+date, cross-links=wikilinks, Dreaming=qmd tending sessions, swarm=parallel capture batches; the differences (clippings hash-pinned verbatim, human curation of concept notes) are the policy layer on the same substrate.

CorpusMap: entities as corpus navigation (Microsoft, arXiv:2609.37226)

_overment quote-tweeting dair-ai’s summary (both captured + the abstract): CorpusMap — a navigation layer that resolves recurring entities across a document collection in advance and gives each entity a page linking to every document that mentions it; original documents stay in place. The agent reads a document, follows an entity to related documents, and stops re-searching for the same evidence. Numbers across 7 models and 3 benchmarks: answer quality +6.4 to +11.7 points while input tokens DROP 34–57% — and it beats an LLM Wiki layer plus three other navigation layers. The map builds without LLM calls and updates incrementally as documents arrive. Vault relevance is direct: this is the empirical validation of the wiki/MoC thesis this garden runs on — entity pages ≈ concept notes (one page per recurring entity, linking every mention), maps ≈ maps/ MoCs, offline-built ≈ qmd tending; and the win condition is both quality AND token cost (AI metrics that actually matter — the 34–57% input-token cut is a cost-per-task result). It also adjudicates the memory debate above: neither raw recall (liao.gg’s counter-thesis) nor LLM-wiki prose — deterministic entity linking beats both.

Building a Memory Pipeline — HumanLayer live episode (2026-10-06)

dexhorthy: “this is gonna go down as one of the best episodes we’ve ever done” — the AI That Works #77 broadcast, “Building a Memory Pipeline” (both tweets captured; broadcast is X-live video, not fetchable — no transcript exists yet). Why it matters to this note’s running theme: HumanLayer is the third independent shop (after Cognition’s Agent Memory Repo and this garden’s qmd loop) converging on memory as an engineered pipeline — extraction, storage, retrieval, and maintenance as explicit stages you design, not a feature you buy. Dex’s own product lane (AC DriverManager, outline skill) treats agent context as buildable infrastructure; a full episode on the memory pipeline is that thesis at book length.

Transcript now captured (2026-10-07): the broadcast was downloaded via yt-dlp and transcribed locally (Parakeet STT — X broadcasts ship no captions) — see Building a Memory Pipeline 🦄 AI That Works #77 (markdown link: the stem carries #, which breaks wikilink resolution). The episode body confirms and extends this section’s thesis: dex + Aaron (BAML co-founder) walk a working pipeline that extracts facts and human corrections from coding-agent sessions, groups them across sessions, judges them (weak model pre-screen → strong model judge), and writes CLAUDE.md-ready memories. Two claims here now grounded in the transcript: the pipeline stages are exactly the ones this note lists (extraction/grouping/judgment/maintenance), and the maintenance problem is still open — dex names staleness (“hobbling the model” with instructions it no longer needs) as unsolved, Cognition included, which sharpens the Open question below.

Meta’s tribal-knowledge mapping: “compass, not encyclopedia” (2026-10)

undefinedKi (242❤ / 19k views; 2-tweet + the full Meta engineering post, all captured — this also clears the carried pending on this author): Meta mapped a 4,100-file, 4-repo, 3-language pipeline codebase into agent-navigable context — 50+ agents in one session (explorers → 11 analysts → writers → 10 critics × 3 rounds → fixers/testers), every analyst asking the same five questions per module (what it configures · how it’s changed · what breaks it · what depends on it · what’s hidden in comments).

The output and the numbers:

• 59 tiny files, 25–35 lines (~1,000 tokens) each — four sections: Quick Commands / Key Files (3–5) / Non-Obvious patterns / See Also. All 59 together <0.1% of a context window. “Compass, not encyclopedia.”
• 5% → 100% coverage (5 → 59 files; 50 → 4,100+ navigable files); 40% fewer tool calls and tokens; zero hallucinated paths (verified); two days of tribal-knowledge research → ~30 min. Critic rounds lifted quality 3.65 → 4.20/5.
• Cross-repo dependency index + data-flow maps: “what depends on X” from ~6,000 tokens of exploration to a ~200-token graph lookup.
• Self-refresh every few weeks: “context that decays is worse than no context at all” — validation, gap-finding, re-critics, auto-fix.

The sharpest part — challenging the academic counter-evidence: research (arXiv 2602.11988) found AI-generated context files decreased agent success on famous OSS repos. Meta’s answer: models already know Django/matplotlib from pretraining — context files there are redundant noise; on proprietary code they’re the whole game. Their three guards: concise (~1K tokens), opt-in (loaded when relevant, not always-on), quality-gated. “The cost of not providing context is measurably higher.”

Vault mirror: this is the Agent skills/Agent knowledge systems convergence at enterprise scale — same shape as Cognition’s Agent Memory Repo and this garden (entity pages ≈ compass files; Dreaming ≈ the self-refresh job), but with the pipeline factory (50 agents) and the falsifiable metric (40% fewer calls). Also the strongest answer yet to the eleven-harness study’s “no vector embeddings” finding: the alternative to embeddings is curated compass files + a graph index.

The Bops stack, assembled in 2 days (2026-10-08) — honcho + composio flagged

nickvasiles (569❤/40k views; both tweets captured): the full stack behind his Jev-integrated Bops, “built everything in 2 days using theo’s t3 and opus 5.5 high” — design @paper · harness OpenAI · memory: honcho.dev · computers: @orgo (virtual computers, orgo-mcp) · messaging+calls: AgentPhone · connectors: @composio · email: agentmail · GTM search: treg. The quoted tweet: Jev “watches your screens so you can get notified when things need your attention — jev watching multiple orgo computer screens at the same time” (decision models as the attention router over agent VM fleets).

USER FLAGS, verbatim: “Two interesting parts for me are honcho and composio” — both captured:

• honcho (OSS) (plastic-labs, 7.5k★ Python, pushed same-day) — “memory infrastructure for stateful agents that understand changing people, agents, groups, projects, and ideas over time.” The model: peer-centric (entities change over time), multi-peer perspective (“models what one peer knows about another”), reasoning-first (“extracts conclusions from conversations and events, not just matching chunks”). The loop: Store → Reason in the background (queue processor updates peer representations) → Query → Inject. Self-hostable (honcho start, FastAPI) with Hermes as a first-class integration (MCP, Claude Code, OpenCode, OpenClaw, Cursor). Claims the “Pareto frontier of agent memory” with public evals. For this note: the lane supermemory v5 occupies, but self-hostable and entity-graph-shaped — the roadmap §3 candidate this vault’s memory-comparison research wanted; kin: the Meta tribal-knowledge compass (background reasoning ≈ Dreaming) and octop-memory (the unbundled sibling).
• composio (OSS) (30.5k★) — the connectors layer: 1000+ pre-authenticated toolkits, per-user sessions, auth, triggers, sandbox; provider adapters for OpenAI Agents/Claude Agent SDK/LangChain/Vercel AI; a CLI (composio search|execute from the shell — the CLIs-for-agents shape); and an agent-accessible-product detail worth noting: the TS package “intentionally packages its TypeScript source so the installed package is inspectable to coding agents” (slim variant if not). The mitsuhiko Codemode wishlist’s “cross-server tool search” as a product — the connectors pole of the MCP-reconsidered arc.

”The truth of the company has to sit somewhere they can read” (codegood.co, 2026-10-12)

Richard Seroter → codegood.co: The standup your agents can’t attend (both captured): the contextmaxxing thesis carried to the whole company. “Everything my agents do rests on one condition: the truth of the company has to sit somewhere they can read. They read files, logs, streams, and state. They cannot attend the standup.” Every fact that exists only in a meeting is invisible to the new workforce; “a company that coordinates by meeting can bolt agents on and will get little.”

The estate described (all record-first, no meetings): agents that publish, never speak — one-line updates to named channels, every claim carrying a pointer to the record that proves it (“a pointer that doesn’t resolve buys nothing downstream”); claims-on-shared-things before touching them; corrections posted to the channel that carried the mistake with evidence attached; status as an hourly digest computed from work records, “never collected from the workers”; a watcher whose standing job is naming streams gone quiet; a 15-minute timer reading published state of 176 services and citing the record it judged from. The receipts: a crash-loop invisible to alerts (service reported itself running between crashes) found, diagnosed, fixed, and written down by a watcher; an agent retracting its own earlier claim citing the records that proved it wrong (“a better standard than most incident reviews I’ve sat through”); a leased queue task run and posted for 18 cents.

The GitHub exit is the spiciest claim: git is decentralized, the PR is a meeting (“a page somebody must visit, a button somebody must press, an approval that only lands if the right person is looking”) — so the trunk moved to a plain append-only git repo on their own machines, review verdicts as records with offsets, re-read by the validator before merge. “The history is the artefact; the rest was ceremony around it.”

Why this anchors here: it’s the documentation-over-recall counter-thesis promoted from agent memory to company coordination — contextmaxxing at org scale. The meeting-artefact audit (“for each standing meeting, ask what artefact would end it… the board that would be true, the written decision trail, the state file”) is the practical tool; “each standing meeting is interest on an artefact nobody built” is the line to keep. Kin: AI native teams (the org-design side — Lara Hogan’s team-level agentic systems, same direction), Agent tests (citations re-read before merge = verification as protocol), the Capy guided-review capture (making review readable vs making it a meeting).