For each one: the problem, the architecture, the decisions and what it achieved. Details of my employer's client systems are generalised on purpose. I can go deeper in a conversation, within what confidentiality allows.
An operational knowledge graph for engineers and AI agents
Problem
What an operations engineer needs to know is spread across observability, ITSM, CMDB, on-call and documentation tools. Agents have the same problem, and an answer nobody can trace is not useful during an incident.
Architecture
Clients
AI agents90% of queries
Engineersweb UI
↓
Access
MCP server
Web UI
Per-user audit, RBACon every path
↓
Core
Ontology and resolverentities and typed relations; stores no data
↓
Systems of record
Observability
ITSM
CMDB
On-call
Docs
Decisions
Store no data. Every query resolves live from the systems of record, so there is no second copy to keep fresh or to secure.
Treat agents as first-class clients. The graph is exposed through an MCP server as well as a web UI. Most queries now arrive through agents.
Make every answer auditable. Access is role-based and audited per user.
Gate autonomy with evaluation. Datasets built from human-verified incidents (gold, silver, bronze) and weekly LLM-as-judge runs back the autonomy levels that define what an agent may do unsupervised. The incident agent moved from L1 (suggest) to L2 (act under guardrails) under that system.
Result
5,000+queries from 9 engineers
90%through AI agents
88%answered with data
0.6 sp50 latency
02 · My own product, public repo
Bookreader: an AI reading agent that lives in the browser
Problem
A reader that can answer questions about your books normally needs your books on someone's server. I wanted the agent to work with the library staying on the device, and to add server pieces only where a feature could not exist without them.
Architecture
Browser (PWA)
Readerepub.js, pdf.js
AI agentreads the book against a goal
Local dataIndexedDB, localStorage
↓
Cloudflare Workers
GatewayOpenAI-compatible proxy, own tokens
Shareciphertext only, on R2
Syncencrypted in the browser
↓
Outside
LLM providerbehind the gateway
External agentslocal read-only MCP; remote MCP with scoped writes (preview)
Decisions
Encrypt sharing end to end. A shared link is encrypted in the sender's browser with AES-GCM 256. The key travels in the URL fragment, which browsers never send, so the server holds bytes it cannot read (ADR-053).
Validate model plans in code. The per-chapter plan the agent proposes is checked deterministically, with a proportional fallback (ADR-049).
Deterministic checks first, then a judge from another model family. Whatever code can verify, code verifies. An LLM judge scores only what needs judgement, and it never comes from the family under test, to avoid self-preference bias (EVALS.md).
Separate local and remote MCP. The local server is a read-only stdio bridge on your machine (MCP README). Write tools exist only on the remote endpoint of the sync Worker, in preview and limited by token scopes, and that endpoint is a stated trade-off: the Worker decrypts in memory to answer.