Building a Second Brain · Knowledge systems - Agent platforms
A Success IT-inspired example showing where no KM fails, where connectors and search help, and where a structured KM layer materially improves consistency, reasoning quality, traceability, and permissioning.
Public note: this article uses fictionalized support details and simplified names. It is intended to explain the operating model, not expose live customer data, private tickets, credentials, channel IDs, or production configuration.
Imagine a support team using an agent platform for day-to-day operations. A Support Agent owns intake and Support CRM workflow. A Coding Agent owns engineering diagnostics, CodeGraph, database investigation, RCA, and PR handoff.
A user reports that a posted invoice total differs from the previewed total in a web application. They attached a screenshot showing the expected and actual totals for the same document.
Attachment shows document DEMO-INV-2026-014, preview total 12,240.00, posted total 12,480.00, and the screen path used by the user.
In this operating model, KM is not just document tagging. It is the layer that converts data access into disciplined action.
Task-specific instructions the agent must load before specialized work.
Step order, commands, evidence bars, handoff shapes, and stop conditions.
Role, user, channel, tool, sandbox, and approval rules.
Ledgers, memory files, active investigations, PR records, and audit trails.
Tagged source-system data: products, ticket types, repos, entities, owners, and ACLs.
Same ticket. Same model quality. Different operating knowledge available.
Only the prompt and generic AI knowledge.
Plausible answer, inconsistent execution. The agent can sound helpful while skipping policy, guessing authority, and leaving no durable audit trail.
SharePoint, Jira, Confluence, Support CRM, SuccessGraph, and CodeGraph are indexed.
Better factual grounding, but the agent still has to infer the operating procedure from retrieved chunks. That inference can vary by prompt, model, search ranking, and source freshness.
Search plus skills, runbooks, permissions, state, and approvals.
Consistent execution. The agent knows the procedure, follows authority boundaries, records evidence, and produces a traceable support and engineering handoff.
No KM does not mean the AI is useless. It means every operational decision is reconstructed from scratch, usually from incomplete prompt context.
The agent may investigate directly, assign a User, or ask a Manager, because it does not know the Support Agent to Coding Agent split.
It may suggest production SQL or status changes without channel, user, or approval context.
It may summarize findings in chat but fail to update the durable RCA, active investigation ledger, ticket comment, or PR evidence.
One run may search tickets first, another may query the DB first, and another may jump to code changes.
The key point: KM is the layer that coordinates the work, not just the layer that stores documents.
The Support Agent reads the user evidence, captures required fields, creates or updates the Support CRM ticket, and classifies product and type.
Product map plus request-type rules decide engineering route vs manual triage.
The Coding Agent resolves product, channel profile, repo, branch base, PR target, tenant context, and allowed diagnostic surface.
CodeGraph comes first. DB diagnostics are read-only, reasoned, and gated. Findings are recorded as they happen.
RCA, ticket update, channel report, PR evidence, and Support Agent handoff use a consistent output shape.
The KM layer matters most when the answer must become a governed action.
| Capability | No KM | Connectors and Search | Structured KM Layer |
|---|---|---|---|
| Find related information | Low Depends on prompt context. |
High Indexes tickets, docs, source metadata, SuccessGraph, and CodeGraph. |
High Uses search when it is the right tool. |
| Choose the right workflow | Low Guesses from general patterns. |
Medium Can retrieve rules but must infer precedence. |
High Loads the relevant skill and follows the runbook. |
| Respect permissions | Low No role or channel authority model. |
Medium Can see ACL metadata if indexed. |
High Enforces channel, role, tool, sandbox, and approval gates. |
| Produce audit trail | Low Chat answer may be the only artifact. |
Medium Can cite retrieved sources. |
High Updates ticket, RCA, memory, ledgers, and PR evidence. |
| Operate consistently | Low Different runs produce different next steps. |
Medium Better context, but still variable execution. |
High Procedure and stop conditions are explicit. |
If the end state is AI agents that assist daily operations, the KM layer must be more than source tagging.
A KM layer is the operational knowledge substrate that lets agents turn retrieved information into governed work.
It includes source metadata, but also the skills, policies, state, and runbooks that make an agent behave like a trained team member rather than a search box.
Products, customers, systems, tickets, repos, services, owners, and environments.
Skills and runbooks for intake, triage, diagnostics, PRs, releases, and support replies.
Role, user, channel, system, tool, and approval rules.
Durable ledgers for active work, handoffs, evidence, audit, and unresolved unknowns.
What was retrieved, what rule was applied, who approved it, and what artifact changed.
Connector/search platforms are still important. The point is that retrieval should be paired with an operational layer for action.
The operating model described here is the same one behind my talk Human in the Loop, and the starting point for the follow-up paper Two Brains, One Operator.
The research track this article belongs to, including knowledge graph research published on this site.
The follow-up paper: why personal and corporate agent memory must split, and how each half is governed and audited.
The revised Human in the Loop talk: bounded agents package colleagues' expertise while people retain authority, judgment, and customer relationships.
The repositories behind these systems.