I build cloud cost-intelligence and data platforms professionally, and implement LLM-agent infrastructure from the ground up on my own time — one small, single-purpose library per hard problem, no framework in the way. The bias throughout: build the thing to understand it — minimal dependencies, code you can read end-to-end, behaviour you can inspect.
Each hard part of running an LLM agent, implemented as an independent library. They stand alone — and compose into a complete platform.
flowchart LR
T(["request"]) --> BH["🛡️ bulkhead<br/><i>gateway</i>"]
BH --> CG["⚙️ cogs<br/><i>runtime</i>"]
LM["🧵 loom<br/><i>context</i>"] --> CG
CG --> SN["📡 sonar<br/><i>tracing</i>"]
CG -. evals .-> GT["🎯 gauntlet"]
classDef n fill:#161b22,stroke:#30363d,color:#e6edf3,rx:8,ry:8;
class T,BH,CG,LM,SN,GT n;
| Project | What it solves | Notable internals |
|---|---|---|
| cogs | The agent runtime | Agent loop, typed tool protocol, provider abstraction, context management, permissions, and deterministic record/replay — in ~1.5k lines. |
| loom | Context engineering | Chunking, embeddings, vector retrieval, history compaction, and token-budgeted context assembly. |
| bulkhead | Provider resilience | Retries, circuit breaking, rate limiting, caching, failover, and cost governance in front of any provider. |
| gauntlet | Agentic evaluation | Deterministic simulated tool environments, state/trajectory/LLM-judge grading, and pass@k with Wilson confidence intervals. |
| sonar | Run observability | OpenTelemetry-style span tracer, cost/latency meters, and text/HTML trace timelines. |
| qwery | SQL over raw files | Hand-written tokenizer + recursive-descent parser feeding a Volcano-model executor over CSV/Parquet — the design behind DuckDB, in pure Python. |
Cloud cost-intelligence — an LLM agent that answers cost questions over large-scale usage data, and the analytics pipelines behind it on Kubernetes.
Reach for: Python Go C++ AWS · Bedrock · Athena Kubernetes · Argo SQL
$ contact ·
LinkedIn ·
mbsdeepak3@gmail.com