Harold Moses II

I built an autonomous documentation monitoring system that detects API changes, determines documentation impact, generates updates, publishes through source control, and notifies stakeholders via Slack. It treats documentation as an observable engineering system — continuously checking for change, producing actionable evidence, and routing results into a repeatable update workflow. This is exactly the kind of automated doc-quality infrastructure that keeps documentation accurate as a product ships.

I built a documentation preprocessing tool that transforms Markdown and MDX files into RAG-retrieval-ready, agent-consumable content. Instead of fixing chunking at retrieval time, it restructures source documents so any downstream vector database or coding agent gets clean, self-describing, measurably better content. It includes a scoring engine (0–100) that quantifies RAG readiness and GEO discoverability before and after optimization — real measurement of doc quality for AI consumption.

I built a grounded retrieval server that turns Arize Phoenix's official documentation into something AI coding agents can query through the Model Context Protocol (MCP).

Discovery: parses Phoenix's llms.txt index (708 pages available), enforces an allowlist, and fetches only canonical documentation. Chunking: heading-aware semantic splitting — each chunk carries its title, section heading, URL, and a content-addressed ID. Embedding: sentence-transformers/all-MiniLM-L6-v2 for production semantic retrieval, plus a deterministic hashing fallback for offline tests.

Five MCP tools return ranked evidence with canonical URLs and a strict answer policy. Every claim traces back to an official source. When evidence is insufficient, the system explicitly abstains rather than inventing an API that doesn't exist.

▼ Interactive demo below — runs entirely in your browser with no backend. Search 10 indexed pages using TF-IDF (Term Frequency–Inverse Document Frequency) keyword relevance scoring.

I built Poly-Glot AI Workspace and developed its developer integration guide for the app's 15-tool MCP server — the same production server published across the Official MCP Registry, MCP.so, Glama, and Hugging Face. The guide takes engineers from zero to working integration using progressive disclosure: architecture overview → quick start → full tool reference → advanced workflows → troubleshooting. It's the documentation I wish existed when I started building MCP integrations.

I instrumented my production multi-provider AI app with Arize Phoenix and OpenTelemetry, producing a 9-page case study covering architecture, span hierarchies, test results, a Node.js setup guide with critical protobuf/ESM findings, production error remediation, and Phoenix documentation recommendations. 50 spans captured across 6 providers with 100% evaluation pass rate.

I developed a progressive Python guide that teaches documentation engineers how to build, trace, and document AI agent tools using Arize Phoenix. Instead of teaching Python in the abstract, every example uses Arize concepts — traces, spans, evaluations, and tool invocation — building from a 6-line doc lookup to a fully Phoenix-traced documentation agent with OpenTelemetry instrumentation. The guide culminates in the Arize AX API pattern for datasets, experiments, and monitors.

Using Poly-Glot AI Workspace — an app I built — I audited Arize's Phoenix and AX documentation from a developer's perspective, identifying 7 specific documentation gaps with proposed fixes. Findings include missing framework-agnostic TypeScript setup paths, undocumented Node.js protobuf/ESM gotchas, no unified Phoenix→AX migration guide, Python-heavy cookbook library, and the absence of agent-readability measurement — the role's most novel requirement.

I maintain two npm packages with 83 total published versions, demonstrating continuous shipping, semantic versioning, automated CI/CD publishing with granular access tokens, and ongoing maintenance of production developer tools.