IT documentation library, generated from live systems

I built an internal documentation system that derives most of its content from the live infrastructure rather than relying on someone's memory. It covers the company's estate end to end, gives the IT team a shared operational reference, helps new hires ramp, and grounds the ticket agent in documented standards.

The important design decision is that it does not just sit there. The documented configuration comes from the running systems, and the agent works against those same standards when it handles tickets. That makes documentation an active part of operations instead of a file someone has to remember to update.

The domains

• Index Master navigation, plus an admin-tools-and-resources index at the root.
• Policies and conduct IT code of conduct, ticket and password standards, AI use policy, and the AI-assisted development policy and guide.
• Active Directory OU structure and delegation, the security-group catalog, and the Group Policy set including the server baseline and user configuration.
• Microsoft cloud The largest domain. Entra ID (attribute map, groups, admin roles, external identities, app registrations, enterprise apps and SSO) plus the Azure estate, its resource inventory, and the cost and spend review.
• Network Topology, VLAN and addressing scheme, wireless configuration, Meraki dashboard access and licensing, and domain registrars.
• Servers Inventory, software, storage and NAS, and the full Remote Desktop Services set covering gateway configuration, user management, client setup, and troubleshooting.
• Applications The IT team's own platforms: Freshservice, ScreenConnect, software deployment, and license positions for Adobe and Claude.
• Line-of-business apps The systems the business runs on: Snowflake, Power BI and Fabric, the CRM, UKG, Concur, QuickBooks, Ramp, PrinterLogic, Bitwarden, and more.
• Security Security baseline, access-control matrix, Defender for Office 365, Purview policies, and MFA.
• Procedures Computer deployment, server patching, password reset, purchasing, shipping, and endpoint escalation.
• Troubleshooting A quick-reference card for daily operations, triage guides, and vendor contacts.
• Standards The naming taxonomy across Active Directory, Entra ID, Microsoft 365 groups, servers, and computers, plus region codes.
• Cloud config export Machine-generated configuration snapshots, including CISA ScubaGear baseline assessment results kept as dated runs.

How it started, and what changed

Version one, in January 2026, was a Python renderer: a script read structured source content and produced a consistent, cross-referenced, revision-tracked markdown library. That solved formatting and regeneration, but the source content was still me writing down what I knew. It went stale the way all documentation goes stale, just more neatly.

The unlock was the IT Ops MCP server. Once the team's operational systems were reachable as one governed connector, the source of truth stopped being my memory and became the systems themselves. Documentation became a query problem rather than a writing problem, and the scope widened from the on-prem estate to essentially everything.

What each system contributed

• Microsoft Graph The Entra tenant documented itself: users and the attribute map, security and dynamic groups, license assignment, app registrations, enterprise apps and their SSO configuration.
• Azure Resource Manager and Cost Management The full Azure estate by resource group and by service, with spend attributed per line item rather than estimated.
• PowerShell over ScreenConnect Remote execution against the on-prem servers produced the hypervisor, domain controller, RDS, and utility-server inventory, along with roles, configuration, and build state, without standing up separate remote-management plumbing.
• Cisco Meraki API The multi-site network: appliances, topology, VLAN and addressing scheme, and firewall configuration per site.
• Freshservice API The service-management configuration itself: catalog items, workflows, groups, asset classes, and the knowledge structure.
• Claude Cowork with the browser extension The Snowflake platform, documented from live introspection of account usage: warehouse and role structure, BI connectivity, and cost, performance, and security observations pulled from the account's own telemetry.

Closing the loop: the docs read back

Documentation that only humans read decays, because nothing depends on it being right. This library is wired back into the same MCP server that generates it, as a governed read-only skill with search, read, and tree access over the repository. The ticket agent uses it as its standards source: asked what to name a new server, which region code applies, how offboarding runs, or which vendor to contact, it answers from the documented standard rather than improvising a plausible one. That is the difference between an agent that sounds like it knows the environment and one that actually does.

Every document is also mirrored into a Freshservice knowledge-base article, so a citation the agent gives is something any technician can open, not just the ones with a GitHub seat. Oversized generated exports get a short pointer article instead of the raw file, and each doc and its article carry a link back to each other, so the citation resolves cleanly in both directions.

The loop runs the other way too. The agent can open pull requests against the documentation when it finds something stale or wrong in the course of working a ticket, reviewed by a human before merge. So the systems generate the docs, the docs steer the agent, and the agent proposes corrections back. Each part has a reason to stay accurate because something downstream depends on it.

The Azure pass paid for itself

Documenting the Azure estate against Cost Management meant reading a full month of actual spend line by line, which is not something anyone does when the bill is simply approved each month. Two findings came straight out of it: a storage endpoint billing a flat hourly fee with zero transactions for the entire month, and a log workspace collecting a high-volume diagnostic feed at double the retention the use case called for. Both were recurring costs nobody had questioned, and both were recoverable without losing a capability. Documentation as a cost-control side effect was not the goal, but it is a fair argument for doing it against live data.

Why generate it instead of writing it

• It matches reality The documented configuration is read from the live configuration, so compliance work, baseline assessments, Conditional Access review, and firewall review all run against the same source of truth the team uses operationally.
• It regenerates When a convention changes or infrastructure lands, the affected documents are re-derived rather than hand-edited one by one.
• Diffs are meaningful Changes show up cleanly in version control instead of hiding inside a rewritten document, so the library doubles as a change record of the estate.
• Coverage scales past what one person would write Nobody hand-documents every group, license assignment, firewall rule, and warehouse role. A query does it in one pass and does it again next quarter.
• Something depends on it Because the agent reads these documents to answer questions and take action, an error in them shows up as a wrong answer rather than sitting undiscovered in a file nobody opens.

What this enables

• New team members ramp from documentation rather than from tribal knowledge. A recent hire started against a structured, complete document set before authoring knowledge-base articles of their own.
• Audit and compliance posture improves when the reference and the estate cannot drift apart silently.
• Continuity insurance The infrastructure can be operated from the documentation by someone who was not there when it was built. That was the original goal, and generation is what made it survive contact with a changing estate.

What this demonstrates

• Using an agent platform as infrastructure, not as a chatbot The MCP server was built for ticket operations; the documentation library is what it turned out to be capable of once the connector existed. Building the integration layer first is what made the second use case nearly free.
• Designing a system that maintains its own accuracy Systems generate the docs, the docs ground the agent, the agent proposes corrections back. No step relies on someone remembering to update a file.
• Breadth across the whole estate Identity, cloud, network, servers, ITSM, and the data platform, each documented against its own API rather than summarized from one vantage point.
• Documentation-as-code discipline applied to enterprise IT: versioned, diffable, regenerable, and structured, rather than a stale document in a shared folder.
• Finding money in the process Reading spend at line-item resolution as part of documenting it surfaced recoverable recurring cost that summary-level review had not.